Chiudere il gap del Captive Portal

Pubblicato un anno fa, un nuovo standard elaborato dalla Internet Engineering Task Force (IETF), propone finalmente una soluzione generale per il funzionamento dei Captive Portal.

Il Captive Portal è un mezzo ben noto per il collegamento alle reti WiFi “pubbliche”, che offrono servizi per la navigazione in rete in centri commerciali, stazioni, aeroporti, Università e luoghi pubblici in genere.

E’ sempre più diffuso, ma si affida fin dalla sua apparizione a meccanismi poco ortodossi e mai standardizzati.  Un fatto che rende difficile per i gestori garantire un comportamento uniforme nei confronti di tutti i device che vogliono collegarsi e, di conseguenza, rende sovente poco fluida, per non dire macchinosa, l’esperienza degli utenti.

Il nuovo standard si propone di risolvere una volta per tutte questo problema e, al tempo stesso,  vuole offrire nuove possibilità di interazione per migliorare l’esperienza dell’utente finale. 

Da quando è stato depositato, circa un anno fa, lo standard si trova ancora in stato di “Proposed Standard”. Tuttavia, i maggiori produttori interessati, Apple e Google, hanno iniziato ad implementarlo nelle versioni più recenti dei loro sistemi operativi. Apple lo supporta sia su iOS che iPadOS. Per il primo, a partire dalla versione 14. Per il secondo, sicuramente dalla 15.0.2,;sinceramente non sono sicuro quale sia la prima versione di iPadOS che lo supporta efficacemente.

Google invece, ha dichiarato il supporto a partire da Android 11.

Come funziona

Per ottenere la connessione alla rete WiFi, l’utente deve autenticarsi ed accettare le condizioni di servizio. Non esistendo alcun protocollo standardizzato, fino ad oggi il Captive Portal per presentare la pagina di login deve in qualche modo manipolare il traffico di rete. Generalmente ridirigendo verso una propria pagina, tramite una risposta HTTP 302, qualunque richiesta inviata dal browser. 

Questo meccanismo, benché poco ortodosso, ha funzionato a lungo; fino alla diffusione massiccia dell’HTTPS. 

Quando una richiesta HTTPS viene reindirizzata ad un url diverso da quello richiesto, inevitabilmente si verifica un errore di certificato. Ed è giusto così.

Per aprire la pagina di login, l’utente deve immaginare di trovarsi dietro un Captive Portal ed accettare l’eccezione di certificato. Sempre che il browser gli consenta di farlo. Peraltro è evidente come non sia una buona pratica abituare gli utenti ad ignorare questi avvisi di violazione della sicurezza…

Sono o non sono online? (captive o non captive)

I produttori di sistemi operativi, hanno quindi inventato un workaround, facendo si che al momento della connessione ad un WiFi, il sistema invii immediatamente una richiesta ad uno o più url predefiniti e, se non riceve la risposta prevista, consideri di essere dietro un Captive Portal ed apra la finestra di un mini-browser “embedded”.

A sua volta, il Captive Portal intercetta la richiesta e restituisce al suo posto una sua pagina web; tipicamente un modulo di login. 

In questo modo, la finestra aperta dal Sistema Operativo, mostra all’utente la pagina di login proposta dal Captive Portal, consentendogli di portare a termine in maniera indolore il processo di autenticazione.

Il fatto che i produttori abbiano implementato i propri meccanismi di connectivity-check, senza peraltro documentarli completamente, rende la soluzione debole e tutt’altro che ideale. Il Captive Portal è costretto a comportarsi in maniera non dissimile da un attacco hacker di tipo “man-in-the-middle”, con tutte le controindicazioni del caso.

Il nuovo standard e la CAPPORT API

Il protocollo DHCP prevede che il server possa inviare al client che richiede un nuovo indirizzo IP, “messaggi” contenenti un codice ed un valore. Il nuovo standard sfrutta questa opportunità, destinando il codice (option) 114 a questo scopo.

In poche parole, quando il client WiFi richiede l’indirizzo ip, il server DHCP deve restituire assieme a quest’ultimo una option 114, contenente l’url con il quale il Captive Portal implementa la cosiddetta Capport API.

Il Client chiama automaticamente l’API, che deve restituire una risposta in formato JSON. La chiamata deve essere obbligatoriamente fatta in HTTPS.

Esempio di chiamata alla Capport Api:

GET / capport_api HTTP/1.1
Host: captive1.mywifi.com
Accept: application/captive+json

E la risposta:

HTTP/1.1 200 OK
Cache-Control: private
Date: Mon, 06 Jul 2020 10:07:35 GMT
Content-Type: application/captive+json

{
“captive”: true,
“user-portal-url”:” captive1.mywifi.com/home”,
}

La discriminante principale è lil campo “captive”. Se è true, il Client capisce di trovarsi dietro un Captive Portal, e di dover chiamare la pagina di login (user-portal-url). Se è false, la navigazione è attivata. Altri parametri (v. più sotto per i dettagli) possono fornire altre informazioni al Client stesso.

Quando il device si collega al wifi:

  1. Richiede un indirizzo al server DHCP
  2. Assieme all’indirizzo IP, riceve dal server DHCP l’opzione 114, contenente l’url della Capport api
  3. Chiama l’api e riceve dal server la risposta descritta qui sopra

Se la risposta contiene captive = false, si considera collegato e libero di navigare

Se le risposta contiene captive = false:

4. Chiama l’url contenuto nel parametro “captive-portal-url”

5. Il server presenta la pagina di login

Quando il processo di autenticazione si chiude con successo il device viene informato (tipicamente ricevendo una pagina di “buona navigazione”) e

6. Il Captive Portal invia al “Network Access Enforcement Tool” il segnale per attivare le regole che permettono la navigazione al device autenticato.

7. Il protocollo prevede anche un non meglio definito “Captive Portal Signal” inviato dal Network Access Enforcement Tool al Device collegato. Questa specifica, però, non è ancora stata dettagliata e, al momento, nessun produttore di apparati mobili l’ha implementata.

venue-info-url

Ad autenticazione completata, ed ogni volta lo desideri, il sistema operativo del device mobile può chiamare la Capport API.

Poiché il device è collegato, l’api risponde con captive = false e, in più, aggiungendo altri parametri. 

Fra questi, il tempo di navigazione ancora disponibile e/o la quantità di dati ancora scaricabili. L’uso di questi due parametri, dipende dall’implementazione del Captive Portal e dalle sue eventuali limitazioni in termini di tempo di connessione e/o quantità di traffico prodotto.

Molto interessante è invece il parametro venue-info-url.

La sua implementazione è molto semplice; il Captive Portal può impostare un url a piacere. Se il sistema operativo lo implementa, quando rileva questo parametro, mostra un avviso all’utente (nell’immagine a fianco, la schermata di uno smartphone Android 11).

Cliccando su link, l’utente viene portato alla pagina definita dal gestore del Captive Portal.

Questa opzione offre interessanti possibilità di interazione con gli utenti del WiFi. Dalla semplice presentazione di inserzioni pubblicitarie, fino a più utili moduli informativi o interattivi (survey). Un Captive Portal dedicato ad un evento, potrebbe fornire informazioni dettagliate sull’evento stesso (agenda) e permettere di scaricare da un apposito sito materiale informativo, file, presentazioni.

CAPTIVISSIMO WiFi supporta, a partire dalla versione 2.0.9, il nuovo protocollo; compresI i parametri “informativi come la “venue-info-url” e i “seconds-remaining”, che potranno essere utilizzati “out of the box”, man mano che i software client ne completeranno l’implementazione.

Vuoi saperne di più sul nostro captive portal?