Vulnérabilité dans TLS, permettant la détermination de clé pour les connexions basées sur les chiffres DH

Dévoilé informations sur la nouvelle une vulnérabilité (CVE-2020-1968) dans le protocole TLS, surnommé
Raccoon et permettant, dans de rares circonstances, de déterminer la clé primaire préliminaire (pre-master), qui peut être utilisée pour déchiffrer les connexions TLS, y compris HTTPS, lors de l'interception du trafic en transit (MITM). Il est à noter que l'attaque est très difficile à mettre en œuvre dans la pratique et revêt un caractère plus théorique. Pour réaliser cette attaque, une configuration spécifique du serveur TLS et une capacité de mesure du temps de traitement des opérations par le serveur avec une grande précision sont requises.

Le problème est directement présent dans la spécification TLS et ne concerne que les connexions utilisant des algorithmes basés sur le protocole d'échange de clés DH (Diffie-Hellman, TLS_DH_*). Avec les algorithmes ECDH, le problème ne se manifeste pas et ils restent sécurisés. Sont vulnérables uniquement les protocoles TLS jusqu'à la version 1.2 incluse, le protocole TLS 1.3 n'est pas affecté. La vulnérabilité se manifeste dans les implémentations TLS réutilisant la clé secrète DH dans différentes connexions TLS (ce comportement est observé sur environ 4,4 % des serveurs dans le classement 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 spécifiquement activée. À partir d'OpenSSL 1.0.2f, la clé primaire DH est réutilisée uniquement lors de l'utilisation d'algorithmes DH statiques (« DH-* », par exemple « DH-RSA-AES256-SHA »). Dans OpenSSL 1.1.1, la vulnérabilité ne se manifeste pas, car cette branche n'utilise pas la clé primaire DH et n'applique pas d'algorithmes DH statiques.

Lors de l'utilisation de la méthode d'échange de clés DH, les deux parties de la connexion génèrent des clés privées aléatoires (appellées respectivement clé « a » et clé « b »), à partir desquelles des clés publiques (ga mod p et gb mod p) sont calculées et envoyées. Après réception des clés publiques par chaque partie, une clé primaire commune (gab mod p) est calculée, qui est utilisée pour former des clés de session. L'attaque Raccoon permet de déterminer la clé primaire en analysant les informations par des canaux extérieurs, en se basant sur le fait que dans les spécifications TLS jusqu'à la version 1.2, il est stipulé qu'il faut jeter tous les zéros initiaux de la clé primaire avant de procéder aux calculs impliquant celle-ci.

Y compris une clé primaire tronquée qui est transmise à la fonction de génération de clé de session, basée sur des fonctions de hachage présentant des latences différentes lors du traitement de diverses données. La mesure exacte du temps des opérations du serveur avec la clé permet à un attaquant de déterminer des indices (oracle) qui lui permettent de juger si la clé primaire commence par zéro ou non. Par exemple, l'attaquant peut intercepter la clé publique (ga) envoyée par le client, la renvoyer au serveur et déterminer
si la clé primaire résultante commence par zéro.

La détermination d’un seul octet de clé n'apporte rien en soi, mais en interceptant la valeur « ga » transmise lors de l’établissement de la connexion par le client, l’attaquant peut former un ensemble d’autres valeurs liées à « ga » et les envoyer au serveur dans des sessions d’établissement de connexion distinctes. En formant et en envoyant les valeurs « gri*ga », l’attaquant peut, par l’analyse des variations de latence dans la réponse du serveur, déterminer les valeurs qui conduisent à l’obtention de clés primaires commençant par zéro. En identifiant ces valeurs, l'attaquant peut établir un ensemble d'équations pour concernant le problème des nombres cachés et calculer la clé primaire d'origine.

Dans OpenSSL, les vulnérabilités sont attribuées à un niveau de dangerosité faible, et la correction a consisté à déplacer dans la version 1.0.2w les chiffrements problématiques « TLS_DH_* » dans une catégorie de chiffrements désactivée par défaut pour un niveau de protection insuffisant (« weak-ssl-ciphers »). Les développeurs de Mozilla ont agi de la même manière, ayant désactivé dans la bibliothèque NSS utilisée par Firefox, les ensembles de chiffrements DH et DHE. À partir de Firefox 78, les chiffrements problématiques sont désactivés. Dans Chrome, le support de DH a été interrompu depuis 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 (CVE-2020-5929) dans la pile TLS des appareils F5 BIG-IP, rendant l'attaque plus réaliste. En particulier, des écarts de comportement des appareils ont été détectés lorsque un octet nul se trouve au début de la clé primaire, ce qui peut être utilisé à la place de la mesure précise du temps de latence lors des calculs.

Source : opennet.ru