Captive portal: differenze tra le versioni

Versione delle 09:45, 26 giu 2025

Versione attuale delle 23:45, 8 lug 2025

Riga 17:

=== Possibili anomalie ===

Può succedere che all'atto dell'accesso l'utente riceva dal browser dei messaggi di errore e relativa impossibilità di conclusione dell'autenticazione. Quello tipico è quello relativo all’utilizzo di un [[certificato digitale]] non valido o ad un’autorità di certificazione non riconosciuta. Ad esempio, accade qualora la pagina del captive portal sia pubblicata in http ma il browser sia impostato (criteri di sicurezza relativi al [[Domain Name System|DNS]]) perché accetti solo indirizzi in https o sul gateway non sia stata selezionata la risoluzione automatica in https. In questi casi è sufficiente forzare l'indirizzament in http (si può anche digitare la URL ''http://neverssl.com'') o disabilitare temporaneamente la sicurezza sul DNS e relativo certificato. Oppure, se configurati dall'utente, non usare DNS alternativi (ad esempio quello di Google o di openDNS) ma impostare l'indirizzamento totalmente automatico via DHCP (l'altermativa sarebbe quella di usare il protocollo DNS-over-HTTPS a livello di browser o di sistema operativo in modo da superare l'eventuale blocco sul router all'uso di DNS alternativi).

Un altro è quello per cui, una volta connessi alla rete wireless, non si apre in automatico la pagina (del browser predefinito) del captive portal con la quale eseguire l'autenticazione: a volte, è sufficiente eseguire la disconnessione e nuovamente la connessione. Altri rimedi possibili sono: riavviare il dispositivo, disattivare e riattivare il Wi-Fi, svuotare la cache DNS (ad esempio in Windows tramite il comando CMD "ipconfig /flushdns"), rinnovare la configurazione IP o verificare le impostazioni del proxy, consentire l'accesso a host aggiuntivi tramite il firewall.

Riga 57:

La maggior parte delle implementazioni di captive portal richiede agli utenti di superare una pagina [[Transport Layer Security|SSL]] di login criptata, dopo la quale il loro [[indirizzo IP]] e [[indirizzo MAC|MAC]] sono abilitati a passare attraverso il gateway. È stato dimostrato che questo tipo di accesso è facilmente attaccabile tramite un semplice [[sniffer|packet sniffer]]. Una volta ottenuti IP e indirizzi MAC di altri dispositivi già autenticati e connessi, chiunque dotato di mezzi e conoscenza tecnica può superare i controlli falsificando le proprie credenziali ([[spoofing]]) con quelle degli utenti autorizzati e attraversare indisturbato il gateway.

Per questa ragione sono state create alcune soluzioni di [[autenticazione]] estesa per limitare i rischi di usurpazione di captive portal.

Una possibile soluzione a questo problema consiste nell'utilizzare una finestra di controllo che continuamente rinnova l'autenticazione mandando al gateway un pacchetto criptato. Tale tecnica è implementata per esempio nel captive portal di Zeroshell.

Riga 90:

Talvolta, l'utilizzo di tecniche di protezione del Layer 2, come [[Wi-Fi Protected Access|WPA]] e [[WPA2]] non sono adottabili per via del loro processo di setup oneroso per l'utente.<ref name="paolo.pavan.name" />

Ad ogni modo, la loro adottabilità dipende dall'utilizzo di hardware ([[Scheda di rete|schede di rete]] ed [[access point]]) e di sistemi operativi che siano in grado di supportare i suddetti protocolli.

Sovente, è comunque necessario un sistema di sicurezza svincolato dal canale di comunicazione sia esso wireless o via cavo.

Spostare il controllo degli accessi dal livello 2 al livello 3 (del [[modello OSI]]), si può rivelare una politica vincente.