TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 est-il une suite de chiffrement sûre à utiliser?
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 est-il une suite de chiffrement sûre à utiliser pour une connexion TLS 1.2 à un serveur Tomcat? Quelles sont les faiblesses potentielles ou de meilleures alternatives? Je recherche un chiffre pris en charge par Java 8.
Les noms de ciphersuite TLS sont structurés de manière à ce que vous puissiez déterminer les algorithmes et les tailles de clé utilisés pour chaque partie de la prise de contact et de la session cryptée. Décomposons celui-ci et voyons s'il y a des améliorations que nous pouvons apporter:
TLS- Cela ne signifie rien en soi, mais cela me permet de mentionner que TLS 1.2 est la dernière version de TLS et n'a aucune vulnérabilité connue.ECDHE- Diffie-Hellman à courbe elliptique avec touches éphémères. Il s'agit de la méthode d'échange de clés. Les échanges de clés Diffie-Hellman qui utilisent des clés éphémères (générées par session) assurent la confidentialité du transfert, ce qui signifie que la session ne peut pas être déchiffrée après coup, même si la clé privée du serveur est connue. La cryptographie à courbe elliptique offre une puissance équivalente à la cryptographie traditionnelle à clé publique tout en nécessitant des tailles de clé plus petites, ce qui peut améliorer les performances. De plus, ils servent de pari de couverture contre une rupture du RSA.RSA- Le certificat du serveur doit contenir une clé publique RSA et la clé privée correspondante doit être utilisée pour signer les paramètres ECDHE. C'est ce qui permet l'authentification du serveur. L'alternative serait ECDSA, un autre algorithme à courbe elliptique, mais vous pouvez être limité par les types de certificats que votre autorité de certification signera.AES_128- Le chiffrement à chiffrement symétrique est AES avec des clés de 128 bits. Ceci est raisonnablement rapide et non cassé (sauf si vous pensez que NSA a backdoored AES, un sujet pour une autre fois). Autre que AES_256 (qui peut être trop coûteux en termes de performances), c'est le meilleur choix des chiffres symétriques définis dans la RFC 5246 , les autres étant RC4 (qui a des faiblesses connues et qui peuvent être cassées assez rapidement) et 3DES_EDE (qui n'a qu'une force de bits pratique de 108 à 112, selon votre source).CBC- Mode de chaînage de blocs de chiffrement. Voici où vous pouvez probablement améliorer votre choix. Le mode CBC est un moyen d'utiliser un chiffrement par blocs pour crypter une donnée de longueur variable, et il a été la source de problèmes TLS dans le passé: BEAST, Lucky-Thirteen et POODLE étaient toutes des attaques contre TLS en mode CBC. Un meilleur choix pour les performances et la sécurité est AES_128_GCM, qui est l'un des nouveaux chiffrements AEAD introduits dans TLS 1.2 et a de bonnes caractéristiques de performances et de sécurité.SHA256- Il s'agit de la fonction de hachage qui sous-tend la fonction MAC (Message Authentication Code) de la suite de chiffrement TLS. C'est ce qui garantit que chaque message n'a pas été falsifié en transit. SHA256 est un excellent choix et constitue l'algorithme de hachage par défaut pour diverses parties de TLS 1.2. Je suis à peu près sûr que l'utilisation de SHA-1 serait OK ici, car la fenêtre d'exploitation est tellement plus petite que, par exemple la signature du certificat. Les suites de chiffrement AEAD sont authentifiées pour commencer, donc cette étape MAC supplémentaire n'est ni nécessaire ni implémentée.
Essentiellement, vous avez choisi une bonne suite de chiffrement qui ne présente aucun problème pratique pour l'instant, mais vous souhaiterez peut-être passer à une suite de chiffrement AEAD (AES-GCM ou ChaCha20-Poly1305 de Google) pour améliorer les performances et la protection contre les futures vulnérabilités liées à CBC .
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 est aussi "sûr" que n'importe quelle suite de chiffrement: il n'y a aucune faiblesse de protocole connue liée à TLS 1.2 avec cette suite de chiffrement. Tout --- implémentation particulier peut, bien sûr, bâcler les choses et introduire des faiblesses de sa propre initiative. Vous pouvez également piétiner votre propre sécurité au sol, par exemple, en omettant de protéger correctement le stockage de la clé RSA de votre serveur; ou en utilisant la génération de paires de clés faibles pour cette clé RSA; ou désactiver la validation de certificat dans le client; ou toute autre action stupide qui soit réalisable si vous ne le faites pas faites attention.
Il y avait ne mise à jour récente sur tous les chiffrements CBC qui pouvaient les rendre dangereux dans la plupart des situations. Vous devriez donc probablement réévaluer la sécurité de votre serveur en exécutant ne vérification . (Plus informations de SSLLabs )
Quant à quoi utiliser, cfieber a commenté correctement, et vos meilleurs (et seuls) paris pour Java 8 sont maintenant TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 et TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 selon le type de certificat. (Tiré de ici )