Https crittografa l'intero URL?

Question

Ho cercato su Google molte e molte risposte sono Sì. Ad esempio: Is GET data also encrypted in HTTPS? Ma il senior security engineer della nostra azienda mi ha detto che l'URL non sarebbe stato crittografato.

Immagine che, se l'URL è stato crittografato, in che modo il server DNS trova l'host e si connette?

Penso che questo sia un punto molto forte sebbene sia contro la maggior parte delle risposte. Quindi sono davvero confuso e le mie domande sono:

1. Https crittografa tutto nella richiesta? (compresi URL, host, percorso, parametri, intestazioni)
2. In caso affermativo, in che modo il server DNS decodifica la richiesta e la invia al server host?

ho provato ad accedere https://www.amazon.com/gp/css/homepage.html/ref=ya_surl_youracct e il mio IE inviato due richieste al server:

Primo:

CONNECT www.amazon.com:443 HTTP/1.0 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Host: www.amazon.com 
Content-Length: 0 
DNT: 1 
Connection: Keep-Alive 
Pragma: no-cache 

Secondo:

GET /gp/css/homepage.html/ref=ya_surl_youracct HTTP/1.1 
Accept: text/html, application/xhtml+xml, */* 
Accept-Language: en-US,zh-CN;q=0.5 
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko 
Accept-Encoding: gzip, deflate 
Host: www.amazon.com 
DNT: 1 
Connection: Keep-Alive 

Sembra che il mio browser ha richiesto due volte : la prima volta è stabilire la connessione con l'host (senza crittografia) e la seconda volta inviare una richiesta crittografata su https? Ho ragione? Se sto capendo correttamente, quando un client chiama l'API RESTFUL usando https, invia le richieste (connessione e get/post) due volte ogni volta?

Answer 1

L'URL IS viene crittografato dal momento in cui lascia il browser fino a quando non raggiunge il server di destinazione.

Quello che succede è che il browser estrae il nome di dominio e la porta dall'URL e lo usa per risolvere il DNS stesso. Quindi avvia un canale crittografato sul server IP di destinazione: porta. Quindi invia una richiesta HTTP attraverso quel canale crittografato.

La parte importante è chiunque ma tu e il server di destinazione puoi solo vedere che ti stai connettendo a uno specifico indirizzo IP e porta. Non possono dire altro (come URL specifici, parametri GET, ecc.).

Gli aggressori non riescono nemmeno a vedere il dominio nella maggior parte dei casi (anche se possono dedurre se esiste effettivamente una ricerca DNS - se non è stato memorizzato nella cache).

La cosa importante da capire è che DNS (Domain Name Service) è un servizio completamente diverso con un protocollo diverso da HTTP. Il browser effettua richieste di ricerca DNS per convertire un nome di dominio in un indirizzo IP. Quindi usa quell'indirizzo IP per emettere una richiesta HTTP.

Ma in nessun momento il server DNS riceve una richiesta HTTP e in nessun momento fa effettivamente altro che fornire un nome di dominio - Mappatura IP per gli utenti.

Answer 2

L'URL (noto anche come "Uniform Resource Locator") contiene quattro parti:

1. protocollo (ad esempio HTTPS)
2. nome host (ad es stackoverflow.com)
3. Port (non sempre inclusa , tipicamente 80 per HTTP e 443 per HTTPS)
4. percorso e il nome del file o della query

Alcuni esempi:

ftp://www.ftp.org/docs/test.txt 
mailto:user@test101.com 
news:soc.culture.Singapore 
telnet://www.test101.com/ 

L'URL come un'intera unità non è effettivamente crittografato perché non viene passato nella sua interezza. L'URL viene effettivamente suddiviso in bit e ciascuna parte viene utilizzata in modi diversi. Per esempio. la porzione del protocollo dirà al tuo browser come usare il resto dell'URL, il nome dell'host gli dirà come cercare l'indirizzo IP del destinatario previsto e la porta gli dirà, beh, quale porta usare. L'unica parte dell'URL che viene passata nel payload stesso è il percorso e la query e quella parte è crittografata.

Se si dà un'occhiata a una richiesta HTTP in grezzo, sembra qualcosa di simile:

GET /docs/index.html HTTP/1.1 
Host: www.test101.com 
Accept: image/gif, image/jpeg, */* 
Accept-Language: en-us 
Accept-Encoding: gzip, deflate 
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) 
(blank line) 
--Body goes here-- 

Quello che si vede nell'esempio di cui sopra è passato. Si noti che l'URL completo non appare da nessuna parte. L'intestazione host può essere effettivamente omessa completamente (non viene utilizzata per il routing).L'unica parte dell'URL che appare qui è a destra del verbo GET e include solo la porzione più a destra dell'URL originale. Il protocollo e il numero di porta non compaiono da nessuna parte nel messaggio stesso.

Risposta breve: tutto a destra del numero di porta nell'URL è incluso nel carico utile della richiesta https ed è in effetti crittografato.

Answer 3

Mentre le altre risposte sono corrette fino a quel momento, ci sono molte altre considerazioni oltre alla semplice crittografia tra il browser e il server. Ecco alcune cose a cui pensare ...

• L'indirizzo IP del server è stato risolto.
• Il browser effettua una connessione socket TCP all'indirizzo IP del server utilizzando TLS. Questo è il CONNECT che vedi nell'esempio.
• La richiesta viene inviata al server tramite la sessione crittografata.

Se questo era tutto quello che c'è da fare, hai finito. Nessun problema.

Ma aspetta, c'è di più!

Avendo i campi in un GET invece di un POST rivela dati sensibili quando ...

• qualcuno guarda nei log dei server. Questo potrebbe essere un dipendente snoopy, ma può anche essere l'NSA o altre agenzie governative a tre lettere, oi registri potrebbero diventare record pubblici se citati in una prova.
• Un utente malintenzionato fa sì che la crittografia del sito Web ricada in testo non crittografato o crittografato. Dai uno sguardo a the SSL checker dai laboratori Qualsys per vedere se un sito è vulnerabile a questo.
• Qualsiasi collegamento sulla pagina a un sito esterno mostrerà l'URI della pagina come referrer. ID utente e password sono involontariamente ma comunemente dati via in questo modo alle reti pubblicitarie. A volte capisco questi nel mio blog.
• L'URL è disponibile nella cronologia del browser e quindi accessibile agli script. Se il computer è pubblico (qualcuno controlla il tuo sito web dal PC guest nella hall dell'hotel o dell'aeroporto) la richiesta GET invia dati a chiunque altro utilizzi quel dispositivo.

Come ho già detto, a volte trovo ID, password e altre informazioni sensibili nei log dei referrer dei miei blog. Nel mio caso, contatto il proprietario del sito di riferimento e informo che stanno esponendo i propri utenti all'hacking. Una persona meno scrupolosa aggiungerebbe commenti o aggiornamenti al sito con collegamenti al proprio sito Web, con l'intenzione di raccogliere i dati sensibili nei registri dei referrer.

Quindi il responsabile della sicurezza senior della vostra azienda ha ragione che l'URL non è crittografato in molti punti in cui è estremamente importante farlo. Tu e gli altri intervistati siete anche corretti che sia crittografato nel caso di uso molto stretto del browser che parla al server nel contesto di una sessione TLS. Forse la confusione che hai menzionato ha a che fare con la differenza nello scopo di questi due casi d'uso.

Si veda anche:

• Testing for Exposed Session Variables (OTG-SESS-004)
• Session Management - How to protect yourself (Si noti che "Usa sempre POST" si ripete più e più volte in questa pagina.)
• Client account hijacking through abusing session fixation on the provider