Quel mécanisme d'échange de clés doit être utilisé dans TLS?
Il existe de nombreux mécanismes d'échange de clés qui peuvent être utilisés dans TLS. Parmi eux se trouvent RSA, ECDH_ECDSA, ECDHE_ECDSA, ECDH_RSA, ECDHE_RSA et autres. Lesquelles d'entre elles sont plus sécurisées cryptographiquement et peuvent être utilisées pour sécuriser la connexion avec le site Web?
Vous pouvez utiliser un échange de clés (dans le cadre d'une suite de chiffrement) uniquement si le type de clé du serveur et le certificat correspondent. Pour voir cela en détail, jetons un œil aux suites de chiffrement définies dans spécification TLS 1.2 . Chaque suite de chiffrement définit l'algorithme d'échange de clés, ainsi que les algorithmes de chiffrement symétrique et de vérification d'intégrité utilisés par la suite; nous nous concentrons ici sur la partie d'échange clé.
RSA: l'échange de clés fonctionne par chiffrement une valeur aléatoire (choisie par le client) avec la clé publique du serveur. Cela nécessite que la clé publique du serveur soit une clé RSA, et que le certificat de serveur n'interdit pas le chiffrement (principalement via l'extension de certificat "Key Usage": si cette extension est présente, elle doit inclure le drapeau "keyAgreement").
DH_RSA: l'échange de clés est un Diffie-Hellman statique: la clé publique du serveur doit être une clé Diffie-Hellman; en outre, ce certificat doit avoir été délivré par une autorité de certification qui elle-même utilisait une clé RSA (la clé CA est la clé qui a été utilisée pour signer le certificat du serveur).
DH_DSS: comme DH_RSA, sauf que l'AC a utilisé une clé DSA.
DHE_RSA: l'échange de clés est un Diffie-Hellman éphémère: le serveur génère dynamiquement une clé publique DH et l'envoie au client; le serveur aussi signe ce qu'il envoie. Pour DHE_RSA, la clé publique du serveur doit être de type RSA et son certificat doit être approprié pour signatures (l'extension Key Usage, si elle est présente, doit inclure l'indicateur digitalSignature).
DHE_DSS: comme DHE_RSA, sauf que la clé de serveur a le type DSA.
DH_anon: il n'y a pas de certificat de serveur. Le serveur utilise une clé Diffie-Hellman qu'il peut avoir générée dynamiquement. Les suites de chiffrement "anon" sont vulnérables aux attaques d'usurpation d'identité (y compris, mais sans s'y limiter, le "Man in the Middle" ) car elles ne disposent d'aucune sorte d'authentification de serveur. D'une manière générale, vous ne devez pas utiliser une suite de chiffrement "anon".
Les algorithmes d'échange de clés qui utilisent la cryptographie à courbe elliptique sont spécifiés dans n autre RFC et proposent ce qui suit:
ECDH_ECDSA: comme DH_DSA, mais avec des courbes elliptiques: la clé publique du serveur doit être une clé ECDH, dans un certificat émis par une CA qui elle-même utilisait une clé publique ECDSA.
ECDH_RSA: comme ECDH_ECDSA, mais l'autorité de certification émettrice a une clé RSA.
ECDHE_ECDSA: le serveur envoie une clé EC Diffie-Hellman générée dynamiquement et la signe avec sa propre clé, qui doit être de type ECDSA. C'est équivalent à DHE_DSS, mais avec des courbes elliptiques pour la partie Diffie-Hellman et la partie signature.
ECDHE_RSA: comme ECDHE_ECDSA, mais la clé publique du serveur est une clé RSA, utilisée pour signer la clé éphémère Diffie-Hellman à courbe elliptique.
ECDH_anon: une suite de chiffrement "anon", avec Diffie-Hellman dynamique à courbe elliptique.
Alors, que choisirez-vous pour un site Web? Vos principales contraintes sont:
Vous voulez une suite de chiffrement prise en charge par la plupart des clients; en pratique, cela exclut la cryptographie à courbe elliptique (les courbes elliptiques sont puissamment cool, mais pas encore bien supportées sur le terrain - considérez que selon gs.statcounter , en septembre 2011, 40% des clients les systèmes utilisent toujours Windows XP et près de 5% utilisent IE 7.0).
Vous voulez une suite de chiffrement compatible avec votre type de clé de serveur et votre certificat. Cela, à son tour, dépend de ce que l'AC accepte (l'AC qui vous a vendu le certificat). 99,9% du temps, cela signifie RSA. Tout le monde fait du RSA. Les clés Diffie-Hellman dans les certificats et les signatures DSA étaient autrefois promues par le NIST (l'agence fédérale américaine qui s'occupe de ces questions) car il y avait un brevet sur RSA; mais ce brevet a expiré en 2000. Diffie-Hellman (dans le cadre des certificats) est spécifié par ANSI X9.42 , une norme qui n'est pas gratuite (donc les développeurs de temps libre open source hésitent à l'implémenter) et pas tout à fait clair non plus. Donc, personne n'utilise vraiment Diffie-Hellman dans les certificats. DSA est plus largement pris en charge (son définition de la norme est gratuit et tout à fait lisible) mais pas au point d'être non anecdotique par rapport à RSA.
Vous ne voulez pas utiliser une suite "anon" car elle n'est pas sécurisée contre les attaquants actifs, et la plupart des navigateurs clients ont les suites "anon" désactivées par défaut.
Donc, votre choix est essentiellement entre "RSA" et "DHE_RSA". Ce dernier peut avoir un coût de calcul légèrement plus élevé, bien que vous auriez besoin d'avoir au moins quelques centaines de nouvelles connexions par seconde pour voir réellement une différence (j'insiste sur le "nouveau": puisque TLS inclut une poignée de main abrégée qui peut s'appuyer sur le échange de clés d'une connexion précédente, l'échange de clés réel avec cryptographie asymétrique ne se produit qu'une fois par nouveau navigateur client au cours de la dernière minute). Donc, en pratique, aucune différence mesurable sur la charge CPU entre RSA et DHE_RSA.
DHE_RSA propose quelque chose appelé Perfect Forward Secrecy , un nom pompeux pour la propriété suivante: si votre serveur est complètement piraté, au point que l'attaquant obtient une copie de la clé privée du serveur, alors il être capable de décrypter passé les sessions TLS (qu'il a enregistrées) si ces sessions utilisaient RSA, alors qu'il ne pourra pas le faire si ces sessions utilisaient DHE_RSA. Dans la pratique, si l'attaquant pouvait voler votre clé privée, il pourrait probablement lire les 10000 numéros de carte de crédit dans la base de données de votre site, il n'y a donc aucune raison pour qu'il prenne la peine d'enregistrer et de décrypter les sessions précédentes, car cela ne produirait qu'une douzaine supplémentaires chiffres ou plus. PFS est mathématiquement élégant, mais sur-typé. Si c'est toujours un acronyme astucieux et peut faire une grande impression sur les faibles d'esprit, dans le cadre d'une campagne de relations publiques bien pensée.
Résumé: utilisez DHE_RSA.