"ECDHE" significa che lo scambio di chiavi utilizzerà l'algoritmo Diffie-Hellman (su curve ellittiche) con elementi DH appena generati; l'ultima "E" sta per effimero . Quindi, mentre la DH produce una chiave condivisa, funzionerà con valori prodotti casualmente, e nulla in DH assicurerà l'autenticazione : il client non ha modo di sapere se la chiave pubblica DH che vede appartiene realmente alla server.
Per ripristinare l'autenticazione del server, è necessario qualcos'altro. È una firma : il server firma digitalmente la metà dello scambio di chiavi DH. Quella firma usa la chiave che si trova nel certificato del server, e quindi l'algoritmo della firma dipende dal tipo di quella chiave. In "ECDHE-RSA", la parte "RSA" si riferisce a tale firma: dice che sarà di tipo RSA (e implica, ovviamente, che il certificato del server contenga la corrispondente chiave pubblica RSA).
Non esiste un meccanismo simile per l'autenticazione client . Quando il server richiede un certificato client, il client dovrà calcolare una firma e inviare la sua chiave pubblica (come parte del suo certificato), ma non vi è alcuna relazione tra quel tipo di certificato client e la suite di crittografia. I motivi sono:
-
I certificati client vengono visualizzati in seguito nell'handshake, dopo la selezione della suite di crittografia. Quando viene scelta la suite di crittografia, il client non sa ancora se verrà richiesto un certificato client.
-
Un server SSL, in generale, deve essere in grado di rispondere all'intero mondo, ma quando il client si connette, conosce con quale server sta parlando e può selezionare un appropriato certificato di conseguenza (il server invia anche un elenco di nomi di CA per restringere le scelte del cliente). I certificati client sono una rarità in un contesto Web; in generale, i server SSL richiedono i certificati client quando sanno che i client hanno già certificati di tipo appropriato (ad esempio un server di banca chiederà il certificato di un cliente solo se il cliente fa parte di un programma in cui la banca ha garantito la distribuzione del detti certificati). Pertanto, non è necessaria una negoziazione dinamica del tipo di certificato client.
La selezione della suite di crittografia consiste nello scegliere gli algoritmi che sono supportati da entrambe le estremità. Se il server deve firmare e il client deve verificare, il client deve essere in grado di capire l'algoritmo della firma e quindi il suo tipo di chiave.
In pratica, il client invia un elenco di suite di crittografia supportate e il server ne seleziona una, una suite di crittografia che, ovviamente, corrisponde agli algoritmi e ai tipi di chiavi che il server utilizzerà. In teoria, la lista inviata dal cliente è ordinata per "preferenza" e il server deve onorare quell'ordine, cioè scegliere la prima suite di crittografia nell'elenco dei client che soddisfi anche le capacità del server. Non tutti i server sono così cortesi.
Vedi questa risposta per un'introduzione a SSL / TLS.