Il protocollo HTTPS è equivalente all'uso di HTTP su una connessione SSL o TLS (su TCP).

Quindi, prima un La connessione TCP (sulla porta 443) è aperta al server. Questo di solito è sufficiente per rivelare il nome host del server (ad esempio www.mysite.com nel tuo caso) all'aggressore. L'indirizzo IP viene osservato direttamente e:

1. di solito hai eseguito una query DNS non crittografata in precedenza,
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, con la quale il client indica al server di cui si desidera il nome host, in modo che il server possa presentare il certificato corretto, se ne ha più. (Questo viene fatto per poter andare via da 2.)

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

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

Ovviamente, poiché D.W. menziona, la lunghezza di entrambe le richieste (che non contiene molti più dati variabili dell'URL, forse alcuni cookie) e la risposta possono essere viste dal flusso di dati crittografati. Ciò potrebbe sovvertire la segretezza, specialmente se sul server è presente solo un piccolo numero di risorse diverse. Anche eventuali richieste di risorse di follow-up.

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

Come ti hanno detto @ Paŭlo Ebermann e @Jeff Ferland, la richiesta GET è crittografata sotto SSL e quindi è sicura. Tuttavia , non dimenticare che molti server web registrano richieste e parametri GET e qualsiasi credenziale o altra informazione sensibile inviata tramite GET potrebbe essere scritta in un registro da qualche parte. Per questo motivo, dovresti utilizzare POST (che sarà anche crittografato con SSL) quando invii dati sensibili.

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

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

Mi rendo conto che ciò contraddice quanto affermato da altre persone, quindi io è meglio spiegare.

È vero che tutto ciò che segue il nome di dominio viene inviato crittografato. Ad esempio, se l'URL è https://www.example.com/foo/bar.html , l'attaccante sarà visibile a www.example.com , 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 intercettatori. Inoltre, altre informazioni, come la lunghezza della pagina visitata, potrebbero essere visibili agli intercettatori. Questo è un piede nella porta per l'attaccante. Sono state effettuate alcune ricerche che utilizzano questo piede nella porta per scoprire quali URL stai visitando, se l'autore dell'attacco può intercettare il tuo traffico https.

Sebbene non sia garantito che questi attacchi avranno successo, suggerisco che sarebbe prudente presumere il peggio: presumere che un intercettatore possa essere in grado di apprendere quali URL stai visitando. Pertanto, non dovresti presumere che SSL / TLS nasconda a un intercettatore quali pagine stai visitando.

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

PS Un'altra avvertenza: in pratica, sslstrip e altri attacchi man-in-the-middle possono avere successo contro molti o la maggior parte degli utenti, se il sito web non utilizza HSTS. Questi 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 sicura (ad esempio, Wifi aperto), dovresti essere cauto che un utente malintenzionato potrebbe essere in grado di apprendere quali pagine gli utenti stanno visitando. Una mitigazione parziale contro la minaccia sslstrip è che gli utenti utilizzino HTTPS Everywhere e che i siti adottino HSTS.

Le seguenti cose trapeleranno prima dell'inizio della sessione:

• Indirizzo IP del server
• Certificato del server
  • Che includerà il dominio nome pubblicato sul certificato, anche se ciò non garantisce che corrisponderà a quello che hai usato.
• Le tue query DNS

Nessun dato o le richieste non correlate alla creazione della connessione SSL ( GET ... ) vengono inviate al server prima dell'inizio della sessione SSL. L'URL viene inviato come parte della richiesta della pagina e protetto come il 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 sta accedendo, soprattutto se si presume che i collegamenti in una pagina vengano cliccati. Google per "analisi del traffico ssl navigazione" o qualcosa di simile se l'argomento ti interessa.

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

Gli stack TLS stanno iniziando a inviare l'indicazione del nome del server (SNI, http://en.wikipedia.org/wiki/Server_Name_Indication; http://www.ietf.org/rfc /rfc3546.txt). Viene inviato in chiaro, il che significa che gli intercettatori possono vedere il nome del server digitato nella barra degli indirizzi.