Maintenant que nous sommes en 2015, quelles suites de chiffrement SSL / TLS doivent être utilisées dans un environnement HTTPS haute sécurité?
Il est devenu assez difficile de configurer un service HTTPS qui conserve "la couche de transport idéale". Comment un service HTTPS doit-il être configuré pour permettre un certain niveau de compatibilité raisonnable sans être vulnérable à des attaques, même mineures?
attaques de déclassement TLS en combinaison Beast, Crime, Breach et Poodle élimine la plupart sinon la totalité de SSLv3 et les versions antérieures. Microsoft désactive SSLv3 par défaut , ce qui me semble une bonne chose. En raison de faiblesses dans RC4 , MD5 et SHA1, il y a encore moins de suites de chiffrement parmi lesquelles choisir.
Un service HTTPS "idéal" n'activerait-il que TLS 1.0, 1.1 et 1.2 avec des variantes de taille de clé suivant les chiffres? Quelle devrait être la suite de chiffrement la plus préférée?
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_DH_RSA_WITH_AES_128_GCM_SHA256
Un service HTTPS "idéal" n'activerait-il que TLS 1.0, 1.1 et 1.2 avec des variantes de taille de clé suivant les chiffres?
Non, un service HTTPS `` idéal '' activerait uniquement TLS 1.2 et n'activerait que les suites de chiffrement basées sur AEAD (Authenticated Encryption with Associated Data) avec SHA-2, les paramètres DH à 4096 bits et les courbes EC à 521 bits d'un type qui correspond à vos besoins (gouvernement approuvé ou non généré par le gouvernement).
Ce service serait également incapable de se connecter et serait utilisé par une grande variété de clients plus anciens, y compris Android 4.3 et versions antérieures, IE 10 et versions antérieures, Java 7 (au moins u25) et versions antérieures), OpenSSL 0.9.8y et versions antérieures (OpenSSL 1.0.0 n'est tout simplement pas répertorié sur ma source), et ainsi de suite. Il serait cependant à l'abri de tout attaque qui ne fonctionne que sur TLS 1.1 et inférieur, toute attaque reposant sur SHA-1 et toute attaque reposant sur le mode CBC ou des chiffrements obsolètes comme RC4.
Limitations de la suite de chiffrement client par https://www.ssllabs.com .
Quelle devrait être la suite de chiffrement la plus préférée?
Ça dépend!
Je suppose que Foward Secrecy est une exigence.
Je pars du principe que "je pense qu'il est raisonnablement sûr à l'heure actuelle" est une exigence.
Je suppose que "effectivement mis en œuvre par au moins un acteur majeur" est une exigence.
Toutes les exigences concernant doivent avoir/ne peuvent pas utiliser certains ou un autre sous-ensemble de chiffres (doivent utiliser X, ne peuvent pas utiliser Y, etc.).
Par conséquent, je proposerais les listes suivantes comme un début raisonnable. Commencez par la catégorie supérieure (TLS 1.2 AEAD), puis continuez à descendre dans la liste et à ajouter des catégories jusqu'à ce que vous atteigniez un niveau qui fonctionne avec votre base d'utilisateurs ou que vous ayez atteint la fin de votre zone de confort, selon la première éventualité.
Incluez autant de suites de chiffrement de chaque catégorie que possible, de sorte que lors de la prochaine attaque, vous pourrez supprimer les suites de chiffrement affectées et continuer avec le reste.
Gardez un œil sur l'environnement des menaces afin de pouvoir continuer à supprimer les suites de chiffrement qui présentent des vulnérabilités.
Dans chaque catégorie principale, veuillez commander ou sélectionner les suites de chiffrement selon vos goûts: DHE est bien sûr plus lent que ECDHE, mais supprime entièrement la provenance de la courbe elliptique, etc. À l'heure actuelle, il semble que la commande soit un compromis, mais si vous voulez de la vitesse, préférez ou même exigez TLS_ECDHE_ *. Si vous ne faites pas confiance aux courbes elliptiques actuellement couramment mises en œuvre, ou si vous êtes préoccupé par les courbes elliptiques en raison de la NSA Suite B d'août 2015 indiquant un éloignement des précédentes courbes elliptiques de la Suite B à venir dans un avenir proche , et sont prêts à graver le CPU, préfèrent ou même nécessitent des suites TLS_DHE_ *.
Gardez à l'esprit que les certificats "normaux" sont des certificats RSA, qui fonctionnent avec les suites de chiffrement TLS_ECDHE_RSA_ * et TLS_DHE_RSA_ *. Les certificats DSA qui fonctionnent avec les suites de chiffrement TLS_ECDHE_ECDSA_ * sont jusqu'à présent très rares et de nombreuses autorités de certification ne les proposent pas.
- TLS 1.2 AEAD uniquement (tous sont également SHA-2)
- TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (nouveau 0xcca9, Pre-RFC7905 0xcc14)
- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (nouveau 0xcca8, Pre-RFC7905 0xcc13)
- TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (nouveau 0xccaa, Pre-RFC7905 0xcc15)
- TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
- TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
- Pour les personnes américaines qui sont intéressées par la conformité NIST, il s'agit d'une suite de chiffrement de catégorie TLS 1.2 devrait pour les serveurs utilisant des clés privées RSA et des certificats RSA par NIST SP800-52 révision 1 = tableau 3-3
- TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
- TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
- TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
- Pour les personnes américaines qui sont intéressées par la conformité NIST, il s'agit d'une suite de chiffrement TLS 1.2 devrait pour les serveurs utilisant des clés privées à courbe elliptique et des certificats ECDSA par NIST SP800-52 révision 1 tableau 3-5
- TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
- Pour les personnes américaines qui sont intéressées par la conformité NIST, il s'agit d'une suite de chiffrement de catégorie TLS 1.2 devrait pour les serveurs utilisant des clés privées à courbe elliptique et des certificats ECDSA par NIST SP800-52 révision 1 tableau 3-5
- Il s'agit du niveau de sécurité le plus élevé que je connaisse actuellement dans les implémentations TLS courantes.
- Depuis janvier 2017, les principaux navigateurs modernes gèrent ce niveau, y compris mais sans s'y limiter Android avec 6.0 prenant en charge AES-GCM et - seul des principaux - anciens CHACHA20-POLY1305 et 7.0 pris en charge nouveau CHACHA20-POLY1305, Chrome avec AES-GCM et CHACHA20-POLY1305, Firefox avec AES-GCM et CHACHA20-POLY1305, IE et Edge avec uniquement AES-GCM, Java avec seulement AES-GCM, OpenSSL 1.1.0 avec AES-GCM et CHACHA20-POLY1305, Safari avec seulement AES-GCM).
- De nombreux navigateurs majeurs ne peuvent pas gérer cela, même ceux de 2015 (Safari 7 sur OSX 10.9, Android 4.3 et versions antérieures, IE 10 sur Win7 (IE 11 même sur Win7 prendra en charge 0x9f et 0x9e si Windows a été corrigé)
- Famille TLS 1.2 SHA2 (non-AEAD)
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
- Pour les personnes américaines qui sont intéressées par la conformité NIST, il s'agit d'une suite de chiffrement de catégorie TLS 1.2 devrait pour les serveurs utilisant des clés privées RSA et des certificats RSA par NIST SP800-52 révision 1 = tableau 3-3
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
- Pour les personnes américaines qui s'intéressent à la conformité NIST, il s'agit d'une suite de chiffrement TLS 1.2 pour les serveurs utilisant des clés privées à courbe elliptique et des certificats ECDSA par NIST SP800-52 révision 1 tableau 3-5
- TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
- Pour les personnes américaines qui sont intéressées par la conformité NIST, il s'agit d'une suite de chiffrement de catégorie TLS 1.2 devrait pour les serveurs utilisant des clés privées à courbe elliptique et des certificats ECDSA par NIST SP800-52 révision 1 tableau 3-5
- TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384 (0xc077)
- TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256 (0xc076)
- TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256 (0xc4)
- Notez que vous avez perdu le mode AEAD et utilisez le mode CBC beaucoup plus ancien; c'est loin d'être idéal. Le mode CBC a été un facteur contribuant à plusieurs attaques dans le passé, y compris Lucky Thirteen et BEAST, et il n'est pas déraisonnable de croire que le mode CBC peut également être lié à de futures vulnérabilités.
- Certains navigateurs modernes qui n'ont pas de suites de chiffrement AEAD en ont un de plus adapté dans cette catégorie, par exemple, IE 11 sur Win7 peut utiliser TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 et Safari 6 et 7 peuvent en utiliser quelques-uns de ces
- encore une fois, c'est si vous ne disposez pas des suites ECDHE_ECDSA GCM)
- TLS 1.0 et 1.1 avec des chiffrements modernes (et des hachages obsolètes, puisque c'est tout ce qui est disponible)
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
- Pour les personnes américaines qui sont intéressées par la conformité NIST, il s'agit d'une suite de chiffrement par catégorie pour les serveurs utilisant des clés privées RSA et des certificats RSA par NIST SP800-52 révision 1 tableau 3-2
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
- Pour les personnes américaines qui s'intéressent à la conformité NIST, il s'agit d'une suite de chiffrement de catégorie devrait pour les serveurs utilisant des clés privées RSA et des certificats RSA par NIST SP800-52 révision 1 table 3-2
- TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
- TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33)
- TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88)
- TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45)
- TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
- Une fois que vous incluez des suites de chiffrement de ce niveau, vous trouverez probablement quelque chose qui fonctionne avec presque toutes les implémentations modernes.
- À ce niveau, vous n'utilisez pas seulement le mode CBC, vous utilisez également SHA-1. NIST SP800-131A a recommandé que SHA-1 soit interdit pour la génération de signature numérique après le 31 décembre 2013 (il y a un an aujourd'hui, en fait).
- TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
- TLS 1.0 et 1.1 avec des chiffrements plus anciens mais toujours raisonnables et des hachages obsolètes
- TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16)
- TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012)
- Pour les utilisateurs américains intéressés par la conformité NIST, il s'agit d'une suite de chiffrement de catégorie devrait pour les serveurs utilisant des clés privées RSA et des certificats RSA par NIST SP800-52 révision 1 table 3-2
- TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008)
- Pour les personnes américaines qui sont intéressées par la conformité NIST, il s'agit d'une suite de chiffrement de catégorie devrait pour les serveurs utilisant des clés privées à courbe elliptique et des certificats ECDSA par NIST SP800-52 révision 1 tableau 3-4
- IE 8 sous Windows XP n'a toujours pas de chance, tout comme Java 6u45 en raison des maximums des paramètres DH).
- C'est absolument le niveau minimum que je recommanderais.
- Notez que pour les serveurs utilisant des clés privées RSA et des certificats RSA qui ont besoin de la conformité NIST SP800-52 révision 1 , vous [~ # ~] devez [~ # ~] , devrait, et peut implémenter d'autres suites de chiffrement TLS_RSA_ * spécifiques qui NE FOURNISSENT PAS le secret de transfert, et donc je ne recommanderais pas à moins que cette conformité ne soit requise. ____.]
- Notez également que le paragraphe 3.3.1 de ce document précise que "le serveur doit être configuré pour n'utiliser que des suites de chiffrement entièrement composées d'algorithmes approuvés. la liste complète des suites de chiffrement acceptables pour une utilisation générale est fournie dans cette section ... "
- Bien entendu, les autres exigences nationales et industrielles varieront.
- et peuvent entrer en conflit les uns avec les autres; lisez attentivement toutes celles qui s'appliquent à vous.
Je vais mettre la prise habituelle ici - essayez votre liste de chiffrement avec vos propres outils (chiffrement openssl -v '...' pour les systèmes basés sur openssl), allez sur https://www.ssllabs.com /index.html commencez par vérifier les suites de chiffrement prises en charge par divers clients, puis configurez votre site, puis revenez sur www.ssllabs.com et exécutez leur test de serveur.
Notez que _ ECDSA _ les suites de chiffrement nécessitent des certificats ECDSA, bien sûr, et ceux-ci sont toujours très difficiles à trouver.
ETA: NSA Conseils EC Suite B, et IE 11/Win7 prend désormais en charge 0x9f et 0x9e.
ETA: Depuis janvier 2016, NIST SP800-52r1 est inchangé et une nouvelle suite de chiffrement (0xc00a) a été ajoutée à la liste.
ETA: Depuis janvier 2017, la RFC7905 a modifié les trois chiffrements TLS 1.2 AEAD CHACHA20-POLY1305, et les navigateurs "modernes" ont considérablement amélioré la prise en charge AEAD comme indiqué dans la nouvelle puce. Voir https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 pour les suites de chiffrement IANA à jour.
Je ne répondais généralement pas avec un simple lien, mais comme les réponses à ces questions changent si souvent, je le fais. De plus, la suite de chiffrement "idéale" dépend complètement de l'application et du public cible. Lesquels contrôlez-vous, quels choix pouvez-vous et pouvez-vous vous permettre de faire (par exemple, avez-vous besoin de prendre en charge IE6?), Tout cela influence la réponse `` idéale ''.
Quoi qu'il en soit, https://cipherli.st/ a un bon résumé des suites de chiffrement et des exemples de configuration pour les applications populaires. Comme d'autres l'ont souligné, Qualys SSLLabs a un outil agréable pour tester votre configuration et a de belles explications.
Un bon point de départ est chiffrement TLS recommandé par Mozilla .
Un bon moyen de tester la sécurité des sites Web HTTPS publics est Qualys SSL Labs , ce site contient également de nombreux articles sur TLS/SSL (en mettant l'accent sur HTTPS).
Mise à jour 2016 via SSL Labs:
Vous devez vous fier principalement aux suites AEAD qui fournissent une authentification forte et un échange de clés, un secret de retransmission et un cryptage d'au moins 128 bits. Certaines autres suites plus faibles peuvent toujours être prises en charge, à condition qu'elles ne soient négociées qu'avec des clients plus anciens qui ne prennent rien en charge de mieux.
Il existe plusieurs primitives cryptographiques obsolètes à éviter:
Les suites Diffie-Hellman anonymes (ADH) ne fournissent pas d'authentification.
- Les suites de chiffrement NULL ne fournissent aucun chiffrement.
- Les suites de chiffrement d'exportation ne sont pas sécurisées lorsqu'elles sont négociées dans une connexion, mais elles peuvent également être utilisées contre un serveur qui préfère des suites plus fortes (l'attaque FREAK).
- Les suites à chiffrement faible (généralement de 40 et 56 bits) utilisent un chiffrement qui peut facilement être brisé.
- RC4 n'est pas sécurisé.
- 3DES est lent et faible.
Utilisez la configuration de suite suivante, conçue pour les clés RSA et ECDSA, comme point de départ:
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256
EDH-RSA-DES-CBC3-SHA
Remarque Cet exemple de configuration utilise des noms de suite non standard requis par OpenSSL. Pour le déploiement dans d'autres environnements (par exemple, IIS), vous devrez utiliser les noms de suite TLS standard.