web-dev-qa-db-fra.com

Certificats SSL et correspondance des suites de chiffrement

J'ai appris le protocole SSL/TLS (depuis https://tools.ietf.org/html/rfc5246 ) et j'ai quelques questions conceptuelles sur le protocole.

  1. Le client et le serveur échangent des messages "bonjour" pendant lesquels ils choisissent la version SSL/TLS et les suites de chiffrement. Plus précisément, le client propose une liste de suites de chiffrement et le serveur en choisit une (si le serveur ne choisit rien, la prise de contact échoue). Maintenant, le serveur choisit-il la suite de chiffrement correspondant à celles utilisées dans le certificat?

    Par exemple: exécuter openssl x509 -in <server_cert>.pem -text -noout vous donne des informations sur le certificat du serveur. Sur un exemple de certificat, je vois que l'algorithme de clé publique est rsaEncryption (2048bit) et l'algorithme de signature est sha256WithRSAEncryption. Cela ne prédétermine-t-il pas déjà une partie de la suite de chiffrement utilisée dans la poignée de main?

  2. Supposons que le serveur et le client se mettent d'accord sur une suite de chiffrement. Maintenant, je vois aussi que les clients peuvent également présenter un certificat plus tard dans la poignée de main. Cela signifie-t-il que les chiffres du certificat client doivent être compatibles avec la suite de chiffrement choisie?

    (Question similaire, mais ne répond pas à ce que je veux: Choisir des suites de chiffrement pour HTTPS )

tlspublic-key-infrastructureopenssl
25
iart

Pour le certificat de serveur: la suite de chiffrement indique le type d'échange de clés, qui dépend du type de clé de certificat du serveur. Vous disposez essentiellement des éléments suivants:

  • Pour les suites de chiffrement TLS_RSA_ *, l'échange de clés utilise le chiffrement d'une valeur aléatoire choisie par le client avec la clé publique RSA du serveur, de sorte que la clé publique du serveur doit être de type RSA et doit être appropriée pour le chiffrement (le certificat du serveur ne doit pas inclure un Key Usage extension qui dit "signature uniquement").

  • Pour les suites de chiffrement TLS_DHE_RSA_ *, l'échange de clés utilise un Diffie-Hellman éphémère, et le serveur signe sa partie de l'échange de clés DH avec sa clé RSA. La clé publique du serveur doit donc être de type RSA et doit être appropriée pour les signatures (là encore, le certificat ne doit pas restreindre l'utilisation de la clé au seul chiffrement).

  • Les suites de chiffrement TLS_DHE_DSS_ * et TLS_DHE_ECDSA_ * utilisent un échange de clés Diffie-Hellman éphémère, et la clé du serveur doit être de type, respectivement, DSA et EC, et doit être appropriée pour les signatures.

  • Les suites de chiffrement TLS_ECDHE_ * sont similaires aux suites de chiffrement TLS_DHE_ *, sauf que l'échange de clés Diffie-Hellman est une variante de courbe elliptique. Les conditions sur le certificat du serveur restent les mêmes.

  • Les suites de chiffrement TLS_DH_ * et TLS_ECDH_ * sont différentes (faites attention au manque de "E" après le "DH"). Pour ces suites, le certificat du serveur contient directement une clé publique Diffie-Hellman (ou une variante de courbe elliptique de celle-ci), et la suite de chiffrement qualifie ensuite l'algorithme utilisé par l'autorité de certification émettrice pour signer le certificat. Par exemple, TLS_DH_RSA_ * signifie "le serveur a une clé publique DH stockée dans un certificat qui a été signé par une autorité de certification avec RSA". C'est le seul cas où le type de signature sur le certificat a une relation avec la suite de chiffrement. Étant donné que dans la pratique, personne n'utilise ce type de certificat, ce cas peut être négligé.

Pour le certificat client: le client présente un certificat lorsque le serveur le demande. Le type de certificat client n'a aucune relation avec la suite de chiffrement (à l'exception du cas extrêmement rare de certificats DH statiques, mais je n'ai jamais vu cela utilisé dans la pratique). Le certificat client doit être approprié pour les signatures. Dans le cadre du message d'établissement de liaison qui demande un certificat client, le serveur envoie des informations sur les algorithmes pris en charge (voir la norme ). En fait, TLS 1.2 étend encore ce mécanisme en donnant une liste flexible des combinaisons d'algorithmes et de fonctions de hachage prises en charge.

24
Thomas Pornin