Le intestazioni HTTPS sono crittografate?


600

Quando si inviano dati tramite HTTPS, so che il contenuto è crittografato, tuttavia sento risposte contrastanti sul fatto che le intestazioni siano crittografate o la quantità di intestazione crittografata.

Quante delle intestazioni HTTPS sono crittografate?

Compresi URL di richiesta GET / POST, cookie, ecc.


9
Le intestazioni HTTP su HTTPS sono crittografate e anche non compresse con HTTP (anche se il corpo è). Ciò li rende meno vulnerabili agli attacchi legati alla compressione come BEAST
Neil McGuigan,

Risposte:


552

L'intero lotto è crittografato - tutte le intestazioni. Ecco perché SSL su vhosts non funziona troppo bene: è necessario un indirizzo IP dedicato perché l'intestazione dell'host è crittografata.

Lo standard SNI (Server Name Identification) indica che il nome host potrebbe non essere crittografato se si utilizza TLS. Inoltre, indipendentemente dal fatto che si stia utilizzando SNI o meno, le intestazioni TCP e IP non vengono mai crittografate. (Se lo fossero, i pacchetti non sarebbero instradabili.)


3
@Greg, Poiché il gateway vhost è autorizzato, il gateway non è riuscito a decodificarli, osservare l'intestazione Host, quindi determinare a quale host inviare i pacchetti?
Pacerier,

2
L'URL Afaik stesso non è crittografato.
Teddy,

4
@Teddu cosa intendi per "URL stesso non crittografato". È crittografato, in quanto fa parte dell'intestazione.
Dmitry Polushkin,

1
Se Fiddler viene utilizzato per catturare la comunicazione https, mostra comunque alcune intestazioni, perché? Soprattutto, quando la connessione Internet è tramite un proxy che richiede l'autenticazione, visualizza l'intestazione Proxy-Authorization quando la richiesta viene rinviata dopo aver ricevuto 407 al primo invio.
Bochen Lin

1
@Bochen allo stesso modo di Pegasus. Se ti trovi alle due estremità del tunnel HTTPS, puoi vedere tutto. Allo stesso modo posso vedere qualsiasi cosa nei browser devtools.
Nux,

97

Le intestazioni sono interamente crittografate. Le uniche informazioni che vanno in rete "in chiaro" sono legate alla configurazione SSL e allo scambio di chiavi D / H. Questo scambio è progettato con cura per non fornire alcuna informazione utile agli intercettatori e, una volta effettuato, tutti i dati vengono crittografati.


4
Non tutte le impostazioni SSL coinvolgono DH
Dori

30
Per essere un po 'pedanti: l'indirizzo IP del client e del server, il nome host del server e i segnali sulle loro implementazioni SSL sono utili per gli intercettatori e sono visibili.
poolie,

66

Nuova risposta alla vecchia domanda, scusa. Ho pensato di aggiungere i miei $ 0,02

L'OP ha chiesto se le intestazioni fossero crittografate.

Sono: in transito.

NON lo sono: quando non in transito.

Quindi, l'URL del browser (e il titolo, in alcuni casi) può visualizzare la stringa di query (che di solito contiene i dettagli più sensibili) e alcuni dettagli nell'intestazione; il browser conosce alcune informazioni di intestazione (tipo di contenuto, unicode, ecc.); e la cronologia del browser, la gestione delle password, i preferiti / i segnalibri e le pagine memorizzate nella cache conterranno tutte la stringa di query. I log del server sull'estremità remota possono anche contenere querystring e alcuni dettagli del contenuto.

Inoltre, l'URL non è sempre sicuro: il dominio, il protocollo e la porta sono visibili, altrimenti i router non sanno dove inviare le richieste.

Inoltre, se hai un proxy HTTP, il server proxy conosce l'indirizzo, di solito non conoscono la stringa di query completa.

Quindi, se i dati si spostano, sono generalmente protetti. Se non è in transito, non è crittografato.

