Quels chiffrements SSL / TLS peuvent être considérés comme sécurisés?
Le site Web OpenSSL fournit une longue liste de différents chiffrements disponibles pour SSL et TLS. Ma question est de savoir lequel de ces chiffres peut être considéré comme sûr de nos jours. Je m'intéresse particulièrement au HTTPS, si cela devrait être important, même si je suppose que non. Je connais Recommandation Apache pour utiliser SSLCipherSuite HIGH:MEDIUM et je reconnais qu'il s'agit de la meilleure pratique.
Ce que je recherche, c'est une norme officielle ou un article récent d'une source acceptée et reconnue comme une organisation de sécurité bien connue. Si un tel document existe, y compris des estimations sur la durée pendant laquelle certains chiffres avec une longueur de clé spécifique seront considérés comme sûrs, ce serait encore mieux. Une telle chose existe-t-elle?
Les suites de chiffrement avec "NULL" n'offrent pas de cryptage des données, seulement un contrôle d'intégrité. Cela signifie "non sécurisé" pour la plupart des utilisations.
Les suites de chiffrement avec "EXPORT" sont, par conception, faibles. Ils sont cryptés, mais uniquement avec des clés suffisamment petites pour être piratées avec du matériel amateur même (disons, un PC domestique de base - cryptage symétrique reposant sur 40- clés de bits). Ces suites ont été définies pour se conformer aux règles d'exportation américaines sur les systèmes cryptographiques, règles qui étaient assez strictes avant 2000. De nos jours, ces restrictions ont été levées et il est inutile de prendre en charge les suites de chiffrement "EXPORT".
Les suites de chiffrement avec "DES" (pas "3DES ") s'appuient pour le chiffrement symétrique sur DES , un ancien chiffrement de bloc qui utilise techniquement une clé de 56 bits (, il utilise une clé de 64 bits, mais il ignore 8 de ces bits, donc la taille de clé effective est de 56 bits. Une clé de 56 bits est fissurable, mais pas en cinq minutes avec un PC. Deep crack était une machine spéciale construite en 1998 pour environ 250 000 $, et pouvait casser une clé de 56 bits DES en 4,5 jours en moyenne). La technologie a progressé, et cela peut être reproduit avec quelques dizaines de FPGA . Toujours pas de matériel standard chez Walmart, mais abordable pour de nombreuses personnes.
Toutes les autres suites de chiffrement prises en charge par OpenSSL ne sont pas faibles; si vous avez un problème avec eux, ce ne sera pas dû à une faiblesse cryptographique des algorithmes eux-mêmes. Vous souhaiterez peut-être éviter les suites de chiffrement qui comportent "MD5 ", non pas en raison d'une faiblesse réelle connue, mais pour les relations publiques. MD5 , en tant que fonction de hachage, est" cassé "car nous pouvons trouver efficacement de nombreuses collisions pour cette fonction. Ce n'est pas un problème pour MD5 tel qu'il est utilisé dans SSL; pourtant, cela suffit pour que MD5 ait une mauvaise réputation, et vous feriez mieux de l'éviter.
Notez que la suite de chiffrement n'applique rien sur la taille de la clé de serveur (la clé publique dans le certificat de serveur), qui doit être suffisamment grande pour fournir une robustesse adéquate (pour RSA ou DSS, optez pour 1024 bits au moins, 1536 bits être mieux - mais ne le poussez pas trop, car la surcharge de calcul augmente fortement avec la taille de la clé).
NIST , une organisation fédérale américaine qui est aussi acceptée et connue que n'importe quelle organisation de sécurité peut l'être, en a publié recommandations (voir notamment les tableaux des pages 22 et 23); cela date de 2005 mais est toujours valable aujourd'hui. Notez que le NIST fonctionne sur une base "approuvée/non approuvée": ils ne prétendent en aucune façon que les algorithmes qui ne sont "pas approuvés" sont faibles de quelque façon que ce soit; seulement qu'ils, en tant qu'organisation, ne se portent pas garants d'eux.
Avez-vous lu SSL et TLS: Conception et construction de systèmes sécurisés , par Eric Rescorla? C'est le classique accepté sur SSL, écrit par l'un des principaux contributeurs au groupe de travail sur les normes de l'IETF sur SSL. Je m'attendrais à ce qu'il contienne des déclarations appropriées sur la force de diverses suites de chiffrement SSL.
Si cela ne répond pas à vos besoins, vous pouvez vous promener dans votre bibliothèque conviviale et consulter tous les manuels de cryptographie et de sécurité dont ils disposent et lire les sections écrites sur SSL/TLS.
Fondamentalement, si vous recherchez une référence pour documenter des faits que chaque expert en sécurité connaît déjà, vous devrez peut-être faire quelques démarches par vous-même pour trouver la meilleure citation.
Quelques petits ajouts à la réponse de Thomas Pornin: alors que le NIST SP800-52 reste officiel (s'il est quelque peu obsolète) pour TLS en général, pour les tailles de clés en particulier, il est remplacé par SP800-57: la partie 1 couvre les tailles de clés et les durées de vie en général, révisée juste en dernier année 2012; part3 couvre certaines applications spécifiques, y compris TLS publié en 2010. En bref, ils ont essayé d'exiger RSA DSA et DH 2048 bits et ECC 224 bits en 2011 mais il y avait trop de recul alors maintenant c'est 2014 - bientôt! (DSA à 2048 ou 3072 bits est spécifié par FIPS 186-3 en 2009, mais je ne vois pas encore beaucoup d'implémentation. Même openssl l'a fait assez maladroitement.) Www.CABforum.org est d'accord avec RSA 2048 en 2014; bien que vous n'ayez pas à obtenir votre certificat auprès d'une autorité de certification "officielle", faire visiblement moins que la pratique "standard" courante tend à vous faire traiter avec scepticisme. FWIW NIST dit actuellement que la force (Z_n 2048, ECC 224, symétrique 112) est "acceptable" jusqu'en 2030, après quoi 3072/256/128 est nécessaire; même si elles s'avèrent fausses, si vous les accompagnez, vous avez à peu près la meilleure excuse possible, et vous aurez certainement beaucoup de bonne compagnie. Enfin, csrc.nist.gov est une meilleure URL de départ pour la cybersécurité (le NIST dans son ensemble fait pas mal d'autres choses).
Rattraper les recommandations officielles pourrait être une tâche intimidante pour la plupart des utilisateurs.
Le moyen le plus rapide d'obtenir une liste à jour des chiffres modernes est de vérifier périodiquement le Mozilla SSL Configuration Generator .
En août 2016, la liste (ordonnée) est:
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
Au-delà de la simple application de ces chiffres, assurez-vous de:
- définissez la version TLS sur 1.2 (ou supérieur)
- utilisez une courbe sûre (comme définie sur safecurves.cr.yp.to ).
Remarque: tous ces chiffres sont compatibles avec le TLS1.3 (à venir).