I dati GET vengono anche crittografati in HTTPS?

Quando avrai

https://encrypted.google.com/search?q=%s

La query %s è crittografata? O solo la risposta? Se non lo è, perché Google dovrebbe pubblicare il suo contenuto pubblico anche con la crittografia?

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

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

EDIT: (Dato che questo mi ha appena ottenuto un badge “Buona risposta”, suppongo che dovrei rispondere all’intera domanda …)

Anche l’intera risposta è crittografata; i proxy non possono intercettare nessuna parte di esso.

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

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 i dati POST sono raramente. Quindi se hai intenzione di fare qualcosa come /login/?username=john&password=doe , allora non farlo; usa invece un POST.

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

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

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

La parte dell’URL dopo il nome host viene inviata in modo sicuro.

Ad esempio, https://somewhere.com/index.php?NAME=FIELD

La parte /index.php?NAME=FIELD è crittografata. Il somewhere.com non lo è.

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

La connessione viene crittografata prima che la richiesta venga trasmessa. Quindi sì, anche la richiesta è crittografata, inclusa la stringa di query.

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 appare come questa (non ricordo la syntax esatta, ma dovrebbe essere abbastanza vicina):

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

Questo è anche il motivo per cui i diversi certificati SSL per diversi host sullo stesso IP sono problematici, il nome host richiesto non è noto fino alla decrittografia.

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.

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 criptato, 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, tanto meno il suo contenuto!

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 è ansible ottenere il nome host desiderato (o la directory virtuale) dalla richiesta fino a quando non viene decodificato.