Anche i dati GET sono crittografati in HTTPS?

Risposte:

146

L'intera richiesta è crittografata, incluso l'URL e persino il comando (GET ). L'unica cosa che una parte interveniente come un server proxy può raccogliere è l'indirizzo e la porta di destinazione.

Si noti, tuttavia, che il pacchetto Client Hello di una stretta di mano TLS può pubblicizzare il nome di dominio completo in testo normale tramite l' estensione SNI (grazie a @hafichuk), che viene utilizzato da tutti i browser mainstream moderni, sebbene alcuni solo su sistemi operativi più recenti.

EDIT: (Dal momento che questo mi ha appena ottenuto un badge "Buona risposta", immagino che dovrei rispondere all'intera domanda ...)

L'intera risposta è anche crittografata; i proxy non possono intercettarne alcuna parte.

Google offre ricerche e altri contenuti su https perché non tutto è pubblico e potresti anche voler nascondere parte del contenuto pubblico da un MITM . In ogni caso, è meglio lasciare che Google risponda da solo .

— Marcelo Cantos
fonte
2
Sono un po 'scontento dell'affermazione che l'URL è crittografato. Il nome host non è considerato parte dell'URL? In tal caso, l'affermazione è errata. Non è possibile nascondere il nome host / indirizzo IP dall'ISP / server proxy nello stesso modo in cui non è possibile nascondere l'indirizzo di destinazione durante l'invio di posta fisica.
— Abhishek Anand,
1
@Abhishek: il nome host non è presente nell'intestazione TCP / IP. Copro gli indirizzi IP nella mia risposta.
— Marcelo Cantos,
Il dominio non è crittografato. Questo serve a supportare host virtuali basati sul nome (rispetto all'IP). @MarceloCantos ha perfettamente ragione che il resto dell'URL (ovvero il GETcomando) è crittografato. Questo è coperto in RFC 4366
— hafichuk, l'
@hafichuk: grazie per quello. Non mi ero reso conto che TLS potesse pubblicizzare il fqdn. L'ultima volta che ho provato a installare un multiserver https (diversi anni fa, lo ammetto), sembrava impossibile su un singolo IP.
— Marcelo Cantos,
Aggiunta davvero importante al TLS contenente il nome di dominio: non dimenticare la richiesta DNS in chiaro che include anche il nome di dominio. È probabile che qualcuno che possa vedere il tuo traffico HTTPS crittografato possa anche guardare le tue richieste DNS.
— Tim G
63

L'URL stesso è crittografato, quindi i parametri nella stringa di query non viaggiano in chiaro attraverso il filo.

Tuttavia, tieni presente che gli URL, inclusi i dati GET, vengono spesso registrati dal server web, mentre raramente i dati POST lo sono. Quindi, se hai intenzione di fare qualcosa del genere /login/?username=john&password=doe, allora non farlo; usa invece un POST.

— Tommaso
fonte
2
+1 grazie. Questo è sul mio server fisico, quindi non sono troppo preoccupato per i log, ma è una buona considerazione per chiunque lo consideri in un ambiente di hosting condiviso. È anche importante considerare perché trasferirò i numeri di carta di credito in questo modo e sicuramente non vorrò registrarli :)
— orokusaki,
3
Non importa che sia la tua scatola. Non vuoi che nessun altro lo possieda (ad es. Hacker malvagi) veda quelle password in chiaro. O quei numeri CC (supponendo che non li stia memorizzando anche altrove).
— Thomas,
1
Dovresti inserirli nel corpo POST, non nella stringa di query URL.
— Thomas,
1
Hai paura che il server Web abbia meno restrizioni sull'accesso ai suoi registri rispetto all'accesso ai dati del sito Web (DB, file, ecc.)? IMHO fintanto che i dati accedono in modo sicuro al server web, tutto va bene. le uniche persone che hanno accesso al server web dovrebbero essere considerate affidabili perché se non lo sono, impedirai loro di leggere i dati in un modo o nell'altro.
— Serge Profafilecebook,
1
Quando le password vengono inviate tramite GET e vengono registrate nel registro di accesso, NON vengono hash. Credo che sia il problema più grande. Avere le password con hash nel database non importa se puoi semplicemente cercarle nel registro di accesso del server web. Dovrebbero essere sottoposti a hash nel database, in caso contrario, correggilo.
— Steen Schütt,
21

HTTPS Stabilisce una definizione SSL sottostante prima che vengano trasferiti tutti i dati HTTP. Ciò garantisce che tutti i dati URL (ad eccezione del nome host, utilizzato per stabilire la connessione) siano trasportati esclusivamente all'interno di questa connessione crittografata e siano protetti dagli attacchi man-in-the-middle nello stesso modo in cui lo sono tutti i dati HTTPS.

Quanto sopra fa parte di una risposta MOLTO completa da Google Answers che si trova qui:

http://answers.google.com/answers/threadview/id/758002.html#answer

— DVK
fonte
6

Tutto è crittografato, ma è necessario ricordare che la query rimarrà nei registri del server e sarà accessibile a vari analizzatori di registri ecc. (Che di solito non è il caso della richiesta POST).

— Eugene Mayevski 'Callback
fonte
1
quali server? accessibile a chi?
— Jader Dias,
2
@Jader almeno agli amministratori di quei server e agli hacker. Con la richiesta POST le informazioni non rimangono nei registri, quindi a meno che non vengano registrate in modo esplicito, non vi sono problemi con i registri. OTTENERE le query rimangono nei registri e se qualunque cosa accada con il registro (o l'amministratore decide di utilizzare questi registri per eventuali attività non valide), ci si trova in difficoltà.
— Eugene Mayevski 'Callback,
4

La connessione viene crittografata prima della trasmissione della richiesta. Quindi sì, anche la richiesta è crittografata, inclusa la stringa di query.

— CHAO
fonte
4

Sì, è sicuro. SSL crittografa tutto.

Estratto dalla richiesta POST:

POST /foo HTTP/1.1
... some other headers

Estratto dalla richiesta GET:

GET /foo?a=b HTTP/1.1
... some other headers

In entrambi i casi, tutto ciò che viene inviato sul socket è crittografato. Il fatto che il client veda i parametri nel suo browser durante una richiesta GET non significa che un uomo nel mezzo vedrebbe lo stesso.

— Darin Dimitrov
fonte
4

Mi sono appena connesso tramite HTTPS a un sito Web e ho passato un sacco di parametri GET. Ho quindi usato WireShark per annusare la rete. Usando HTTP, l'URL viene inviato non crittografato, il che significa che posso facilmente vedere tutti i parametri GET nell'URL. Usando HTTPS, tutto è crittografato e non riesco nemmeno a vedere quale pacchetto è il comando GET, per non parlare del suo contenuto!

— Jeff Lamb
fonte
3

L'SSL ha luogo prima dell'analisi dell'intestazione, questo significa:

Client creates Request
Request gets encrypted
Encrypted request gets transmitted to the Server
Server decrypts the Request
Request gets parsed

Una richiesta è simile a questa (non ricordo l'esatta sintassi, ma dovrebbe essere abbastanza vicina):

GET /search?q=qwerty HTTP/1.1
Host: www.google.de

Questo è anche il motivo per cui avere diversi certificati SSL per più host sullo stesso IP è problematico, il nome host richiesto non è noto fino alla decodifica.

— Morfildur
fonte
1
Il HTTP/1.1arriva alla fine della prima riga.
— Marcelo Cantos,
@Marcelos Cantos: Grazie, è da un po 'che non scrivo richieste HTTP a mano.
— Morfildur,
0

La richiesta GET viene crittografata quando si utilizza HTTPS - in effetti questo è il motivo per cui i siti Web protetti devono avere un indirizzo IP univoco - non è possibile ottenere il nome host (o la directory virtuale) desiderato dalla richiesta fino a quando non viene decrittografato.

— Michael Burr
fonte
JFYI: esiste un'estensione TLS che consente al client di specificare il nome host e quindi il server può scegliere il certificato corrispondente.
— Eugene Mayevski 'Callback
@Eugene: Grazie - Sono a conoscenza dell'estensione TLS, ma solo nel senso più totale di consapevolezza - Non so nulla dei dettagli o di quanto ampiamente (o potrebbe) essere in uso.
— Michael Burr,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.