4.1. Directives générales

Les algorithmes cryptographiques s'affaiblissent avec le temps à mesure que la cryptanalyse s'améliore: des algorithmes autrefois considérés comme robustes deviennent faibles. Ces algorithmes doivent être progressivement abandonnés et remplacés par des suites de chiffrement plus sécurisées. Cela aide à garantir que les propriétés de sécurité souhaitées sont toujours maintenues. SSL/TLS existe depuis presque 20 ans et beaucoup des suites de chiffrement qui ont été recommandées dans diverses versions de SSL/TLS sont maintenant considérées comme faibles ou au moins pas aussi robustes que souhaité. Par conséquent, cette section modernise les recommandations concernant la sélection des suites de chiffrement.

• Les implémentations NE DOIVENT PAS négocier les suites de chiffrement avec chiffrement NULL.

  Justification: Les suites de chiffrement NULL ne chiffrent pas le trafic et ne fournissent donc aucun service de confidentialité. Toute entité sur le réseau ayant accès à la connexion peut visualiser le texte en clair des contenus échangés par le client et le serveur. (Néanmoins, ce document ne décourage pas les logiciels d'implémenter des suites de chiffrement NULL, car elles peuvent être utiles pour les tests et le débogage.)

• Les implémentations NE DOIVENT PAS négocier les suites de chiffrement RC4.

  Justification: Le chiffrement par flux RC4 présente une variété de faiblesses cryptographiques, comme documenté dans [RFC7465]. Notez que DTLS interdit déjà spécifiquement l'utilisation de RC4.

• Les implémentations NE DOIVENT PAS négocier les suites de chiffrement offrant moins de 112 bits de sécurité, y compris le chiffrement dit "niveau exportation" (qui fournit 40 ou 56 bits de sécurité).

  Justification: Basé sur [RFC3766], au moins 112 bits de sécurité sont nécessaires. 40 bits et 56 bits de sécurité sont considérés comme non sécurisés aujourd'hui. TLS 1.1 et 1.2 ne négocient jamais les chiffrements d'exportation de 40 ou 56 bits.

• Les implémentations NE DEVRAIENT PAS négocier les suites de chiffrement qui utilisent des algorithmes offrant moins de 128 bits de sécurité.

  Justification: Les suites de chiffrement qui offrent entre 112 bits et 128 bits de sécurité ne sont pas considérées comme faibles à l'heure actuelle; cependant, on s'attend à ce que leur durée de vie utile soit suffisamment courte pour justifier le support de suites de chiffrement plus robustes à l'heure actuelle. Les chiffrements de 128 bits devraient rester sécurisés pendant au moins plusieurs années, et les chiffrements de 256 bits jusqu'à la prochaine avancée technologique fondamentale. Notez que, en raison des attaques dites "meet-in-the-middle" [Multiple-Encryption], certaines suites de chiffrement héritées (par exemple, 3DES de 168 bits) ont une longueur de clé effective qui est plus petite que leur longueur de clé nominale (112 bits dans le cas de 3DES). Ces suites de chiffrement devraient être évaluées selon leur longueur de clé effective.

• Les implémentations NE DEVRAIENT PAS négocier les suites de chiffrement basées sur le transport de clé RSA, également appelé "RSA statique".

  Justification: Ces suites de chiffrement, qui ont des valeurs assignées commençant par la chaîne "TLS_RSA_WITH_*", ont plusieurs inconvénients, en particulier le fait qu'elles ne supportent pas la confidentialité persistante.

• Les implémentations DOIVENT supporter et préférer négocier les suites de chiffrement offrant une confidentialité persistante, telles que celles des familles Diffie-Hellman éphémère et Diffie-Hellman éphémère à courbe elliptique ("DHE" et "ECDHE").

  Justification: La confidentialité persistante (parfois appelée "confidentialité persistante parfaite") empêche la récupération d'informations qui ont été chiffrées avec d'anciennes clés de session, limitant ainsi le temps pendant lequel les attaques peuvent réussir. Voir la Section 6.3 pour une discussion détaillée.