Diciamo che non mi sono mai connesso al sito example.com .
Se questo sito è https e scrivo https://example.com/supersecretpage l'URL verrà inviato in chiaro poiché è la prima volta che mi collego al sito e quindi le chiavi crittografiche non sono state ancora scambiate? Se non quando avviene? Qualcuno potrebbe spiegare i passaggi quando digito quell'URL?
Risposta breve: No, l'URL è crittografato, ma il dominio (secondario) viene inviato in testo semplice.
Nel tuo caso un attaccante (passivo) sa che ti stai connettendo a example.com , ma non sa quale pagina specifica stai accedendo.
In breve, ci sono tre volte in cui un utente malintenzionato può ottenere informazioni sul sito a cui si sta accedendo (in ordine cronologico):
Tuttavia il ...
Per maggiori dettagli leggi la spiegazione di seguito.
Nota: quando scrivo "(sub) dominio", intendo sia il dominio ( example.com ) che il sottodominio ( mydomain.example.com ). Quando scrivo solo "dominio", intendo solo il dominio ( example.com ) senza il sottodominio.
Fondamentalmente ciò che accade è:
example.com può anche includere www.example.com , devserver.example.com e how-to-develop-tls.example . Queste voci sono chiamate Nomi alternativi oggetto e il certificato è valido per tutti loro. Dopo che tutto ciò è successo, viene inviata una "normale" richiesta HTTP (sul canale TLS protetto). Ciò significa che questa è la prima volta nell'intera richiesta in cui viene visualizzato URL completo . La richiesta, ad es. assomiglia a questo:
GET /supersecretpage HTTP/1.1
Host: example.com
[...]
* Se il certificato è un certificato jolly, non include i sottodomini, ma solo *.example.com .
Un'altra cosa vale la pena menzionare: prima che la connessione possa essere stabilita, tutto il client deve risolvere il nome DNS. Per fare ciò invia query DNS non crittografate a un server DNS e queste contengono anche il (sotto) dominio , che può quindi essere utilizzato da un utente malintenzionato per vedere i domini visitati .
Tuttavia questo non deve sempre accadere in questo modo, perché si presuppone che l'utente digiti manualmente in https://example.com/supersecretpage nella barra degli URL. Ma questo è molto raro come la maggior parte degli utenti, ad es. preferirebbe digitare example.com/supersecretpage . Un altro problema potrebbero essere i visitatori che fanno clic su un link non sicuro , che utilizza HTTP - in contrasto con un collegamento HTTPS sicuro ). Tali collegamenti potrebbero ad es. essere vecchi collegamenti creati quando il sito non supportava HTTPS o non ha reindirizzato a HTTPS per impostazione predefinita.
Mi chiedi perché questo è importante?
In questo caso (normale) non c'è https:// nell'URL. Quando nessun protocollo viene inserito nella barra degli URL tutti i browser internamente "convertono" questo URL in http://example.com/supersecretpage (notare il link ) in quanto non possono aspettarsi che il server supporti HTTPS.
Ciò significa che il browser tenta innanzitutto di connettersi al sito Web utilizzando HTTP non sicuro e solo dopo che il sito Web invia un reindirizzamento (301) all'URL HTTPS che utilizza la modalità protetta.
In questo caso, l'autore dell'attacco può visualizzare l'URL completo nella richiesta HTTP non crittografata.
Puoi testarlo da solo esaminando il "pannello di rete" del tuo browser. Dovresti vedere questo "upgrade HTTPS":
Tuttavia, si noti che esistono tecniche per impedire questa prima richiesta HTTP non sicura. In particolare HSTS e - per proteggere anche la prima connessione che fai al sito - precarico HSTS , ma anche HTTPS Ovunque aiuta contro tali attacchi. A proposito: Secondo Netcraft 95 % di tutti i server HTTPS vulnerabili erano vulnerabili a tali attacchi (stripping SSL) a partire da marzo 2016.
No, l'URL non verrà inviato in chiaro.
Immediatamente dopo il completamento dell'handshake a tre vie TCP, il client avvia la negoziazione TLS con il server. Solo dopo che la negoziazione è completa e la crittografia è attiva, viene inviata la richiesta HTTP.
Poiché non hai mai visitato il sito www.example.com, il tuo browser deve risolvere il nome del dominio in indirizzo IP. Quindi, invia una query di risoluzione DNS che contiene il nome di dominio del sito a cui si sta tentando di connettersi. Quindi un MITM può scoprire quale dominio si sta tentando di connettersi a meno che non si usi il DNS sicuro.