Come gli hotspot Wifi legittimi reindirizzano le richieste https

La maggior parte degli hotspot reindirizza con certificati non validi.

Browser / OS utilizza l'euristica per rilevare tale comportamento.

This determination of being in a captive portal or being online is done by attempting to retrieve the webpage http://clients3.google.com/generate_204

link

MacOS e iOS utilizzano il link (grazie a @ceejayoz)

Ad esempio, Android visualizzerà una notifica per reindirizzare l'utilizzo alla pagina di accesso del portale.

Molti di loro usano solo il proprio certificato di hotspot e sperano che gli utenti facciano clic sull'avviso e si colleghino comunque. Personalmente quando vedo un avviso simile e so che è un captive portal, annullo la richiesta e digito un URL HTTP Non mi interessa come http://redirect.me.away e lascia che il portale faccia il suo lavoro su HTTP . Una volta effettuato l'accesso, riprovo la richiesta HTTPS che ora funziona.

Il più delle volte, li evito però - riempire i loro stupidi moduli di iscrizione non vale la pena il mio tempo, soprattutto data la scarsa connessione che offrono. Forse un giorno avremo una rete di hotspot EAP-Enterprise in cui ti registri una volta e poi il tuo dispositivo si connette automaticamente con un nome utente / password e tutto funziona perfettamente in background.

C'è una cosa che la rete captive non può fare: reindirizzare alla sua pagina mentre restituisce il certificato server corretto. In linea di principio, ci sono quelle possibilità: (a) non reindirizzare affatto https. (b) reindirizzamento con un certificato autofirmato. (c) restituisce il proprio certificato, quindi la negoziazione https fallirà. (d) uccide immediatamente qualsiasi tentativo di connessione con https.

Da quando ho cambiato il codice di rete su iOS da http a https, ho trovato più di una rete in cattività che uccide immediatamente qualsiasi tentativo di connessione. Sarebbe un'indicazione piuttosto strong per un'applicazione che esiste una rete captive. L'applicazione può quindi utilizzare un rilevamento migliore visitando uno degli URL di Google o di Apple forniti a tale scopo e se non rispondono come previsto, allora si dispone sicuramente di una rete captive. L'applicazione può andare da lì e avviare un browser o consentire all'utente di accedere alle impostazioni.

Non so cosa facciano esattamente i browser, ma possono rilevare che https è stato rifiutato e visitare automaticamente una pagina http che va al sito di accesso.

I portali in cattività agiscono essenzialmente come un man-in-the-middle, reindirizzando le richieste dei client verso un sito diverso (la loro pagina di accesso). Tecnicamente si tratta dello stesso tipo di comportamento che HTTPS tenta di impedire, perché è ciò che fanno i malintenzionati sulle connessioni HTTP non protette.

Pertanto, quando è possibile connettersi a un sito HTTPS da un captive portal senza un avviso e senza aver effettuato prima l'accesso al portale, è avvenuto uno dei seguenti eventi:

1. Il captive portal non intercetta il traffico SSL ma lo consente. Di conseguenza, viene visualizzata immediatamente la pagina di destinazione, senza mai aver effettuato l'accesso. Tuttavia, dal punto di vista del provider, ciò in gran parte vanifica lo scopo di avere un captive portal in primo luogo.
2. Una delle CA nell'elenco di CA attendibili o una CA subordinata verificata (direttamente o indirettamente) da una di queste CA radice è canaglia (o viene violata, anche se quest'ultima è improbabile se l'operatore WiFi è addirittura remoto ). Di conseguenza, l'hotspot dispone di un certificato con caratteri jolly (corrispondente a qualsiasi nome di server) o può emettere certificati arbitrari accettati dal browser. Di conseguenza, si digita un URL HTTPS e si ottiene invece la pagina di accesso senza alcun avviso.

Il secondo esempio è una debolezza intrinseca nella progettazione dei certificati: il tuo fornitore di browser / sistema operativo (o, nel caso di dispositivi aziendali, l'amministratore di sistema) ha distribuito un certificato CA sulla macchina, sostanzialmente affermando che "questa CA non emettere mai certificati per nessun server a nessuno che non sia l'operatore legittimo di quel server). A meno che tu non verifichi manualmente ciascuna CA e rimuova quelle discutibili (che è quasi impraticabile per un individuo), ti stai fidando ciecamente delle loro asserzioni.

Se nessuno dei due casi precedenti si applica, potrebbe verificarsi una delle seguenti condizioni:

1. La connessione fallirebbe (a causa di un server non raggiungibile) fino a quando non ti connetti a un semplice server HTTP, tieni reindirizzato alla pagina di accesso e accedi
2. Verrà visualizzato un avviso relativo a un certificato non valido: il nome del server non corrisponde o il certificato non proviene da una CA attendibile. Se ignori questo avviso, otterrai la pagina di accesso.