Ho una configurazione del captive portal per la mia organizzazione che obbliga gli utenti all'autenticazione prima di poter accedere alla rete. La sfida è che quando un utente apre il suo browser e la sua homepage è https (es. link ) e reindirizzo il traffico a http://myportal.company.com dell'utente finale riceve un errore
Dato che il web ha sempre più valore su HTTPS (che è buono!) ora mi sta causando un problema.
Che opzioni ho?
Un portale captive sta essenzialmente facendo un uomo nell'attacco centrale. HTTPS e altri protocolli che utilizzano SSL / TLS sono esplicitamente in grado di rilevare e prevenire tali attacchi di tipo "uomo medio". Questo ti lascia due scelte: non fare un uomo nell'attacco centrale o fare in modo che il cliente si fidi dell'uomo nel mezzo. Tutte le soluzioni completamente trasparenti richiedono il controllo del cliente.
Affidarsi all'uomo in mezzo è in molti casi possibile se è possibile aggiungere l'uomo nella CA centrale del captive portal come affidabile per il client. In alcuni sistemi come Windows questo può essere fatto in modo automatico (criterio di gruppo). Se i browser vedranno che il certificato è firmato da questa CA aggiunta in modo esplicito, disabiliteranno anche il controllo del pinning della chiave pubblica (HPKP esplicito e incorporato). Ma nota che non funzionerà in tutti i casi, cioè ci sono applicazioni non-browser come Dropbox che continuano a fare il pinning del certificato e quindi non funzioneranno più.
Gli attacchi di non fare un uomo nel mezzo funzionano se si configura il captive portal come proxy esplicito nel client. Se la configurazione automatica del proxy è abilitata nel client, è possibile farlo con un server WPAD, può essere configurato con criteri di gruppo o deve essere configurato manualmente. Con un proxy è possibile richiedere l'autenticazione. Ma sei limitato all'autenticazione di base (nome utente e password) o all'autenticazione trasparente tramite NTLM. Non è possibile per prima cosa presentare al cliente alcune informazioni che deve accettare. L'autenticazione proxy funziona anche se il client sa che sta parlando con un proxy. Basta intercettare il normale traffico HTTP / HTTPS e inviare una richiesta di autenticazione proxy non funzionerà. Ciò significa anche che le applicazioni che non sono a conoscenza del proxy (ovvero non utilizzano le impostazioni di sistema) non funzioneranno.
E infine potresti abbandonare qualsiasi tentativo di reindirizzare l'utente e semplicemente pubblicare informazioni che descrivono che i client dovrebbero prima autorizzarsi usando un URL interno. Fino a quando ciò non viene fatto, qualsiasi accesso fallisce semplicemente e una volta che il client si è autorizzato, il MAC del client specifico è concesso per un po 'di tempo.
Se capisco la tua domanda, hai un server proxy che blocca l'accesso a Internet finché l'utente non si è autenticato. Con "blocchi" intendo: se il tuo proxy riceve una richiesta di link , falsificherà l'host richiesto (google.com) e restituirà un reindirizzamento 302 intestazione a una pagina di accesso che è ospitata sul proxy stesso. Questo è uno schema molto comune che può essere trovato nel wifi pubblico in McDondald's, Starbucks, ecc. Ed è anche piuttosto comune nelle impostazioni aziendali.
Il problema con questo è ovviamente lo spoofing. Lo spoofing di google.com causerà un errore di cert, sebbene (fino a poco tempo fa) l'utente potesse fare clic. L'introduzione di HSTS ora rende impossibile aggirare l'errore cert e passare alla pagina di accesso del proxy, e c'è poco un utente finale può fare per sovrascriverlo.
Come utente finale, ho riscontrato questo problema come un problema sempre più recente. Il modo in cui l'ho affrontato come utente finale è navigare in un sito che non ha HSTS (ad esempio CNN.com) o navigare per IP (ad esempio http://192.168.0.1 ). Anche questi verranno intercettati dal proxy ma posso aggirare eventuali errori di cert.
Credo che il modo "corretto" per un server proxy di richiedere l'autenticazione non sia con un reindirizzamento 302 ma con un HTTP 407 Status Code che significa" richiesta l'autenticazione proxy ". Il proxy dovrebbe rispondere con questa intestazione invece del reindirizzamento 302. Il browser dovrebbe sapere come interpretare l'HTTP 407 e presentare un dialogo appropriato per la raccolta di nome utente e password.
Seconda opzione .... Se si tratta di una rete aziendale e si è in grado di spingere i criteri di gruppo, è possibile utilizzarla per imposta la home page del browser sulla pagina di login del proxy, eliminando così la necessità di reindirizzamenti.
Chrome rileva captive portal:
When a main frame HTTPS load is taking a while, we preemptively open a background request for http://www.gstatic.com/generate_204
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.
Leggi altre domande sui tag tls certificates url-redirection captive-portal