ROBOT : Return Of Bleichenbacher's Oracle Threat
Cryptographie
ROBOT : Return Of Bleichenbacher's Oracle Threat, le retour de la menace de l'oracle de Bleichenbacher. Nom choisi pour former un mot, plutôt qu'un sigle au sens strict. « Une attaque de 1998 revenue en 2017 parce que personne n'avait vraiment fermé la porte derrière elle », par analogie avec le cambrioleur qui repasse vingt ans plus tard et retrouve la clé sous le même paillasson.
L'attaque d'origine : En 1998, Daniel Bleichenbacher montre que si un serveur révèle, même indirectement, si un message chiffré en RSA PKCS #1 v1.5 est correctement formé, un attaquant peut, à force de questions, déchiffrer un message sans la clé privée. Le serveur devient un « oracle » qui répond oui ou non, et chaque réponse fait avancer le calcul.
Le retour : En 2017, Hanno Böck, Juraj Somorovsky et Craig Young constatent que de nombreux serveurs TLS de grands équipementiers et de grands sites restent vulnérables : messages d'erreur, délais ou fermetures de connexion différents trahissent encore la validité du remplissage. Les contre-mesures ajoutées depuis 1998 étaient si délicates à programmer que beaucoup les avaient programmées de travers.
Ce qui est touché : L'échange de clés RSA de TLS 1.2 et antérieurs, dans lequel le client chiffre directement le secret de session avec la clé publique du serveur. L'attaquant peut alors déchiffrer des sessions enregistrées ou produire une signature avec la clé du serveur, au prix d'un grand nombre de requêtes.
Correction : Désactiver les suites de chiffrement à échange de clés RSA (celles qui commencent par TLS_RSA_) au profit d'ECDHE, qui apporte en prime la confidentialité persistante. TLS 1.3 a supprimé cet échange de clés, ce qui règle la question par la méthode la plus fiable : l'abolition.
Ce qui arrive si on s'en passe
Garder l'échange de clés RSA activé sur un serveur TLS 1.2, c'est parier que son implémentation fait partie de celles qui ont réussi un exercice raté par de grands éditeurs vingt ans durant. Si le pari est perdu, un attaquant qui interroge le serveur assez longtemps déchiffre des sessions enregistrées, et comme ce mode n'offre pas de confidentialité persistante, une seule faille ouvre aussi les archives. Une ligne de configuration suffisait pourtant à retirer la mise.
Explication de la marmotte
Pour établir une connexion sécurisée, certains anciens réglages faisaient chiffrer un secret avec la clé du serveur. En 1998, un chercheur a montré que si le serveur répond un peu différemment selon que le message reçu est bien formé ou non, un pirate peut, en posant des milliers de questions, finir par retrouver le secret. En 2017, d'autres chercheurs ont découvert que beaucoup de serveurs avaient encore ce défaut, et ont appelé ce retour ROBOT. La solution est simple : désactiver ces anciens réglages et utiliser les méthodes modernes.
Où ce terme est utilisé
- Choisir ECDSA, EdDSA ou RSA pour un certificat TLS (2 occurrences)
- L'attaque de Bleichenbacher : un oracle de padding contre RSA PKCS#1 v1.5 (2 occurrences)