Come fa un web server a sapere quale coppia di chiavi utilizzare per la decrittografia SSL?

Comprendo che quando Apache riceve una richiesta su una delle porte TCP su cui è in ascolto (ad es. 80, 443), deciderà quale host viene richiesto guardando l'intestazione HTTP Host. Il server saprà quindi a quale host virtuale deve reindirizzare la richiesta.

Ma come funziona per HTTP su SSL / TLS? Poiché l'intera richiesta HTTP viene crittografata (almeno è quello che credo di aver letto da qualche parte), le informazioni di intestazione possono essere lette solo dopo che il server ha decifrato i dati. Ma per decrittografare, deve sapere quale coppia di chiavi utilizzare poiché è possibile avere più certificati SSL installati su un server Web.

Quindi, come fa il server a sapere quale chiave è necessaria per la decrittazione?

Potrei immaginare che l'handshake TLS fornisca le informazioni necessarie.

Per quanto riguarda il flag "possibile duplicato" :

Anche se concordo sul fatto che le risposte alla domanda collegata e alla mia sono simili, devo dire che la domanda è diversa. È fuori dubbio se o come sia possibile l'hosting di più siti con certificati SSL indipendenti. Invece la mia domanda affronta l'aspetto tecnico sottostante.

Inizialmente, il web server non lo sapeva. Questo era il motivo per cui era necessario un indirizzo IP separato per ogni vhost SSL che si voleva ospitare sul server. In questo modo, il server sapeva che quando è arrivata una connessione su IP X, doveva usare la configurazione (compresi i certificati) per il vhost associato.

Ciò è cambiato con Indicazione nome server , un'estensione TLS che in effetti consente a un client di indicare il nome host richiesto nel processo di sincronizzazione. Questa estensione è utilizzata in tutti i sistemi operativi moderni, ma i vecchi browser o server non la supportano, quindi se ti aspetti che i client utilizzino ancora IE 6 su WinXP, non avrai fortuna.

Sembra che tu abbia alcune idee sbagliate su TLS / SSL. La richiesta HTTP non è crittografata dalla chiave pubblica del server. È crittografato da un codice simmetrico usando una chiave negoziata nella stretta di mano precedente.

Breve descrizione dell'handshake TLS: il server e il client negoziano alcuni cifrari, chiavi simmetriche e altri dettagli. Al fine di prevenire MITM, il server di solito invia il proprio certificato (catena) al client e autentica l'handshake utilizzando la chiave nel certificato. (Esistono anche altre varianti, ad esempio l'autenticazione client o TLS-PSK, ma non sono molto utilizzate con HTTP.) Il client può convalidare il certificato (nel solito modo) o ignorarlo.

Sebbene SNI sia importante quando si utilizzano più certificati TLS su un solo IP, non è essenziale che il server sia in grado di decrittografare la richiesta. Senza SNI, il server non sa quale catena di certificati debba essere inviata, quindi di solito ne sceglie uno (ad es. Il primo vhost), che potrebbe ovviamente essere sbagliato. Se il server sceglie una catena di certificati errata, il client dovrebbe rifiutarla (quindi non continua con l'invio della richiesta HTTP). Tuttavia, se il client ignora il certificato (o se il certificato non valido è contrassegnato come attendibile per questo sito), può continuare correttamente. Poiché la chiave simmetrica utilizzata per la crittografia non dipende dal certificato (TLS è progettato per funzionare anche senza certificati), il server può decrittografarlo.

Solo una piccola nota del perché sto scrivendo su TLS, mentre mi hai chiesto di SSL: TLS è la nuova versione di SSL. Tutte le versioni di SSL sono considerate non sicure per l'uso generale, quindi ora utilizziamo principalmente TLS (1.0, 1.1, 1.2).