Je pense que l’idée est plutôt que le jour où ces algorithmes sont défaillants, on change le protocole pour en forcer d’autres et on laisse la transition à la charge de l’utilisateur.
J’ai déjà dit ce que je pensais de la faisabilité de cette approche. Si le futur me donne tort, je serai le premier à en être content, mais je n’y crois guère.
As shown by the continuing torrent of SSL/TLS vulnerabilities, cipher agility increases complexity monumentally.
Il s’agirait quand même de ne pas tout mettre sur le dos de l’agilité cryptographique.
Parmi toutes les attaques contre TLS, moi je n’en compte que deux qui ont été permises par l’agilité cryptographique : FREAK et LOGJAM, qui exploitent des failles dans la procédure de négociation des algorithmes pour forcer l’usage d’algorithmes ridiculement faibles.1
Les autres attaques ? Voyons voir :
L’attaque théorique de Vaudeney (2002), mise en pratique contre TLS par Canvel et al., 2003, une attaque temporelle (timing attack) ;
BEAST, une attaque contre le mode de chiffrement CBC ;
CRIME, une attaque permise par la compression TLS ;
DROWN, causée par le support continu (et complètement absurde) de SSLv2, un protocole que l’on sait complètement cassé depuis environ le lendemain de sa publication en 1995 ;
Sweet32, une attaque contre les algorithmes de chiffrement par bloc opérant sur des blocs de 64 bits ;
TIME et BREACH, semblables à CRIME mais avec la compression au niveau HTTP ;
Triple Handshake, une faille dans le protocole d’établissement d’une connexion (handshake) ;
Il est certain que la complexité générale de TLS est à l’origine de certaines de ces attaques. Mais il n’y a pas que l’agilité cryptographique qui rend TLS complexe ! CRIME et Heartbleed par exemple sont dûes à des fonctionnalités accessoires (la compression pour CRIME et l’extension Heartbeat pour Heartbleed) — des fonctionnalités apparemment peu usitées de surcroît, ce qui rend leur présence dans un protocole de cryptographie assez contestables. Et d’autres protocoles que TLS supportent l’agilité cryptographique sans avoir un tel « palmarès » d’attaques (par exemple SSH).
On peut aussi noter que l’agilité cryptographique a permis d’offrir des contre-mesures immédiates à plusieurs de ces attaques, sans devoir attendre une mise à jour du protocole ou des implémentations (et c’est heureux, parce que vous avez vu le temps qu’il faut pour publier une nouvelle version de TLS ou pour avoir des implémentations à jour ? en 2015 on trouvait encore des serveurs et des clients qui ne supportaient pas TLS 1.2, publié en 2008...).
Par exemple, à la publication de BEAST (attaque contre CBC) en 2011, on a pu conseiller aux sysadmins de privilégier RC4 (qui n’était pas vulnérable, s’agissant d’un algorithme de chiffrement en flux). Deux ans plus tard, les attaques contre RC4 ont commencé à se faire un peu trop pressantes, mais ça a donné un répit de deux ans aux développeurs de bibliothèques TLS pour, soit implémenter des contre-mesures contre BEAST, soit (encore mieux) implémenter TLS 1.1+ (qui n’est plus vulnérable à BEAST), soit implémenter d’autres modes de chiffrement que CBC, voire les trois à la fois.
1 Ce qui n’aurait posé aucun problème si serveurs et clients n’avaient pas continué à supporter les algorithmes ridiculement faibles en question, ce qui me ramène à un point avancé dans un autre message : il n’y a aucune raison pour que « agilité cryptographique » signifie forcément « supporter tous les algorithmes possibles et imaginables, même les plus pourris » — on peut être favorable à l’agilité sans pour autant se priver d’exclure les algorithmes cassés ou en passe de l’être.
[^] # Re: X25519
Posté par gouttegd . En réponse à la dépêche Sortie de la version 1.0.0 de age. Évalué à 10. Dernière modification le 04 novembre 2021 à 02:27.
J’ai déjà dit ce que je pensais de la faisabilité de cette approche. Si le futur me donne tort, je serai le premier à en être content, mais je n’y crois guère.
Il s’agirait quand même de ne pas tout mettre sur le dos de l’agilité cryptographique.
Parmi toutes les attaques contre TLS, moi je n’en compte que deux qui ont été permises par l’agilité cryptographique : FREAK et LOGJAM, qui exploitent des failles dans la procédure de négociation des algorithmes pour forcer l’usage d’algorithmes ridiculement faibles.1
Les autres attaques ? Voyons voir :
Il est certain que la complexité générale de TLS est à l’origine de certaines de ces attaques. Mais il n’y a pas que l’agilité cryptographique qui rend TLS complexe ! CRIME et Heartbleed par exemple sont dûes à des fonctionnalités accessoires (la compression pour CRIME et l’extension Heartbeat pour Heartbleed) — des fonctionnalités apparemment peu usitées de surcroît, ce qui rend leur présence dans un protocole de cryptographie assez contestables. Et d’autres protocoles que TLS supportent l’agilité cryptographique sans avoir un tel « palmarès » d’attaques (par exemple SSH).
On peut aussi noter que l’agilité cryptographique a permis d’offrir des contre-mesures immédiates à plusieurs de ces attaques, sans devoir attendre une mise à jour du protocole ou des implémentations (et c’est heureux, parce que vous avez vu le temps qu’il faut pour publier une nouvelle version de TLS ou pour avoir des implémentations à jour ? en 2015 on trouvait encore des serveurs et des clients qui ne supportaient pas TLS 1.2, publié en 2008...).
Par exemple, à la publication de BEAST (attaque contre CBC) en 2011, on a pu conseiller aux sysadmins de privilégier RC4 (qui n’était pas vulnérable, s’agissant d’un algorithme de chiffrement en flux). Deux ans plus tard, les attaques contre RC4 ont commencé à se faire un peu trop pressantes, mais ça a donné un répit de deux ans aux développeurs de bibliothèques TLS pour, soit implémenter des contre-mesures contre BEAST, soit (encore mieux) implémenter TLS 1.1+ (qui n’est plus vulnérable à BEAST), soit implémenter d’autres modes de chiffrement que CBC, voire les trois à la fois.
1 Ce qui n’aurait posé aucun problème si serveurs et clients n’avaient pas continué à supporter les algorithmes ridiculement faibles en question, ce qui me ramène à un point avancé dans un autre message : il n’y a aucune raison pour que « agilité cryptographique » signifie forcément « supporter tous les algorithmes possibles et imaginables, même les plus pourris » — on peut être favorable à l’agilité sans pour autant se priver d’exclure les algorithmes cassés ou en passe de l’être.