Domanda:
Perché le richieste HTTPS includono il nome host in testo non crittografato?
jay-charles
2015-04-23 21:46:40 UTC
view on stackexchange narkive permalink

Ho qualche problema a capire perché il protocollo HTTPS include il nome host in testo normale. Ho letto che il nome host e gli indirizzi IP di un pacchetto HTTPS non sono crittografati.

Perché il nome host non può essere crittografato? Non possiamo semplicemente lasciare l'IP di destinazione in testo normale (quindi il pacchetto è instradabile), quindi quando il pacchetto arriva al server di destinazione, il pacchetto viene decrittografato e l'host / indice identificato dall'intestazione?

Forse il problema è che ci possono essere diversi certificati per un particolare IP di destinazione (certificati diversi per diversi sottodomini?), Quindi il server di destinazione non può decifrare il pacchetto finché non arriva all'host corretto all'interno di quel server. Ha senso ALCUNI, o me ne vado?

Gli algoritmi di crittografia devono essere impostati prima che possa essere eseguita la crittografia. Ecco perché inizialmente tutto è chiaro. Il nome di dominio fa generalmente parte del certificato che il server invia in chiaro. Qualsiasi dominio o IP associato al certificato del server sarà comunque disponibile. Fa parte dell'identificazione del server. HTTPS non fornisce anonimato, solo sicurezza.
Dopo che si è verificato l'handshake e gli algoritmi di crittografia selezionati, perché non dovrebbe essere crittografato tutto tranne l'IP di destinazione?
Per chiarire: pensavo che l'intestazione HTTP "Host" fosse in qualche modo lasciata visibile quando si utilizza HTTPS.Non è così.Tutte le intestazioni HTTP, i parametri di query, il corpo e così via sono crittografati all'interno della connessione TLS.Invece, la connessione TLS stessa inizia con un handshake che include il campo "nome_server", che potrebbe essere necessario affinché il server risponda con il certificato appropriato e / o per un provider di hosting condiviso per determinare a quale applicazione del cliente è destinata la richiesta, poiché condividono lo stesso indirizzo IP.
In quasi tutti i casi (1), una query DNS è stata eseguita immediatamente prima della prima (2) connessione HTTPS che fornisce il nome di dominio in chiaro.(1) Le eccezioni si verificano quando il nome di dominio è definito in un file locale (come il file `hosts`) o quando una precedente query DNS ha restituito una risposta con caratteri jolly (` * `answer). (2) Le connessioni successive riutilizzeranno la risposta DNS memorizzata nella cache e potranno anche riutilizzare la sessione TLS.
Quattro risposte:
#1
+72
Steffen Ullrich
2015-04-23 22:03:38 UTC
view on stackexchange narkive permalink

Il nome host è incluso nell'handshake SSL iniziale per supportare i server che hanno più nomi host (con certificati diversi) sullo stesso indirizzo IP (SNI: Server Name Indication). Questo è simile all'intestazione host nelle richieste HTTP semplici. Il nome è incluso nel primo messaggio del client (ClientHello), cioè prima che venga effettuata qualsiasi identificazione e scambio di chiavi, in modo che il server possa offrire il certificato corretto per l'identificazione.

Sebbene crittografare il nome host sarebbe carino, la domanda sarebbe quale chiave usare per la crittografia. Lo scambio delle chiavi avviene solo dopo l'identificazione del sito tramite certificato, perché altrimenti potresti scambiare le chiavi con un man-in-the-middle. Ma l'identificazione con i certificati richiede già il nome host in modo che il server possa offrire il certificato corrispondente. Quindi la crittografia del nome host dovrebbe essere eseguita con una chiave basata su un altro tipo di identificazione o in un modo non sicuro contro man-in-the-middle.

Potrebbero esserci modi per proteggere il nome host nell'handshake SSL, ma al costo di un sovraccarico aggiuntivo nell'handshake e nell'infrastruttura. Sono in corso discussioni se e come includere SNI crittografati in TLS 1.3. Ti suggerisco di dare un'occhiata a questa presentazione e alla mailing list IETF TLS.

A parte questo, la perdita del nome host può verificarsi anche da parte di altri significa, come la precedente ricerca DNS per il nome. E ovviamente anche il certificato inviato nella risposta del server non è crittografato (stesso problema, nessuna chiave ancora) e quindi si può estrarre l'obiettivo richiesto dalla risposta del server.

Ci sono molti siti là fuori che non funzionerà senza SNI, come tutte le offerte SSL gratuite di Cloudflares. Se vi si accede da un client che non supporta SNI (come IE8 su Windows XP), verrà fornito il certificato errato o un errore di handshake SSL come "unknown_name".

