Il comportamento dipende dal browser. Se il browser invia effettivamente la richiesta HTTPS destinata a Facebook al captive portal, allora è chiaramente una vulnerabilità del browser. Ma ci sono altri modi per gestire la situazione.
Recentemente ho dovuto utilizzare una rete con un captive portal alcune volte. E in quei casi ho avviato Chromium che ha avuto un paio di schede di Facebook aperte da una sessione precedente.
Quello che è successo è che è stato visualizzato un messaggio di errore corretto. Ma allo stesso tempo Chromium ha aperto una nuova scheda che accede a un URL HTTP specifico con l'intenzione effettiva di essere dirottato dal captive portal. Non appena ho superato il captive portal, le schede di Facebook si ricaricano automaticamente e questa volta non viene visualizzato alcun errore.
Quindi sembra che Chromium rilevi la presenza di un captive portal, lo apra in modo sicuro e infine rilevi dopo aver superato il captive portal.
Il rilevamento di un captive portal simile esiste in Android e iOS, anche se non è legato al browser ma avviene piuttosto come parte dell'associazione con il punto di accesso.
Vedo alcuni malintesi sulla tua comprensione di come funzionano i portali in cattività. I portali in cattività che ho incontrato hanno sicuramente funzionato in modo diverso.
Nessuna intercettazione è stata effettuata per il traffico DNS. Finché hai utilizzato il server DNS fornito tramite DHCP, al tuo computer è consentito effettuare ricerche DNS senza restrizioni senza accedere al captive portal.
Nessun trucchetto ICMP viene estratto. Piuttosto uno dei router sul percorso legittimo tra il computer e il server dirotterà le connessioni TCP alla porta 80. Una volta che la connessione TCP è stata dirottata, un reindirizzamento al captive portal verrà inviato al browser. Nelle implementazioni corrette, questo reindirizza a un URL HTTPS e in qualche modo include informazioni sull'URL originale in modo che tu possa essere rinviato più tardi. L'intera comunicazione con il captive portal viene eseguita utilizzando un certificato legittimo per un nome di dominio che in realtà appartiene al captive portal.
Questo approccio funziona per HTTP - ma non per HTTPS. Il router che esegue il dirottamento non avrà un certificato valido per il sito a cui si sta accedendo, quindi in qualsiasi browser sicuro verrà visualizzato un avviso di certificato se lo stesso dirottamento è stato eseguito per HTTPS.
Ci sono tre modi per aggirare il problema non funzionante per HTTPS:
- Affidati agli utenti che ignorano gli avvisi di sicurezza e accettando che le loro informazioni private verranno intercettate anche dopo essere state presentate per un avvertimento molto dettagliato sul rischio.
- Affidati agli utenti a capire come funziona tutto e, da soli, apri un URL HTTP per essere dirottato e poi conosci l'URL HTTPS originale dopo aver passato il captive portal.
- Consenti al software client di rilevare la presenza di portali in cattività e gestirlo in modo appropriato. Questo si basa ancora sulla capacità degli utenti di individuare se un captive portal sta tentando di eseguire attacchi di phishing, ma almeno non perde alcun cookie.