Translated message

A translation of this page exists in English.

SWEET32: Attaques d'anniversaire contre les algorithmes TLS d'une taille de bloc de 64 bit (CVE-2016-2183)

Mis à jour -

Aperçu général

Red Hat Product Security vient de prendre connaissance d'un problème de chiffrement par blocs pour les protocoles SSL/TLS pouvant évoluer en attaque de collision dans certaines conditions. Cette vulnérabilité a été évaluée à un niveau d'impact Modéré et a reçu pour CVE CVE-2016-2183. Ce problème ne requiert aucune action de la part des utilisateurs de produits Red Hat pour l'instant. Veuillez consulter la section Resolution pour obtenir plus d'informations.

Historique

Les chiffrements par blocs hérités ayant des taillles de bloc de 64 bits s'exposent à une attaque de collision réelle, si utilisés en mode CBC. Toutes les versions de protocole SSL/TLS prenant en charge les suites de chiffrement utilisant 3DES comme algorithme de chiffrement symétrique sont touchées (exemple : ECDHE-RSA-DES-CBC3-SHA). Dans les versions d’OpenSSL livrées avec Red Hat Enterprise Linux 6 et 7, qui sont basées sur des suites de chiffrement DES, vous trouverez ci-dessous celles qui prennent en charge AES-128 (avec la suite de chiffrement PFS) et AES-256. Cela signifie que le chiffrement DES est uniquement choisi lorsque le serveur désactive explicitement AES-128 et AES-256. Dans la version d’OpenSSL livrée avec Red Hat Enterprise Linux 5, vous trouverez des suites de chiffrement basées DES au-dessous d'AES-256, mais au dessus d'AES-128. Dans de tels cas, DES n'est choisi que lorsque le serveur désactive explicitement une suite de chiffrement basée AES-256.

La sécurité d'une suite de chiffrement dépend de la taille de la clé (k). De ce fait, la meilleure façon d'attaquer un chiffrement par bloc est d'effectuer une recherche exhaustive par clé, avec une complexité de 2k. Cependant, lorsque les chiffrements par bloc sont utilisés pour chiffrer des montants de données importants par des modes de chiffrement tels que CBC, la taille du bloc (n) joue également un rôle sur le niveau de sécurité.

Quand on utilise le mode de chiffrement CBC, il peut y avoir une attaque anniversaire simple, pour laquelle, une fois que les blocs 2n/2 sont encodés avec la même clé, on peut s'attendre à une collision entre deux blocs de chiffrement. Une collision en sortie indique des entrées identiques. Ces données combinées à un certain nombre de conditions (voir ci-dessous) peut servir à extraire du texte brut de données chiffrées.

Aspect pratique de l'attaque

  1. Tout d'abord, DES/3DES est le seul chiffrement utilisé dans SSL/TLS d'une taille de 64 bits. Comme expliqué dans le récapitulatif, les suites de chiffrement comprenant 3DES sont moins prioritisées que les autres suites de chiffrement (comme AES-128 par exemple).

  2. Pour effectuer une attaque sur des chiffrements par bloc de 64 bit, vous aurez besoin de 32Go de données capturées sur la connexion. Dans le cas de SSL/TLS, cela signifie à partir d'une seule session SSL/TLS. (Pour toutes les nouvelles sessions, SSL/TLS renégocie les clés symétriques). Donc les connexions https longue durée pourraient être vulnérables.

  3. Dans de nombreux contextes, récupérer le xor entre deux blocs de texte brut n'est pas suffisant dans le cas d'une attaque ayant un impact réel. Cependant, la possibilité d'une attaque est bien réelle lorsque les conditions suivantes sont remplies :

    • un secret bien déterminé est envoyé à plusieurs reprises ;

    • certaines parties du texte brut sont connues.

  4. L'attaque POC mentionnée dans le papier publié, assume que le jeton d'authentification passe entre le serveur et le client pour toutes ses communications (le jeton peut être sous forme de cookie d'identifiants utilisée pour l'authentification de base). L'attaquant exécute alors un JavaScript malveillant à l'origine du site sous attaque. Un type d'attaque BEAST peut ensuite être utilisé afin d'extraire le cookie.

Atténuation du risque

  1. Les configurations SSL/TLS doivent favoriser AES par rapport à DES. Les versions d'OpenSSL livrées avec Red Hat Enterprise Linux 6 et 7 le font déjà.
  2. Dans la version d'OpenSSL fournie avec Red Hat Enterprise Linux 5, 3DES se trouve sous la suite AES-256 et au-dessus de la suite AES-128, donc les suites de chiffrement basées AES-256 ne doivent pas être désactivées sur le serveur.
  3. Les serveurs utilisant OpenSSL ne doivent pas désactiver les suites de chiffrement AES-128 et AES-256. Les versions d'Apache fournies avec Red Hat Enterprise Linux utilisent la chaîne de chiffrement par défaut, pour laquelle AES est préféré aux suites de chiffrement basées DES/3DES.

Résolution

  1. Cette vulnérabilité est liée au design de la suite de chiffrement DES/3DES, et n'est pas un problème d'implémentation.
  2. Cette défaillance n'affecte pas directement les bibliothèques cryptographiques (OpenSSL, NSS et GnuTLS) de Red Hat Enterprise Linux 5, 6 et 7, dans la mesure où il existe des suites de chiffrement plus importantes, qui se toruvent au dessus de 3DES dans les configurations des listes de chiffrement par défaut.
  3. Dans Red Hat Enterprise Linux 5, ne pas désactiver les suites de chiffrement basées AES-256 sur le serveur. Dans Red Hat Enterprise Linux 6 et 7, ne pas désactiver les suites de chiffrement basées AES-128 ou AES-256 sur le serveur.

Correctifs de sécurité en amont :

OpenSSL:

OpenSSL a classifié ce problème à un niveau de sécurité « peu élevé ». Ils ont changé les suites de chiffrement de la catégorie HIGH (élevée) à la catégorie MEDIUM (moyenne) pour la branche 1.0.2, et la désactiveront comme étant par défaut dans une prochaine version.

NSS:

Mozilla est entrain d'implémenter des limitations de données pour toutes les suites de chiffrement.

Problèmes associés

Upstream OpenVPN est également exposé à l'attaque Sweet32 et est suivi par CVE CVE-2016-6329. L'implémentation d'OpenVPN de Red Hat n'est pas touchée par ce problème.

Références

https://access.redhat.com/security/cve/CVE-2016-2183
https://sweet32.info/

Comments