Per non scegliere, ma anche i dati alla fine vengono decifrati e possono essere analizzati, letti, salvati, inoltrati o eliminati a piacimento. Inoltre, il malware alle due estremità può acquisire istantanee di dati che entrano (o escono) dal protocollo SSL - come Javascript (non valido) all'interno di una pagina all'interno di HTTPS che può effettuare surrettiziamente chiamate HTTP (o https) a siti Web di registrazione (dal momento che l'accesso al disco rigido locale è spesso limitato e non utile).

Inoltre, i cookie non sono crittografati nemmeno sotto il protocollo HTTPS. Gli sviluppatori che desiderano archiviare dati sensibili nei cookie (o in qualsiasi altro luogo) devono utilizzare il proprio meccanismo di crittografia.

Per quanto riguarda la cache, i browser più moderni non memorizzano nella cache le pagine HTTPS, ma questo fatto non è definito dal protocollo HTTPS, dipende interamente dallo sviluppatore di un browser per essere sicuri di non memorizzare nella cache le pagine ricevute tramite HTTPS.

Quindi, se sei preoccupato per lo sniffing dei pacchetti, probabilmente stai bene. Ma se sei preoccupato per il malware o qualcuno che ti fa scorrere la cronologia, i segnalibri, i cookie o la cache, non sei ancora fuori dall'acqua.


20
So che le buone risposte sono in cima, ma questo inserisce ancora una volta informazioni errate . Il dominio non è visibile, a meno che non venga utilizzato SNI. Protocollo diverso da IP e TCP non sono visibili. Non puoi dire se sto usando HTTP 1.1, SPDY o HTTP2. Ciò che è visibile sui due endpoint è irrilevante, poiché l'obiettivo della crittografia non è quello di rendere le cose invisibili ma di renderle visibili solo alle parti fidate. Quindi gli endpoint sono impliciti nella domanda e circa 2/3 della risposta possono essere rimossi. Le informazioni del proxy dovrebbero essere: se usi un proxy HTTPS, allora ha accesso a tutto .
Melvyn,

6
Il tuo link afferma specificamente che i cookie sono crittografati: "La connessione del visitatore è crittografata, oscurando URL, cookie e altri metadati sensibili".
DylanYoung,

1
Si, è corretto. I cookie vengono crittografati durante il trasporto, ma una volta raggiunti il ​​browser non vengono crittografati dal protocollo SSL. È possibile per uno sviluppatore crittografare i dati dei cookie, ma ciò non rientra nell'ambito di applicazione di SSL.
Andrew Jennings,

4
@DylanYoung SSL = livello socket sicuro ; TLS = sicurezza del livello di trasporto . La crittografia è a livello di socket (connessione) o per dirla in altro modo a livello di trasporto non mentre è memorizzata nel browser per database di dominio.
curiousguy,

@Wigwam I cookie HTTP sensibili alla sicurezza sono quasi sempre riferimenti opachi (di solito è un numero casuale crittograficamente forte) a un record nel database del server di sessioni autenticate. In quanto tale crittografia questo identificatore insignificante porterebbe principalmente ulteriore complessità.
curiousguy,

53

La versione 1.1 di HTTP ha aggiunto un metodo HTTP speciale, CONNECT, destinato a creare il tunnel SSL, incluso l'handshake del protocollo e la configurazione crittografica necessari.
Le richieste regolari da allora in poi vengono tutte inviate nel tunnel SSL, nelle intestazioni e nel corpo inclusi.


Quando viene utilizzato CONNECT per creare il tunnel SSL?
curiousguy,


47

Con SSL la crittografia è a livello di trasporto, quindi ha luogo prima dell'invio di una richiesta.

Quindi tutto nella richiesta è crittografato.


Poiché SSL avviene nel livello di trasporto e l'assegnazione dell'indirizzo di destinazione nei pacchetti (nell'intestazione) avviene nel livello di rete (che è al di sotto del trasporto), come vengono crittografate le intestazioni?
Prateek Joshi,

@PrateekJoshi Perché le intestazioni HTTP vivono sul livello dell'applicazione e quindi, per impostazione predefinita, sono crittografate a causa della crittografia di un livello inferiore / antenato.
Aquarelle,

40

HTTPS (HTTP over SSL) invia tutto il contenuto HTTP su un tunel SSL, quindi anche il contenuto e le intestazioni HTTP vengono crittografati.


21

Sì, le intestazioni sono crittografate. È scritto qui .

Tutto nel messaggio HTTPS è crittografato, comprese le intestazioni e il carico di richiesta / risposta.


37
Wikipedia non è la specifica, che è ciò che dovresti citare.
Aran Mulholland,

8

anche l'URL è crittografato, in realtà hai solo l'IP, la porta e, se SNI, il nome host non crittografato.


Anche se SNI non è supportato, un intermediario in grado di intercettare le connessioni HTTP sarà spesso in grado di monitorare anche le domande DNS (la maggior parte dell'intercettazione viene eseguita vicino al client, come su un router utente piratato). Quindi saranno in grado di vedere i nomi DNS.
curiousguy,
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.