Les travaux sur la nouvelle version du protocole TLS 1.3 sont presque terminés. Après quatre ans de discussion en mars 2018, l'IETF a approuvé la
28e version du projet en tant que norme proposée, elle devrait donc être la dernière avant d'adopter les spécifications finales.
TLS 1.3 accélère le processus d'établissement d'une connexion sécurisée d'environ la moitié en combinant plusieurs étapes à ce stade. En outre, il met en œuvre un régime de secret direct parfait grâce aux clés éphémères (CE) DH. Ce mode garantit la protection des clés de session même en cas de compromission de clés à long terme.
De nombreuses autres améliorations ont été mises en œuvre, notamment la prise en charge du chiffrement de flux ChaCha20, les algorithmes de signature numérique Ed25519 et Ed448, les protocoles d'échange de clés x25519 et x448, etc. La prise en charge des fonctions de hachage MD5 et SHA-224 obsolètes, les courbes elliptiques faibles et rarement utilisées a été supprimée
Mais le plus intéressant est la nouvelle idée qui est
discutée à l'IETF . Les experts de Google suggèrent de générer périodiquement au hasard une nouvelle version du protocole TLS avec des modifications mineures. L'idée est que des mises à jour fréquentes seront un antidote à une ossification dangereuse.
Quel est ce problème?
La soi-disant "ossification" est une situation où les développeurs de protocoles se rendent soudain compte qu'il est difficile d'introduire des améliorations en raison de la large distribution de l'ancienne version, qui pour une raison quelconque convient aux utilisateurs. En réalité, l'ancienne version ne répond plus aux exigences de sécurité modernes et aux nouvelles spécifications, mais elle ne peut pas être implémentée de facto.
On
pense que les nœuds dits intermédiaires, à savoir les fournisseurs de solutions dans le domaine de la «sécurité», sont devenus le principal «frein» spécifiquement avec la mise en œuvre de TLS 1.3. Ils conseillent à leurs clients de prescrire
des règles de pare-feu spécifiques avec l'analyse des certificats lorsqu'ils se serrent la main avec TLS. Dans la nouvelle version de la norme,
les certificats SSL sont cryptés, de sorte que les intermédiaires ne pourront plus les analyser.
Comment la mise à jour constante résoudra-t-elle le problème d'ossification du protocole?
La mise à jour continue toutes les six semaines est un schéma courant du navigateur Chrome. Dans cette situation, les "interprètes" sont
obligés de se conformer au cahier des charges, car une implémentation incompatible ne fonctionnera pas pour une grande partie des utilisateurs.
Sur la liste de diffusion de l'IETF, cette idée a été
suggérée par David Benjamin du projet Chromium. Il écrit que TLS 1.3 est un protocole extensible qui est rétrocompatible avec TLS 1.2. Il peut être déployé progressivement, mettant à jour les implémentations actuelles de TLS 1.2. Et ici, il y a des problèmes. De nombreux serveurs incompatibles ne pourront pas établir de connexion à l'étape TLS 1.3 ClientHello, vous devrez donc revenir en arrière pour établir une connexion à l'aide de la version de protocole prise en charge.
David Benjamin avance l'idée de comment éviter ce problème à l'avenir. Discutant des mesures préventives, il mentionne
les invariants de protocole qui sont énumérés à l'article 9.3 du cahier des charges. Tous les noeuds finaux et nœuds intermédiaires
doivent respecter les invariants décrits. En particulier, les nouveaux clients et les nouveaux serveurs n'ont pas le droit de réduire le niveau des paramètres à l'ancienne version. De la même manière, les nœuds intermédiaires n'ont pas le droit de le faire lors du transfert de la connexion entre le client et le serveur mis à jour et ne peuvent pas affecter la prise de contact. Cependant, compte tenu de la vitesse de mise à jour inégale, les clients et serveurs mis à jour peuvent prendre en charge l'établissement de la communication en utilisant l'ancien protocole, mais uniquement de la manière correcte décrite dans la clause 9.3.
Mais la pratique montre qu'il ne suffit pas de décrire le comportement requis dans les spécifications. Comment
forcer les nœuds intermédiaires à respecter la règle clé du traitement ClientHello - ignorer les paramètres non reconnus? Pour cela, la méthode
GREASE est proposée.
GRAISSE: antidote contre l'ossification
GREASE (Generate Random Extensions And Sustain Extensibility) est une méthode pour générer
des extensions
aléatoires pour TLS et la sortie constante de nouvelles versions du protocole. David Benjamin propose d'établir un cycle de sortie standard de six semaines, qui coïncidera avec la sortie de nouvelles versions de Chrome.
La libération de telles "ordures" en grand nombre obligera les serveurs à se conformer à la règle clé du traitement ClientHello pour ignorer les paramètres non reconnus. Il se propagera également aux nœuds intermédiaires. Afin qu'ils n'interfèrent pas dans la communication entre le client et le serveur, la règle clé pour eux est la suivante: si vous n'avez pas envoyé de demande ClientHello, vous n'avez pas le droit de traiter la réponse. De même, l'écosystème devrait être inondé d'un grand nombre de ces réponses.
"En bref, nous prévoyons de tamponner régulièrement les nouvelles versions de TLS (et probablement d'autres paramètres sensibles tels que les extensions)", a déclaré Benjamin, exprimant apparemment le point de vue de Google. - environ toutes les six semaines, selon le calendrier de sortie de Chrome. Ensuite, Chrome, les serveurs de Google et tous ceux qui souhaitent participer prendront en charge deux (ou plus) versions de TLS 1.3: le standard stable 0x0304 et la version alternative temporaire. Toutes les six semaines, nous sélectionnons au hasard un nouveau point de code. À tous les autres égards, ces versions sont identiques à 1.3, à l'exception peut-être de détails mineurs pour séparer les clés et apporter des modifications syntaxiques autorisées. Le but est d'ouvrir la voie aux futures versions de TLS en les imitant (ébauche négative). »
Un tel schéma présente certains risques, notamment des collisions de points de code. De plus, des précautions doivent être développées, car la tâche est de maintenir et de maintenir l'extensibilité de TLS, et de ne pas interférer avec le développement du protocole. Des mesures de précaution:
- Documentation détaillée de tous les points de code (lors de l'élaboration d'un point en un mois et demi, ils suffiront pendant plus de 7000 ans).
- Évitement proactif des collisions: rejet des numéros que l'IETF peut choisir.
- BoringSSL n'activera pas cette option par défaut. Il ne sera activé que là où il peut être désactivé: sur les serveurs et dans le navigateur. En réalité, très probablement, à chaque instant, seuls les derniers points de code seront utilisés. Parce qu'ils évoluent rapidement, l'écosystème ne devrait pas être attaché à une telle expansion temporaire, et les implémentations resteront compatibles les unes avec les autres.
- Si pour une raison quelconque la méthode ne fonctionne pas, l'expérience peut être arrêtée à tout moment.
L'idée est intéressante, et si Google commence à agir de cette manière, elle peut vraiment sauver l'écosystème d'une dangereuse «ossification» due aux fournisseurs de solutions dans le domaine de la «sécurité» et à d'autres systèmes d'entreprise spécifiques. Un représentant de Cloudflare a
soutenu cette proposition. Dans tous les cas, a-t-il dit, au moins quelque chose doit être fait pour éviter le problème que nous avons rencontré lors de la mise en œuvre de TLS 1.3. Un autre membre du groupe de travail de l'IETF l'a
qualifiée d '"idée fantastique" et a suggéré que Google crée une page wiki qui décrit les points de code qu'il utilise ou prévoit d'utiliser à l'avenir.
