SSL / TLS (https) nasconde gli URL a cui si accede [duplicato]

Il protocollo HTTPS equivale a utilizzare HTTP su un SSL o TLS connessione (su TCP).

Quindi, prima una connessione TCP (sulla porta 443) è aperta al server. Di solito questo è sufficiente per rivelare il nome host del server (cioè www.mysite.com nel tuo caso) all'autore dell'attacco. L'indirizzo IP viene osservato direttamente e:

1. di solito hai fatto una query DNS non criptata prima
2. molti server HTTPS servono solo un dominio per indirizzo IP,
3. Il certificato del server viene inviato in chiaro e contiene il nome del server (tra più, forse),
4. nelle versioni TLS più recenti, c'è l'indicazione del nome del server, tramite la quale il client indica al server quale nome host è desiderato, in modo che il server possa presentare il certificato giusto, se ne ha di più. (Questo è fatto per essere in grado di andare via da 2).

Quindi avviene un handshake TLS. Ciò include la negoziazione di una suite di crittografia e quindi uno scambio di chiavi. Supponendo che almeno uno del tuo browser e il server non includessero il NONE cipher nelle suite accettate, tutto ciò che segue lo scambio di chiavi è crittografato.

E supponendo che non ci sia un attacco man-in-the-middle di successo (cioè un attaccante che intercetta la connessione e presenti un certificato server contraffatto accettato dal browser), lo scambio di chiavi è sicuro e nessun intercettatore può decifrare nulla che viene quindi inviato tra te e il server, e inoltre nessun utente malintenzionato può modificare qualsiasi parte del contenuto senza che questo venga notato. Ciò include l'URL e qualsiasi altra parte della richiesta HTTP, nonché la risposta dal server.

Naturalmente, come D.W. menziona, la lunghezza di entrambe le richieste (che contiene non molto più dati variabili dell'URL, forse alcuni cookie) e la risposta può essere vista dal flusso di dati crittografati. Questo potrebbe sovvertire la segretezza, specialmente se sul server c'è solo un piccolo numero di risorse differenti. Anche eventuali richieste di risorse di follow-up.

La tua password nell'URL (o in qualsiasi altra parte della richiesta) dovrebbe comunque essere sicura, ma al massimo la sua lunghezza può essere conosciuta.

Come hanno detto @ Paŭlo Ebermann e @Jeff Ferland, la richiesta GET è crittografata in SSL e quindi è sicura. Tuttavia , non dimenticare che molti server Web registrano richieste e parametri GET e qualsiasi credenziale o altre informazioni sensibili inviate tramite GET potrebbero essere scritte in un registro da qualche parte. Per questo motivo, è necessario utilizzare POST (che verrà crittografato anche in SSL) quando si inviano dati sensibili.

Questo rientra nella categoria di "crittografia non è la sicurezza magica che risolve tutti i tuoi problemi".

Dovresti presumere che l'URL non sia protetto, cioè che un intercettatore passivo possa essere in grado di sapere quale URL stai visitando.

Mi rendo conto che ciò contraddice ciò che sostengono alcune altre persone, quindi è meglio che lo spieghi.

È vero che tutto ciò che segue il nome del dominio viene inviato crittografato. Ad esempio, se l'url è https://www.example.com/foo/bar.html , allora www.example.com è visibile per l'utente malintenzionato, mentre la richiesta HTTP ( GET /foo/bar.html HTTP/1.0 ) è crittografata. Ciò impedisce a un intercettatore di vedere direttamente la parte del percorso dell'URL. Tuttavia, la lunghezza della parte del percorso dell'URL potrebbe essere visibile agli utenti maltrattati. Inoltre, altre informazioni, come la lunghezza della pagina che hai visitato, potrebbero anche essere visibili agli intercettori. Questo è un piede nella porta per l'attaccante. C'è stato qualche ricerca che utilizza questo piede nella porta per scoprire quali URL stai visitando , se l'utente malintenzionato può origliare il tuo traffico https.

Anche se non vi è alcuna garanzia che questi attacchi avranno successo, suggerisco che sarebbe prudente assumere il peggio: assumere che un intercettatore possa essere in grado di sapere quali URL si stanno visitando. Pertanto, dovresti non presumere che SSL / TLS nasconda da un utente che intercetta le pagine che stai visitando.

Sì, https fornisce integrità per l'URL che hai visitato.

P.S. Un altro avvertimento: in pratica, sslstrip e altri attacchi man-in-the-middle potrebbero avere successo contro molti o la maggior parte degli utenti, se il sito web non sta usando HSTS . Tali attacchi possono violare sia la riservatezza che l'integrità dell'URL. Pertanto, se gli utenti visitano siti Web che non utilizzano HSTS su una rete non protetta (ad es., WiFi aperto), dovresti diffidare che un utente malintenzionato sia in grado di sapere quali pagine gli utenti stanno visitando. Una riduzione parziale contro la minaccia sslstrip è per gli utenti di uso HTTPS Ovunque e per i siti di adottare HSTS.

Le seguenti cose si verificheranno prima dell'inizio della sessione:

• Indirizzo IP del server
• Certificato del server
  • Questo includerà il nome di dominio pubblicato sul certificato, anche se questo non garantisce che corrisponda a quello che hai usato.
• Le tue query DNS

Nessun dato o richiesta non correlata alla creazione della connessione SSL ( GET ... ) viene inviata al server prima che inizi la sessione SSL. L'URL viene inviato come parte della richiesta di pagina e protetto come qualsiasi traffico che fa parte della sessione.

Sì e no.

L'url è crittografato correttamente, quindi i parametri di query non dovrebbero mai essere rivelati direttamente.

Tuttavia, l'analisi del traffico può ottenere spesso la lunghezza dell'URL e conoscere il server e la lunghezza dell'URL è spesso sufficiente per intercettare le pagine a cui si accede, soprattutto se si presume che i collegamenti su una pagina siano cliccati. Google per "analisi del traffico ssl browsing" o qualcosa di simile se l'argomento ti interessa.

Nel tuo caso d'uso questo è di importanza marginale. L'uso intelligente dell'analisi del traffico può rivelare la lunghezza del nome utente e / o della lunghezza della password, a seconda che gli altri URL recuperati contengano anche il nome utente. Se si sostituiscono il nome utente / password a una lunghezza costante, è possibile evitare questi attacchi, ma potrebbe non valere la pena.

Gli stack TLS stanno iniziando a inviare l'indicazione del nome del server (SNI, link ; link ). Ciò viene inviato in chiaro, nel senso che gli intercettatori possono vedere il nome del server digitato nella barra degli indirizzi.