Certificati SSL e corrispondenza delle suite di crittografia

Question

Certificati SSL e corrispondenza delle suite di crittografia

Naviga le tue risposte

#1 da (19 voti)

19

Ho imparato a conoscere il protocollo SSL / TLS (dal link ) e ho alcune domande concettuali sul protocollo .

Il client e il server scambiano messaggi "ciao" durante i quali scelgono la versione SSL / TLS e le suite di crittografia. Di Più in particolare, il client suggerisce una lista di suite di cifratura e il il server ne sceglie uno (se il server non seleziona nulla, il l'handshake fallisce). Ora, il server sceglie la suite di crittografia corrispondenti a quelli utilizzati nel certificato?

Per esempio: l'esecuzione di openssl x509 -in <server_cert>.pem -text -noout fornisce informazioni sul certificato del server. Su un certificato di esempio, vedo che l'algoritmo a chiave pubblica è rsaEncryption (2048 bit) e l'algoritmo di firma è sha256WithRSAEncryption. Questo non già predeterminerà una parte della suite di cifratura utilizzata nell'handshake?
Supponiamo che il server e il client concordino su una suite di crittografia. Ora, vedo anche che i clienti possono anche presentare un certificato più tardi nell'handshake. Ciò significa che le cifre sul certificato client devono essere compatibili con la suite di crittografia scelta?

(Domanda simile, ma non risponde a ciò che voglio: Picking cipher suite per HTTPS )

openssl public-key-infrastructure tls

posta iart 29.05.2015 - 20:22

fonte

1 risposta

Leggi altre domande sui tag openssl public-key-infrastructure tls

Biometrico rispetto ad altri meccanismi di autenticazione a due fattori Cosa c'è di sbagliato con la memorizzazione di chiavi private nel cloud?

score 19 · Answer 1

Per il certificato del server: la suite di crittografia indica il tipo di scambio di chiavi, che dipende dal tipo di chiave del certificato del server. Fondamentalmente hai il seguente:

Per suite di crittografia TLS_RSA_ *, lo scambio di chiavi utilizza la crittografia di un valore casuale scelto dal client con la chiave pubblica RSA del server, quindi la chiave pubblica del server deve essere di tipo RSA e deve essere appropriata per la crittografia (il server il certificato non deve includere un'estensione Key Usage che dice "solo firma").
Per le suite di crittografia TLS_DHE_RSA_ *, lo scambio di chiavi utilizza un Diffie-Hellman effimero e il server firma la sua parte dello scambio di chiavi DH con la sua chiave RSA. Pertanto la chiave pubblica del server deve essere di tipo RSA e deve essere appropriata per le firme (anche in questo caso il certificato non deve limitare l'utilizzo della chiave solo alla crittografia).
Le suite di crittografia TLS_DHE_DSS_ * e TLS_DHE_ECDSA_ * utilizzano uno scambio temporaneo di chiavi Diffie-Hellman e la chiave del server deve essere di tipo, rispettivamente, DSA ed EC e deve essere appropriata per le firme.
TLS_ECDHE_ * le suite di crittografia sono simili alle suite di crittografia TLS_DHE_ *, con la differenza che lo scambio di chiavi Diffie-Hellman è una variante di curva ellittica. Le condizioni sul certificato del server rimangono le stesse.
Le suite di crittografia TLS_DH_ * e TLS_ECDH_ * sono diverse (attenzione alla mancanza di "E" dopo il "DH"). Per queste suite, il certificato del server contiene direttamente una chiave pubblica Diffie-Hellman (o una sua variante di curva ellittica) e la suite di crittografia qualifica quindi l'algoritmo utilizzato dalla CA di emissione per firmare il certificato. Ad esempio, TLS_DH_RSA_ * significa "il server ha una chiave pubblica DH memorizzata in un certificato firmato da qualche CA con RSA". Questo è l'unico caso in cui il tipo di firma sul certificato ha una qualsiasi relazione con la suite di crittografia. Poiché in pratica nessuno usa quel tipo di certificato, questo caso può essere trascurato.

Per il certificato del cliente: il client presenta un certificato quando il server lo richiede. Il tipo di certificato del cliente non ha alcuna relazione con la suite di crittografia (eccetto per il rarissimo caso di certificati statici di DH, ma non l'ho mai visto usato nella pratica). Il certificato del cliente deve essere appropriato per le firme. Come parte del messaggio di handshake che richiede un certificato client, il server invia alcune informazioni sugli algoritmi supportati (vedere il standard). Infatti, TLS 1.2 espande ulteriormente tale meccanismo fornendo un elenco flessibile di algoritmi supportati e combinazioni di funzioni hash.