Vedo alcuni parallelismi tra questo e il push di Google "https ovunque". Sebbene sarebbe fantastico crittografare tutto e prevenire tutte le possibilità di MitM (anche per i siti di streaming), come affronteremo tutti i risparmi di cache e larghezza di banda che la crittografia annullerà?
@JoshvonSchaumburg Direi che l'argomento è che l'infrastruttura è ora utilizzata principalmente da cose che non vengono comunque memorizzate nella cache (ad esempio guardando i video di YouTube). Dopo tutto, se funzionasse, perché le aziende dovrebbero preoccuparsi dei propri CDN? Gli ISP e i manutentori dell'infrastruttura non hanno più alcuna motivazione per fare bene il caching, perché sono pagati a byte;)
Non sono sicuro di questa spiegazione. Per uno, gli ISP hanno la motivazione per memorizzare bene la cache. Quasi tutti (almeno negli Stati Uniti e presumo altrove) offrono un canone mensile fisso illimitato. Ciò significa che hanno assolutamente incentivi a memorizzare nella cache. Inoltre, anche se offrissero piani basati sui dati (prendiamo i gestori wireless, ad esempio, oi mercati di prova in cui gli ISP limitano la banda larga cablata), i fornitori di servizi hanno ancora incentivi a memorizzare nella cache all'interno delle loro reti perché le velocità sono maggiori. Inoltre, non è necessario eseguire il peering con altre reti per eseguire il pull dei flussi video con i server di memorizzazione nella cache.
@JoshvonSchaumburg Poiché un utente malintenzionato saprebbe quale sito desidera attaccare e raccoglierebbe informazioni su questo sito con mezzi legali (Google, aprendo il sito nel suo browser e simili), otterrebbe le informazioni che stai cercando disperatamente di nascondere con un clic di un pulsante, ovvero la mappatura di un hostname al suo IP. Ci sono attacchi che utilizzano l'iniezione di testo normale, qualcosa che non sarebbe necessario se il nome host fosse crittografato. Quindi la crittografia del nome host genererebbe una vulnerabilità per la protezione delle informazioni che possono essere facilmente acquisite con altri mezzi.
@MarkusWMahlberg: l'obiettivo della crittografia SNI non sarebbe nascondere la mappatura dal nome host all'IP, ma nascondere il nome host effettivo a cui si accede su sistemi che hanno molti nomi host per IP (servizi di hosting tipici, CDN ...). E non vedo il tuo argomento secondo cui la crittografia SNI creerebbe nuove vulnerabilità, vedo solo che sarebbe un sovraccarico considerevole o semplicemente inefficace.
@SteffenUllrich alcuni cifrari utilizzati presentano punti deboli rispetto agli attacchi di testo in chiaro noti. Poiché ogni richiesta conterrebbe un testo in chiaro noto, ciò imporrebbe una debolezza teorica. Non sono sicuro che nascondere il nome host a cui si accede aggiungerebbe effettivamente una sicurezza diversa dalla negabilità plausibile.
@MarkusWMahlberg - Non penso che porre una domanda per una migliore comprensione di un protocollo non sia certo il mio "tentativo disperato di nascondere" qualcosa. Sentiti libero di lasciare il tono sarcastico e condiscendente in futuro!
@JoshvonSchaumburg Il mio commento non voleva essere né sarcastico né condiscendente e vorrei esprimere il mio massimo rammarico per qualsiasi sentimento offeso. Era un mero gioco intellettuale e per favore sii così gentile da vedere il mio commento come parte di una disputa accademica, come previsto.
La tua implicazione che stavo "disperatamente" cercando di nascondere informazioni che potevano essere accertate dal "clic di un pulsante" era, a mio parere, condiscendente verso la mia conoscenza limitata sull'argomento, ma accetterò le tue scuse.
@MarkusWMahlberg: Non credo che la tua argomentazione sul testo normale noto sia rilevante. Ogni richiesta / risposta HTTP all'interno di una connessione TLS (ovvero HTTPS) contiene un testo normale più noto rispetto al nome SNI.
@Luaan Poiché la memorizzazione nella cache consente loro di addebitare i byte, non stanno effettivamente trasferendo, ovviamente.E i video di YouTube potrebbero essere memorizzati nella cache, se Google non spingesse HTTPS ovunque.
@immibis Bene, non è proprio specifico di Google;Non sarei sorpreso se la maggior parte del traffico del sito Web su Internet fosse HTTPS al giorno d'oggi.Ci sono persino ISP che cercano di costringerti a installare le proprie CA di root!
Se il nome host è stato trasmesso dopo DHKE ma prima di SSL, potrebbe essere protetto dallo snooping passivo.
@Bengie: Almeno nelle versioni TLS inferiori a TLS 1.3 lo scambio di chiavi viene avviato solo dopo aver ricevuto il certificato.Tuttavia, la scelta del certificato richiede la conoscenza del nome host previsto sui sistemi con più certificati sullo stesso indirizzo IP.Ciò significa che l'invio del nome dopo DHKE è troppo tardi poiché è necessario conoscerlo prima per scegliere il certificato appropriato.
#2
+22
Tom Leek
2015-04-24 00:04:41 UTC
view on stackexchange narkive permalink

