Perché le richieste HTTPS includono il nome host in testo chiaro?

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 in semplici richieste HTTP. Il nome è incluso nel primo messaggio dal client (ClientHello), ovvero prima che venga effettuata l'identificazione e lo scambio di chiavi, in modo che il server possa offrire il certificato corretto per l'identificazione.

Sebbene la crittografia dell'hostname sia piacevole, la domanda dovrebbe essere la chiave da utilizzare per la crittografia. Lo scambio di chiavi arriva solo dopo l'identificazione del sito per 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. Pertanto, la crittografia del nome host dovrebbe essere eseguita con una chiave basata su un altro tipo di identificazione o in un modo non sicuro rispetto a 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. Ci sono discussioni in corso se e come includere SNI crittografato in TLS 1.3. Suggerisco di dare un'occhiata a questa presentazione e la mailing list IETF TLS .

Oltre a ciò, la perdita del nome host può verificarsi anche con altri mezzi, come la precedente ricerca DNS per il nome. E ovviamente il certificato inviato nella risposta del server non è crittografato (stesso problema, nessuna chiave ancora) e quindi si può estrarre il target richiesto dalla risposta del server.

Ci sono molti siti là fuori che non funzionano senza SNI, come tutta l'offerta SSL gratuita di Cloudflares. Se si accede da un client che non supporta SNI (come IE8 su Windows XP), ciò comporterà la pubblicazione del certificato errato o un errore di handshake SSL come "nome sconosciuto".

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 al server giusto. Per fare ciò, 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 utilizzarlo per un server falso che posa come 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 server la stringa honest-bank-inc.com , e certamente non evilhacker.com .

Fin qui tutto bene. Quindi diventa la parte tecnica. In "HTTPS", hai l'incapsulato HTTP in SSL. Ciò significa che il tunnel SSL viene prima stabilito (la procedura "handshake") e quindi, solo allora, il client invia la richiesta HTTP all'interno di quel tunnel. Durante l'handshake, il server deve inviare il suo certificato al client. Ma, a quel punto , il client non ha ancora detto al server con cui sta cercando di parlare. Il server può presumere che, dal momento che ha ricevuto la connessione, il nome che il client desidera raggiungere è probabilmente uno dei nomi di sito che ospita il server. Ma questo è congettura 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 fin dall'inizio della connessione, il server può utilizzare quell'indirizzo IP per sapere quale server è il vero target. Certamente, la relativa carenza di indirizzi IP rende oggi meno attraente quella soluzione tradizionale.

• Diversi nomi nel certificato del server. Questo è perfettamente valido. Google stesso tende a mettere più di 70 nomi nel loro certificato. Una variante è "nomi jolly" che contengono "*", corrispondenti a molti nomi. Tuttavia, questo funziona solo fino a quando tutti i nomi sono noti al momento del rilascio 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 della stretta di mano, prima che il server invii il suo certificato. Questa è la soluzione moderna, e ora che Windows XP è andato oltre il limite, può finalmente essere ampiamente utilizzato (IE su Windows XP era l'ultimo browser che non supportava SNI).

Il fatto che comunichi con alcuni server ovviamente non può essere nascosto dall'IP. I pacchetti devono lasciare la macchina, accedere alla rete, essere indirizzati alla destinazione e consegnati. Non è un segreto che stai contattando un server che consegna pagine dal link .

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), contiene dettagli sulla specifica richiesta: instradarlo su un server all'indirizzo specificato www, ricerca, posta, ecc. E lungo questo percorso di directory nome.

I servizi di hosting hanno sfruttato questa indiretta per supportare più siti su un singolo server web tramite l'indicazione del nome del server. Quindi, entrambi i link collegamento e link potrebbero essere ospitati su server su 127.0.0.1, ed è solo il nome che distingue come il server instraderà quel messaggio internamente. È possibile che per motivi di sicurezza debba essere indirizzato a un server separato, dove verranno memorizzate le chiavi effettive. Le chiavi per decodificare quel messaggio potrebbero non esistere su quel server front-end, quindi non possono essere decifrate fino a quando non arrivano sul computer che ospita il sito di fred.

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 link su SSL / TLS.

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

• lighttpd: link
• Apache: link
• Nginx: link