Il faut croire que le sujet était difficile, car cela faisait plus de deux ans que les membres de l’IETF étaient en discussion pour promouvoir une nouvelle version du protocole de sécurisation Web TLS 3.1. Il a fallu attendre la 28 ème « brouillon » pour aboutir à quelque chose de concret et de partagé par l’ensemble des acteurs.

L’obligation de sécuriser les accès Internet

Google a annoncé qu’il ne tiendrait plus compte prochainement dans ses périmètres de recherche, des sites qui ne seraient pas sécurisés en mode HTTPS.

C’est une bonne idée sauf que la sécurisation en question reposait jusqu’à maintenant sur un mode SSL, rempli de failles et d’un mode TLS 1.2 qui ne donnait pas satisfaction.

L’événement est donc important qui va concerner tous les développeurs en mal de sécurisation, qui vont devoir adapter leur code s’ils veulent le durcir. Sachant que la tâche ne sera pas insurmontable, dans la mesure où TLS est une couche de sécurisation empilée sur HTTP, qui se charge de l’authentification des serveurs et du contrôle de la confidentialité des échanges de données et leur intégrité. Il peut arriver que cette couche assure aussi l’authentification du client par le serveur, mais c’est plus rare.

La version 1.3 de TLS validée par l’IETF (Internet Engineering Task Force) fonctionne comme les précédentes en mode client-serveur, mais avec plusieurs variantes.

D’abord, ce qui est une bonne chose, elle offre une protection supplémentaire contre les attaques de type « downgrade », qui incitent le serveur à accepter une version ancienne du protocole, moins sécurisée et remplie de failles.

Certains protocoles de hashage disparaissent, MD5 et SHA-224, remplacés par des algorithmes plus performants, tels que x25519, ChaCha20, Poly1305 ou Ed25519.

De plus, les équipes de développement ont systématiquement supprimé toutes les primitives dont s’étaient servis les attaquants pour générer les attaques les plus connues, telles que DROWN, POODLE, SLOTH, CRIME, Logjam et de nombreuses autres.

Pour améliorer la robustesse des échanges, la technique dite PFS (Perfect Forward Secrecy) a été généralisée, fondée sur l’usage de clés éphémères, qui garantissent que si un hacker a réussi à pénétrer une session, il ne pourra pas « jeter » un œil sur les sessions précédentes, qui n’auront pas été menées avec la même clé. Cela dit, c’est surtout au niveau de la session en cours que les critiques (ou les craintes) vont être les plus vives.

Contrairement à TLS 1.2, dans lequel une session initiale de négociation client-serveur était ouverte pour définir le type de chiffrement qui serait utilisé, avec TLS 1.3, c’est le serveur qui décide de la clé de chiffrement à utiliser, sans négociation. Ce qui a au moins l’avantage d’éviter de réutiliser des « vieux machins » qui ont fait la preuve de leur dangerosité…
Un protocole plus performant

Les « penseurs » de l’IETF ont aussi estimé que TLS avait besoin d’être remanié en termes de performances. L’idée était de réduire les « aller-retour » entre client et serveur, plus précisément lors des échanges de négociation de clés (un seul A/R contre deux auparavant). De plus, s’ils ont déjà été en session, il ne sera pas nécessaire d’enclencher une nouvelle négociation et les échanges concrets pourront commencer immédiatement.

Certains spécialistes estiment d’ailleurs que ce choix de favoriser les performances contre la sécurité, au moins sur ce point particulier, pourrait être contre-productif et…dangereux. Cette fonctionnalité porte un nom : « 9-RTT Resumption », qui peut par exemple être implémentée sur les proxies, en frontal des serveurs.

Tout le monde n’est pas d’accord

Cela ne date pas d’hier, mais plusieurs organismes n’apprécient pas les décisions prises par l’IETF, les institutions financières surtout, qui n’auront plus la possibilité comme le passé de déchiffrer et de gérer les connexions TLS, pour les surveiller. Ces institutions voulaient en fait pouvoir placer un backdoor dans le code, qui leur aurait permis d’effectuer cette introspection. Mais l’IETF a refusé, ce qui a fait grincer quelques dents…

D’une manière générale, les sentiments sont mitigés face à la nouvelle norme. Il y a déjà les « contre » qui estiment que le « 9-RTT Resumption » va fragiliser les connexions, qui pourrait servir de cheval de Troie pour les attaquants. Il y a aussi les « pour », qui se disent que de toute façon on ne pouvait guère faire moins bien qu’avec les précédentes versions.

Pour ce qui nous concerne, nous nous demandons ce qu’ont bien pu faire les délégués de l’IETF pendant plus de deux ans, pour aboutir à ce standard… Et nous attendons (sans impatience), l’arrivée de la première grosse attaque d’envergure basée sur le nouveau protocole…

Bien qu’officiellement approuvé, TLS 1.3 demandera un certain temps aux éditeurs de navigateurs pour s’adapter. Bien que la plupart aient anticipé en se fondant sur les versions « draft » de TLS 1.3, ils vont donc devoir se conformer à la version officielle.

Ce qui prendra au minimum toute l’année 2018.