SNI è disponibile per l'hosting virtuale (diversi server, con nomi distinti, sullo stesso indirizzo IP). Quando un client SSL si connette a un server SSL, vuole sapere se sta parlando con il server giusto. A tal fine, cerca il nome del server previsto nel certificato. Ogni hacker malvagio può acquistare un certificato per il proprio server (chiamato evilhacker.com ), ma non sarà in grado di usarlo per un falso server che spaccia per honest-bank-inc. com perché il browser client, tentando di connettersi a https://honest-bank-inc.com/ , sarà piuttosto irremovibile nel trovare nel presunto certificato del server la stringa honest-bank-inc.com , e certamente non evilhacker.com.

Fin qui tutto bene. Poi diventa la parte tecnica. In "HTTPS", hai HTTP incapsulato in SSL. Ciò significa che prima viene stabilito il tunnel SSL (la procedura di "handshake") e solo allora il client invia la richiesta HTTP all'interno di quel tunnel. Durante l'handshake, il server deve inviare il proprio certificato al client. Ma, a quel punto , il client non ha ancora detto al server con chi sta cercando di parlare. Il server può presumere che, poiché ha ricevuto la connessione, il nome che il client vuole raggiungere sia probabilmente uno dei nomi di sito che ospita il server. Ma è un'ipotesi e fallisce se il server ospita diversi siti con nomi distinti.

Ci sono principalmente tre modi per uscire da questo enigma:

  • Un IP per sito. Poiché il server conosce l'indirizzo IP di destinazione sin dall'inizio della connessione, il server può utilizzare quell'indirizzo IP per sapere quale server è il vero obiettivo. Ovviamente, la carenza relativa dell'indirizzo IP rende questa soluzione tradizionale meno attraente oggigiorno.

  • Diversi nomi nel certificato del server. Questo è perfettamente valido. Gli stessi Google tendono a inserire più di 70 nomi nel loro certificato. Una variante è "nomi con caratteri jolly" che contengono "*", corrispondenti a molti nomi. Tuttavia, questo funziona solo fintanto che tutti i nomi sono noti al momento dell'emissione del certificato. Per un servizio di hosting di siti Web, ciò significherebbe acquistare un nuovo certificato ogni volta che un cliente si registra.

  • SNI. Con SNI, il client invia il nome previsto all'inizio dell'handshake, prima che il server invii il suo certificato. Questa è la soluzione moderna, e ora che Windows XP è andato oltre il baratro, può finalmente essere ampiamente utilizzato (IE su Windows XP era l'ultimo browser che non supportava SNI).

Buona spiegazione. Quindi, se stessi ancora utilizzando IE su XP e passassi a un sito HTTPS su un server che ospita più siti HTTPS con più certificati, come farebbe il server a sapere quale certificato fornire senza il supporto SNI?
@JoshvonSchaumburg: Il server non conosce e fornirebbe il certificato predefinito del sito (che comporterà il rifiuto da parte del browser a causa della mancata corrispondenza del nome) o restituirà un avviso "unknown_name" o qualcosa di simile.
"Per un servizio di hosting di un sito Web, ciò significherebbe acquistare un nuovo certificato ogni volta che un cliente si registra". Mi prendi in giro? Stavo indovinando che SSL con caratteri jolly consente QUALSIASI stringa sotto il dominio principale, ma solo al 1 ° livello con * domain.com (IE: 1st.main.com, 2st.1st.main.com)
#3
+7
John Deters
2015-04-23 22:10:38 UTC
view on stackexchange narkive permalink

Il fatto che stai comunicando con qualche server ovviamente non può essere nascosto dall'IP. I pacchetti devono lasciare la macchina, entrare nella rete, essere instradati a destinazione ed essere consegnati. Non è un segreto che stai contattando un server che fornisce pagine da https://www.fred.com.

Tuttavia, l'URL non contiene l'IP. Invece, contiene più di un'informazione. Non solo contiene il nome host (che deve essere risolto in un indirizzo IP), ma contiene dettagli sulla richiesta specifica: instradalo a un server a quell'indirizzo denominato www, ricerca, posta, ecc. E lungo questo percorso di directory name.

I servizi di hosting hanno sfruttato questo indiretto per supportare più siti su un unico server web tramite Server Name Indication. Quindi sia https://www.fred.com e https://www.barney.com potrebbero essere ospitati su un server a 127.0.0.1, ed è solo il nome che distingue il modo in cui il server instraderà il messaggio internamente. È possibile che per motivi di sicurezza debba essere instradato a un server separato, dove verranno archiviate le chiavi effettive. Le chiavi per decrittografare quel messaggio potrebbero non esistere su quel server front-end, quindi non può essere decrittografato finché non arriva alla macchina che ospita il sito fred.

Qualche motivo speciale per cui hai usato fred.com invece di example.com?Se ne avessi bisogno due, potresti aggiungere example.org, o se desideri nomi più distinguibili, usare {fred, barney} .example.Questi domini sono riservati per l'uso negli esempi.
#4
  0
gavenkoa
2018-01-27 23:12:39 UTC
view on stackexchange narkive permalink

Oltre alla necessità di includere il nome host per risolvere il certificato, esiste una pratica comune connessa all'uso di SNI, che è importante sapere: consente di implementare https://en.wikipedia.org/wiki/Virtual_hosting su SSL / TLS.

SNI è utilizzato da tutti i server Web più diffusi:



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...