Come dovrebbero reindirizzare i portali in cattività?

Tecnicamente un portale captive è sempre un attacco man-in-the-middle. Pertanto, tutte le tecniche contro MitM dovranno e dovrebbero avvertire su di esse, dando all'utente il potere di decidere se fidarsi o meno. Alcuni browser hanno rilevamento del captive portal , in generale consentendo temporaneamente il reindirizzamento senza mostrare qualsiasi pagina con il dominio originale.

Contemporary security needs make transparent implementation of captive portals challenging. Thankfully, web browser and OS developers realize the importance of reporting the existence of this intermediate status between being connected to the Internet or not, this way reducing failure cases to a minimum.

Da questo punto di vista, il reindirizzamento a una pagina di accesso al portale captive separata con un certificato adeguatamente firmato e corrispondente sarebbe meno dannoso che mostrare la pagina di accesso direttamente con qualsiasi dominio.

Abbiamo altre opzioni?

• Potremmo eseguire il reindirizzamento solo su un semplice HTTP per evitare l'errore di mancata corrispondenza del certificato. Sarebbe comunque un MitM, ma su un protocollo che non è stato progettato per rilevarlo. Questo avrebbe funzionato perfettamente prima di HTTP Strict Transport Security (HSTS) contro il nostro attacco di downgrade del protocollo , che sarebbe questo tipo di captive portal.

• Nessun reindirizzamento. Basta bloccare tutto il traffico prima che l'utente abbia aperto manualmente l'URL della pagina di accesso e effettuato l'accesso. Sicurezza massimizzata, a scapito della convenienza. Ora devi informare i tuoi utenti di questo accordo, che di solito significa bisogno di ulteriore supporto. Anche se comunichi ai tuoi utenti immagini che hanno bisogno di digitare questo indirizzo nella barra degli indirizzi , alcuni di essi cercano ancora di cercare l'indirizzo da Google.

• Abbandonare il WiFi aperto e utilizzare altri metodi di autenticazione. Nessuna necessità di captive portal né di login. Severo bisogno di supporto. L'impresa WPA2 sarebbe tecnicamente ideale in quanto non è necessaria una singola chiave pre-condivisa, ma è meno nota al gruppo target (persone che utilizzano il WiFi ad accesso libero).

Allo stesso tempo, queste sono le ragioni per cui esistono ancora portali in cattività. La mia idea di un sostituto adatto per i portali in cattività sarebbe un semplice URL HTTP standardizzato che i browser proverebbero ad accedere quando mai viene rilevato qualcosa che blocca la connessione. Quella pagina eseguirà quindi il reindirizzamento alla pagina di accesso con HTTPS e un certificato appropriato, e il browser dovrebbe rilevare qualcos'altro come un attacco. Ma questo è solo il mio sogno, lontano dalla realtà. I portali in cattività esisteranno finché funzioneranno nella pratica.

Sfortunatamente, non c'è una soluzione perfetta qui, dato che lo scopo di TLS è proteggere da questo tipo di attacco. Ma penso che il modo migliore di procedere sia questo:

• Per le connessioni HTTPS, è sufficiente bloccarle. Non provare a reindirizzare. Ciò fornirà all'utente un messaggio di errore che indica l'assenza di accesso a Internet piuttosto che un avviso di sicurezza. È meglio.

• Per le connessioni HTTP, dovresti rispondere con 511 Autenticazione di rete richiesta :

  The 511 status code indicates that the client needs to authenticate to gain network access.

  [...]

  The 511 status SHOULD NOT be generated by origin servers; it is intended for use by intercepting proxies that are interposed as a means of controlling access to the network.