des informations sur le nouveau (CVE-2020-1968) dans le protocole TLS, nom de code
et permettant, dans de rares circonstances, de déterminer une clé primaire préliminaire (pré-maître), qui peut être utilisée pour décrypter les connexions TLS, y compris HTTPS, lors de l'interception du trafic de transit (MITM). Il est à noter que l’attaque est très difficile à mettre en œuvre dans la pratique et est plutôt de nature théorique. Pour mener une attaque, une configuration spécifique du serveur TLS et la capacité de mesurer très précisément le temps de traitement du serveur sont nécessaires.
Le problème est présent directement dans la spécification TLS et affecte uniquement les connexions utilisant des chiffrements basés sur le protocole d'échange de clés DH (Diffie-Hellman, TLS_DH_*"). Avec les chiffrements ECDH, le problème ne se produit pas et ils restent sécurisés. Seuls les protocoles TLS jusqu'à la version 1.2 sont vulnérables ; TLS 1.3 n'est pas concerné par le problème. La vulnérabilité se produit dans les implémentations TLS qui réutilisent la clé secrète DH sur différentes connexions TLS (ce comportement se produit sur environ 4.4 % des serveurs Alexa Top 1M).
Dans OpenSSL 1.0.2e et les versions antérieures, la clé primaire DH est réutilisée dans toutes les connexions serveur, sauf si l'option SSL_OP_SINGLE_DH_USE est explicitement définie. Depuis OpenSSL 1.0.2f, la clé primaire DH n'est réutilisée que lors de l'utilisation de chiffrements DH statiques ("DH-*", par exemple "DH-RSA-AES256-SHA"). La vulnérabilité n'apparaît pas dans OpenSSL 1.1.1, puisque cette branche n'utilise pas de clé primaire DH et n'utilise pas de chiffrements DH statiques.
Lors de l'utilisation de la méthode d'échange de clés DH, les deux côtés de la connexion génèrent des clés privées aléatoires (ci-après clé « a » et clé « b »), sur la base desquelles les clés publiques (ga mod p et gb mod p) sont calculées et envoyées. Une fois que chaque partie a reçu les clés publiques, une clé primaire commune (gab mod p) est calculée, qui est utilisée pour générer des clés de session. L'attaque Raccoon vous permet de déterminer la clé primaire via une analyse de canal secondaire, basée sur le fait que les spécifications TLS jusqu'à la version 1.2 exigent que tous les octets nuls de tête de la clé primaire soient supprimés avant les calculs l'impliquant.
L'inclusion de la clé primaire tronquée est transmise à la fonction de génération de clé de session, qui est basée sur des fonctions de hachage avec des délais différents lors du traitement de différentes données. Mesurer avec précision le timing des opérations clés effectuées par le serveur permet à l'attaquant de déterminer des indices (oracle) qui permettent de juger si la clé primaire repart de zéro ou non. Par exemple, un attaquant pourrait intercepter la clé publique (ga) envoyée par le client, la retransmettre au serveur et déterminer
si la clé primaire résultante commence à zéro.
En soi, définir un octet de clé ne donne rien, mais en interceptant la valeur « ga » transmise par le client lors de la négociation de connexion, l'attaquant peut générer un ensemble d'autres valeurs associées à « ga » et les envoyer à le serveur dans des sessions de négociation de connexion distinctes. En générant et en envoyant des valeurs « gri*ga », l'attaquant peut, en analysant les changements de délais de réponse du serveur, déterminer les valeurs qui conduisent à recevoir des clés primaires à partir de zéro. Après avoir déterminé ces valeurs, l'attaquant peut créer un ensemble d'équations pour et calculez la clé primaire d'origine.
Vulnérabilités OpenSSL faible niveau de danger, et le correctif a été réduit à déplacer les chiffrements problématiques « TLS_DH_* » dans la version 1.0.2w vers la catégorie des chiffrements avec un niveau de protection insuffisant (« chiffrements SSL faibles »), qui est désactivée par défaut . Les développeurs de Mozilla ont fait la même chose, dans la bibliothèque NSS utilisée dans Firefox, les suites de chiffrement DH et DHE. Depuis Firefox 78, les chiffrements problématiques sont désactivés. La prise en charge de Chrome pour DH a été interrompue en 2016. Les bibliothèques BearSSL, BoringSSL, Botan, Mbed TLS et s2n ne sont pas affectées par le problème car elles ne prennent pas en charge les chiffrements DH ou les variantes statiques des chiffrements DH.
Des problèmes supplémentaires sont notés séparément () dans la pile TLS des appareils F5 BIG-IP, rendant l'attaque plus réaliste. En particulier, des écarts dans le comportement des appareils en présence d'un octet zéro au début de la clé primaire ont été identifiés, qui peuvent être utilisés à la place de mesurer la latence exacte des calculs.
Source: opennet.ru