La Fibre
Télécom => Réseau => 
Protocoles réseaux sécurisés (https) => Discussion démarrée par: vivien le 26 mars 2018 à 20:31:55
-
Le protocole TLS 1.3 approuvé par l'IETF
(https://lafibre.info/images/logo/logo_tls_1.3.webp)
Cette version promet une sécurité plus robuste et de meilleures performances
L'IETF (Internet Engineering Task Force), l'organisme d'élaboration des standards Internet, vient d'approuver la norme de sécurité TLS 1.3. Rappelons que comme son prédécesseur SSL (Secure Sockets Layer), TLS (Transport Layer Security) est un protocole de sécurisation des échanges sur Internet. Il fonctionne suivant un mode client-serveur et permet de satisfaire à un certain nombre d'objectifs de sécurité. Parmi ceux-ci, on note l'authentification du serveur, la confidentialité des données échangées (ou session chiffrée) et l'intégrité des données échangées. De manière optionnelle, il permet aussi l'authentification du client, même si dans la réalité celle-ci est souvent assurée par le serveur.
Les protocoles de sécurisation des échanges sur Internet sont très largement utilisés, étant donné que leur mise en œuvre est facilitée par le fait que les protocoles de la couche application, comme HTTP, n'ont pas à être profondèment modifiés pour utiliser une connexion sécurisée, mais ils sont seulement implèmentés au-dessus des premiers (TLS ou SSL). Le protocole HTTP sécurisé (HTTPS) est par exemple une simple combinaison du HTTP avec une couche de chiffrement comme SSL ou TLS. Mais SSL est banni depuis 2014 à cause de nombreuses failles de sécurité qui ont montré ses faiblesses.
TLS 1.3, qui devrait être à présent la version recommandée, vient d'être approuvé après 4 ans de travail et 28 drafts. Le nouveau protocole renforce encore la sécurisation des échanges et promet de meilleures performances que les autres versions de TLS. L'un des principaux changements est que TLS 1.3 abandonne les algorithmes de chiffrement et de hachage obsolètes, tels que MD5 et SHA-224, pour des alternatives plus sécurisées comme ChaCha20, Poly1305, Ed25519, x448 et x25519.
« TLS 1.3 représente un bond en avant significatif pour la sécurité », explique Cloudfare dont les ingénieurs ont participé au développement du protocole. « TLS 1.3 supprime toutes les primitives et les fonctionnalités qui ont contribué à une configuration faible et permis les vulnérabilités courantes telles que DROWN, Vaudenay, Lucky 13, POODLE, SLOTH, CRIME et bien d'autres. Des fonctionnalités supplèmentaires ont été ajoutées pour améliorer la sécurité et la robustesse du protocole. » Cette version offre en effet une protection contre les attaques de type « downgrade » par lesquelles un attaquant incite un serveur à utiliser une ancienne version du protocole ayant des vulnérabilités connues.
Sans se limiter à la sécurité, le nouveau protocole met également un accent sur la performance. « TLS 1.3 représente un tournant décisif pour les performances HTTPS », estime Cloudfare. Il diminue en effet la latence de connexion en réduisant le nombre d'allers-retours entre le client et le serveur.
(https://lafibre.info/images/ssl/201803_tls_1point2.png) (https://lafibre.info/images/ssl/201803_tls_1point3.png)
Parmi les principales nouveautés, on peut encore citer des fonctionnalités telles que TLS False Start et Zero Round Trip Time (0-RTT) qui sont censées réduire le temps de connexion à des hôtes avec lesquels le client a déjà communiqué. Elles permettent donc d'avoir une expérience Web plus rapide et plus fluide pour les sites Web que vous visitez régulièrement.
Source : Developpez.com (https://www.developpez.com/actu/195330/Le-protocole-TLS-1-3-approuve-par-l-IETF-cette-version-promet-une-securite-plus-robuste-et-de-meilleures-performances/), le 26 mars 2018, par Michael Guilloux, Chroniqueur Actualités.
Edit : Premières implémentations des version de SSL / TLS :
(https://lafibre.info/images/ssl/201806_firefox_61_tls13.jpg)
Statistique du déploiement de TLS 1.3 sur Internet :
(https://lafibre.info/images/ssl/statistiques_sites_https_populaires.webp)
Edit : Support par navigateur web
- Firefox : version 60 du 9 mai 2018 cf Firefox 60 release notes (https://www.mozilla.org/en-US/firefox/60.0/releasenotes/)
- Chrome : version 70 du 16 octobre 2018
- Vivaldi : version 2.1 du 24 octobre 2018
- Opera : version 57 du 28 novembre 2018
- Samsung Internet : version 10.1 du 8 septembre 2019
- iOS : iOS 12.2 du 25 mars 2019
- Safari : Safari sur macOS Mojave 10.14.4 du 25 mars 2019 (ce n'est pas la version de Safari qui importe, mais la version du système d’exploitation)
- Edge : version 79 du 15 janvier 2020
(https://lafibre.info/images/ssl/tls13_support.webp) (https://lafibre.info/images/ssl/http3_support.webp)
-
Fonctionnalités supprimées de TLS 1.3 :
- Static RSA handshake
- CBC MtE modes (https://fr.wikipedia.org/wiki/Mode_d%27op%C3%A9ration_(cryptographie)) (Dans ce mode, on applique sur chaque bloc un ‘OU exclusif’ avec le chiffrement du bloc précédent avant qu’il soit lui-même chiffré)
- RC4 (https://fr.wikipedia.org/wiki/RC4) (algorithme de chiffrement en continu conçu en 1987)
- MD5 (https://fr.wikipedia.org/wiki/MD5) (fonction de hachage cryptographique inventée en 1991)
- SHA1 (https://fr.wikipedia.org/wiki/SHA-1) (fonction de hachage cryptographique conu par la NSA en 1995)
- Compression (Permet d'activer la compression au niveau SSL. L'activation de la compression est à l'origine de problèmes de sécurité dans la plupart des configurations: l'attaque nommée CRIME)
- Renegotiation (permet une attaque Man-In-The-Middle)
Fonctions ajoutées à TLS 1.3 :
- Full handshake signature
- Downgrade protection (pour éviter une attaque Man-In-The-Middle qui baisse le chiffrement afin de pouvoir décoder le flux)
- Reprise abrégée avec option (EC)DHE (Échange de clés Diffie-Hellman basé sur les courbes elliptiques (https://fr.wikipedia.org/wiki/%C3%89change_de_cl%C3%A9s_Diffie-Hellman_bas%C3%A9_sur_les_courbes_elliptiques))
- Curve 25519 (https://fr.wikipedia.org/wiki/Curve25519) and 448 : Les algorithmes de courbe elliptique sont maintenant dans la spécification de base dans TLS 1.3
Des banques et des entreprises voulaient intégrer une porte dérobée afin de pouvoir analyser le trafic dans TLS 1.3, officiellement pour se prémunir d'attaque.
L'option n'a pas été retenue, car ce type de possibilité entraîne un risque sécurité non négligeable malgré les idées de tiers de confiance émises.
-
Une porte dérobée est toujours une mauvaise idée...
-
Doit-on / peut-on activer TLS 1.3 ? Je n'ai que le 1.2 d'activé sur tes conseils et ceux de Hugues.
-
TLS 1.3 sera activé automatiquement quand il sera disponible.
TLS 1.3 a été normalisé le 1er mars 2018 et il n'est pas encore disponible sur les distribution serveur les plus utilisées.
Les distributions qui sortiront en 2019 devaient toutes intégrer TLS 1.3
TLS 1.0 et TLS 1.1 peuvent être désactivés si tu n'as pas besoin de compatibilité avec les veilles versions d'Internet Explorer.
Je l'ai désactivé sur tous mes sites sauf lafibre.info.
J'envisage une désactivation de TLS 1.0 et 1.1 pour lafibre.info au second semestre 2018.
-
Merci pour tes précisions Vivien.
J'ai en effet désactivé TLS 1.0 et 1.1 pour ne garder que TLS 1.2, j'attendrai donc le support officiel de TLS 1.3 pour l'activer.
-
Si tu utilises la ligne SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 TLS 1.3 sera activé automatiquement quand il sera disponible : cette configuration désactive les vieux protocoles, ce qui permet lors de l'apparition d'un nouveau qu'il soit activé automatiquement.
Note: on ne désactive pas SSLv2 qui n'est plus implèmenté
-
Ma ligne est SSLProtocol -all +TLSv1.2 ce qui limite en effet au seul protocol 1.2
-
Ce n'est pas recommandé. Je t'invite à utiliser ma ligne.
-
:)
-
Je ne retrouve plus dans quel fichier je dois modifier cette ligne, ni si je dois où non refaire le certificat Let's Encrypt après modification de la ligne.
-
Avec Ubuntu, cela se trouve par défaut dans /etc/apache2/mods-available/ssl.conf
Le code par défaut avec Ubuntu 16.04 LTS :
# The protocols to enable.
# Available values: all, SSLv3, TLSv1, TLSv1.1, TLSv1.2
# SSL v2 is no longer supported
SSLProtocol all -SSLv3
-
Avec Ubuntu, cela se trouve par défaut dans /etc/apache2/mods-available/ssl.conf
Merci Vivien, je suis sous Debian Raspbian.
J'ai déjà modifié cette ligne mais cela ne change pas dans ssllabs.com.
Dois-je refaire le certificat let's encrypt pour que ce soit pris en compte ?
-
Normalement non, par contre il faut bien penser à recharger la configuration Apache :)
-
Je n'ai toujours pas tls1.3 d'activé alors que j'ai changé la ligne dans ssl.conf d'apache et que j'ai recharger apache.
Y aurait'il un autre endroit où indiquer la config ssl ?
Je n'ose pas trop refaire le certificat car on est limité à 5 tous les 7 jours et j'en ai déjà fait plusieurs cette fin de semaine et je crois bien l'avoir fait après avoir changé la config dans ssl.conf
-
Si c'est pour TLS 1.3, j'ai souligné la réponse:
Si tu utilises la ligne SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 TLS 1.3 sera activé automatiquement quand il sera disponible : cette configuration désactive les vieux protocoles, ce qui permet lors de l'apparition d'un nouveau qu'il soit activé automatiquement.
Note: on ne désactive pas SSLv2 qui n'est plus implèmenté
-
Oui j'ai vue, mais dans ce cas pourquoi lorsque je test le serveur d'un forum que je fréquente :
Protocols
TLS 1.3 Yes
TLS 1.2 Yes
TLS 1.1 Yes
TLS 1.0 Yes
SSL 3 No
SSL 2 No
Donc cela peut s'activer non ?
-
Oui, mais pas encore conseillé si ton système ne le fait pas par défaut.
Pour Ubuntu, je n'ai trouvé qu'une implèmentation en version alpha via OpenSSL ou autres.
Donc possible, mais de l'alpha sur un serveur, c'est bof... À toi de voir.
-
Merci pour la précision ;)
-
Debian 10 (sortie probable en 2019) et Ubuntu 18.10 auront probablement TLS 1.3.
Cela sera aussi la fin de TLS 1.0 et TLS 1.1 su Debian 10 : OpenSSL abandonne le support des versions TLS 1.0/1.1 sur Debian Unstable (https://lafibre.info/cryptographie/debian-tls/)
Pour les navigateurs, TLS 1.3 est activé (prise en charge par défaut du dernier draft de TLS 1.3) à partir de Firefox 60 sortie cette semaine.
-
Firefox 61 est la première version de Firefox vec le support de TLS1.3 activé par défaut
=> https://www.mozilla.org/en-US/firefox/61.0/releasenotes/
(https://lafibre.info/images/ssl/201806_firefox_61_tls13.png)
(https://lafibre.info/images/ssl/201806_firefox_61_tls13.jpg)
Source : CloudFlare: A Detailed Look at RFC 8446 (a.k.a. TLS 1.3) (https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/) le 10 aout 2018
-
Stéphane Bortzmeyer a réalisé sur son blog http://www.bortzmeyer.org/ un article décrivant pas à pas le contenu de la RFC 8446 (https://www.rfc-editor.org/rfc/rfc8446.txt) qui décrit TLS Version 1.3.
L'article est sous licence GFDL (GNU Free Documentation License (https://fr.wikipedia.org/wiki/Licence_de_documentation_libre_GNU)) un licence proche de CC-BY-SA (Creative Commons - paternité - partage à l'identique) utilisé sur ce forum.
RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
Après un très long processus, et d'innombrables polémiques, la nouvelle version du protocole de cryptographie (https://fr.wikipedia.org/wiki/Cryptographie) TLS, la 1.3, est enfin publiée. Les changements sont nombreux et, à bien des égards, il s'agit d'un nouveau protocole (l'ancien était décrit dans le RFC 5246 (http://www.bortzmeyer.org/5246.html), que notre nouveau RFC remplace).
Vous pouvez voir l'histoire de ce RFC sur la Datatracker de l'IETF (https://datatracker.ietf.org/doc/rfc8446/). Le premier brouillon a été publié en avril 2014, plus de trois années avant le RFC. C'est en partie pour des raisons techniques (TLS 1.3 est très différent de ses prédécesseurs) et en partie pour des raisons politiques. C'est que c'est important, la sécurité ! Cinq ans après les révélations de Snowden (https://fr.wikipedia.org/wiki/Edward_Snowden), on sait désormais que des acteurs puissants et sans scrupules, par exemple les États, espionnent massivement le trafic Internet. Il est donc crucial de protéger ce trafic, entre autres par la cryptographie (https://fr.wikipedia.org/wiki/Cryptographie). Mais dire « cryptographie » ne suffit pas ! Il existe des tas d'attaques contre les protocoles de cryptographie, et beaucoup ont réussi contre les prédécesseurs de TLS 1.3. Il était donc nécessaire de durcir le protocole TLS, pour le rendre moins vulnérable. Et c'est là que les ennuis ont commencé. Car tout le monde ne veut pas de la sécurité. Les États veulent continuer à espionner (le GCHQ (https://fr.wikipedia.org/wiki/Government_Communications_Headquarters) britannique s'était clairement opposé à TLS 1.3 sur ce point (https://www.ncsc.gov.uk/blog-post/tls-13-better-individuals-harder-enterprises)). Les entreprises veulent espionner leurs employés (et ont pratiqué un lobbying intense contre TLS 1.3). Bref, derrière le désir de « sécurité », partagé par tout le monde, il y avait un désaccord de fond sur la surveillance. À chaque réunion de l'IETF (https://fr.wikipedia.org/wiki/Internet_Engineering_Task_Force), une proposition d'affaiblir TLS pour faciliter la surveillance apparaissait, à chaque fois, elle était rejetée et, tel le zombie des films d'horreur (https://fr.wikipedia.org/wiki/Film_de_zombies), elle réapparaissait, sous un nom et une forme différente, à la réunion suivante. Par exemple, à la réunion IETF de Prague en juillet 2017, l'affrontement a été particulièrement vif, alors que le groupe de travail TLS espérait avoir presque fini la version 1.3. Des gens se présentant comme enterprise networks ont critiqué les choix de TLS 1.3, notant qu'il rendait la surveillance plus difficile (c'était un peu le but…) gênant notamment leur déboguage. Ils réclamaient un retour aux algorithmes n'ayant pas de sécurité persistante (https://fr.wikipedia.org/wiki/Confidentialit%C3%A9_persistante). Le début a suivi le schéma classique à l'IETF : « vous réclamez un affaiblissement de la sécurité » vs. « mais si on ne le fait pas à l'IETF, d'autres le feront en moins bien », mais, au final, l'IETF est restée ferme et n'a pas accepté de compromissions sur la sécurité de TLS. (Un résumé du débat est dans « TLS 1.3 in enterprise networks (https://www.cs.uic.edu/~s/musings/tls13-enterprises/) ».)
Pour comprendre les détails de ces propositions et de ces rejets, il faut regarder un peu en détail le protocole TLS 1.3.
Les fondamentaux :
Revenons d'abord sur les fondamentaux : TLS (https://fr.wikipedia.org/wiki/Transport_Layer_Security) est un mécanisme permettant aux applications client/serveur de communiquer au travers d'un réseau non sûr (par exemple l'Internet) tout en empêchant l'écoute et la modification des messages. TLS suppose un mécanisme sous-jacent pour acheminer les bits dans l'ordre, et sans perte. En général, ce mécanisme est TCP.
Avec ce mécanisme de transport, et les techniques cryptographiques mises en œuvre par dessus, TLS 1.3 garantit :
- L'authentification (https://fr.wikipedia.org/wiki/Authentification) du serveur (celle du client est facultative), authentification qui permet d'empêcher l'attaque de l'intermédiaire (https://fr.wikipedia.org/wiki/Attaque_de_l%27homme_du_milieu), et qui se fait en général via la cryptographie asymétrique (https://fr.wikipedia.org/wiki/Cryptographie_asym%C3%A9trique),
- La confidentialité des données (https://fr.wikipedia.org/wiki/Confidentialit%C3%A9) (mais attention, TLS ne masque pas la taille des données, permettant certaines analyses de trafic),
- L'intégrité (https://fr.wikipedia.org/wiki/Int%C3%A9grit%C3%A9_(cryptographie)) des données (qui est inséparable de l'authentification : il ne servirait pas à grand'chose d'être sûr de l'identité de son correspondant, si les données pouvaient être modifiées en route).
Ces propriétés sont vraies même si l'attaquant contrôle complètement le réseau entre le client et le serveur (le modèle de menace est détaillé dans la section 3 - surtout la 3.3 - du RFC 3552 (http://www.bortzmeyer.org/3552.html), et dans l'annexe E de notre RFC).
TLS est un protocole gros et compliqué (ce qui n'est pas forcèment optimum pour la sécurité). Le RFC fait 147 pages.
Pour dompter cette complexité, TLS est séparé en deux composants :
- Le protocole de salutation (handshake protocol), chargé d'organiser les échanges du début, qui permettent de choisir les paramètres de la session (c'est un des points délicats de TLS, et plusieurs failles de sécurité ont déjà été trouvées dans ce protocole pour les anciennes versions de TLS),
- Et le protocole des enregistrements (record protocol), au plus bas niveau, chargé d'acheminer les données chiffrées.
Pour comprendre le rôle de ces deux protocoles, imaginons un protocole fictif simple, qui n'aurait qu'un seul algorithme de cryptographie symétrique (https://fr.wikipedia.org/wiki/Cryptographie_sym%C3%A9trique), et qu'une seule clé, connue des deux parties (par exemple dans leur fichier de configuration). Avec un tel protocole, on pourrait se passer du protocole de salutation, et n'avoir qu'un protocole des enregistrements, indiquant comment encoder les données chiffrées. Le client et le serveur pourraient se mettre à communiquer immédiatement, sans salutation, poignée de mains et négociation, réduisant ainsi la latence. Un tel protocole serait très simple, donc sa sécurité serait bien plus facile à analyser, ce qui est une bonne chose. Mais il n'est pas du tout réaliste : changer la clé utilisée serait complexe (il faudrait synchroniser exactement les deux parties), remplacer l'algorithme si la cryptanalyse (https://fr.wikipedia.org/wiki/Cryptanalyse) en venait à bout (comme c'est arrivé à RC4 (https://fr.wikipedia.org/wiki/RC4), cf. RFC 7465 (http://www.bortzmeyer.org/7465.html)) créerait un nouveau protocole incompatible avec l'ancien, communiquer avec un serveur qu'on n'a jamais vu serait impossible (puisque on ne partagerait pas de clé commune), etc.
D'où la nécessité du protocole de salutation, où les partenaires :
- S'authentifient avec leur clé publique (ou, si on veut faire comme dans le protocole fictif simple, avec une clé secrète partagée),
- Sélectionnent l'algorithme de cryptographie symétrique qui va chiffrer la session, ainsi que ses paramètres divers,
- Choisir la clé de la session TLS (et c'est là que se sont produites les plus grandes bagarres lors de la conception de TLS 1.3).
Notez que TLS n'est en général pas utilisé tel quel mais via un protocole de haut niveau, comme HTTPS (https://fr.wikipedia.org/wiki/HyperText_Transfer_Protocol_Secure) pour sécuriser HTTP. TLS ne suppose pas un usage particulier : on peut s'en servir pour HTTP, pour SMTP (RFC 7672 (http://www.bortzmeyer.org/7672.html)), pour le DNS (RFC 7858 (http://www.bortzmeyer.org/7858.html)), etc. Cette intégration dans un protocole de plus haut niveau pose parfois elle-même des surprises en matière de sécurité, par exemple si l'application utilisatrice ne fait pas attention à la sécurité (Voir mon exposé à Devoxx (http://blog.soat.fr/2014/04/devoxx-2014-utiliser-tls-sans-se-tromper-une-conference-animee-par-stephane-bortzmeyer/), et ses transparents (http://www.bortzmeyer.org/files/bortzmeyer-tls-devoxx.odp).)
TLS 1.3 est plutôt un nouveau protocole qu'une nouvelle version, et il n'est pas directement compatible avec son prédécesseur, TLS 1.2 (une application qui ne connait que 1.3 ne peut pas parler avec une application qui ne connait que 1.2.) En pratique, les bibliothèques qui mettent en œuvre TLS incluent en général les différentes versions, et un mécanisme de négociation de la version utilisée permet normalement de découvrir la version maximum que les deux parties acceptent (historiquement, plusieurs failles sont venues de ce point, avec des pare-feux stupidement configurés qui interféraient avec la négociation).
Section 1.3 : Différences importantes entre TLS 1.2 et TLS 1.3 :
La section 1.3 de notre RFC liste les différences importantes entre TLS 1.2 (qui était normalisé dans le RFC 5246 (http://www.bortzmeyer.org/5246.html)) et 1.3 :
- La liste des algorithmes de cryptographie symétrique acceptés a été violemment réduite. Beaucoup trop longue en TLS 1.2, offrant trop de choix, comprenant plusieurs algorithmes faibles, elle ouvrait la voie à des attaques par repli (https://en.wikipedia.org/wiki/Downgrade_attack). Les « survivants » de ce nettoyage sont tous des algorithmes à chiffrement intègre (https://en.wikipedia.org/wiki/Authenticated_encryption).
- Un nouveau service apparait, 0-RTT (zero round-trip time, la possibilité d'établir une session TLS avec un seul paquet, en envoyant les données tout de suite), qui réduit la latence du début de l'échange. Attention, rien n'est gratuit en ce monde, et 0-RTT présente des nouveaux dangers, et ce nouveau service a été un des plus controversés (https://github.com/tlswg/tls13-spec/issues/1001) lors de la mise au point de TLS 1.3, entrainant de nombreux débats à l'IETF.
- Désormais, la sécurité future (https://fr.wikipedia.org/wiki/Confidentialit%C3%A9_persistante) est systématique, la compromission d'une clé secrète ne permet plus de déchiffrer les anciennes communications. Plus de clés publiques statiques, tout se fera par clés éphémères (https://en.wikipedia.org/wiki/Ephemeral_key). C'était le point qui a suscité le plus de débats à l'IETF, car cela complique sérieusement la surveillance (ce qui est bien le but) et le déboguage.
- Plusieurs messages de négociation qui étaient auparavant en clair sont désormais chiffrés. Par contre, l'indication du nom du serveur (SNI, section 3 du RFC 6066 (http://www.bortzmeyer.org/6066.html)) reste en clair et c'est l'une des principales limites de TLS en ce qui concerne la protection de la vie privée. Le problème est important, mais très difficile à résoudre (voir par exemple la proposition ESNI, Encrypted SNI (https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/).)
- Les fonctions de dérivation de clé (https://fr.wikipedia.org/wiki/Fonction_de_d%C3%A9rivation_de_cl%C3%A9) ont été refaites.
- La machine à états (https://fr.wikipedia.org/wiki/Automate_fini) utilisée pour l'établissement de la connexion également (elle est détaillée dans l'annexe A du RFC).
- Les algorithmes asymétriques à courbes elliptiques (https://fr.wikipedia.org/wiki/Cryptographie_sur_les_courbes_elliptiques) font maintenant partie de la définition de base de TLS (cf. RFC 7748 (http://www.bortzmeyer.org/7748.html)), et on voit arriver des nouveaux comme ed25519 (https://en.wikipedia.org/wiki/EdDSA#Ed25519) (cf. RFC 8422 (http://www.bortzmeyer.org/8422.html)).
- Par contre, DSA (https://fr.wikipedia.org/wiki/Digital_Signature_Algorithm) a été retiré.
- Le mécanisme de négociation du numéro de version (permettant à deux machines n'ayant pas le même jeu de versions TLS de se parler) a changé. L'ancien était très bien mais, mal implèmenté, il a suscité beaucoup de problèmes d'interopérabilité. Le nouveau est censé mieux gérer les innombrables systèmes bogués qu'on trouve sur l'Internet (la bogue ne provenant pas tant de la bibliothèque TLS utilisée que des pare-feux mal programmés et mal configurés qui sont souvent mis devant).
La reprise d'une session TLS précédente fait l'objet désormais d'un seul mécanisme, qui est le même que celui pour l'usage de clés pré-partagées. La négociation TLS peut en effet être longue, en terme de latence, et ce mécanisme permet d'éviter de tout recommencer à chaque connexion. Deux machines qui se parlent régulièrement peuvent ainsi gagner du temps.
Un bon résumé de ce nouveau protocole est dans l'article de Mark Nottingham (https://blog.apnic.net/2017/12/12/internet-protocols-changing/).
Section 1.4 : Changements pour TLS 1.2
Ce RFC concerne TLS 1.3 mais il contient aussi quelques changements pour la version 1.2 (section 1.4 du RFC), comme un mécanisme pour limiter les attaques par repli (https://en.wikipedia.org/wiki/Downgrade_attack) portant sur le numéro de version, et des mécanismes de la 1.3 « portés » vers la 1.2 sous forme d'extensions TLS.
-
Section 2 : Survol général de TLS 1.3
La section 2 du RFC est un survol général de TLS 1.3 (le RFC fait 147 pages, et peu de gens le liront intégralement). Au début d'une session TLS, les deux parties, avec le protocole de salutation, négocient les paramètres (version de TLS, algorithmes cryptographiques) et définissent les clés qui seront utilisées pour le chiffrement de la session. En simplifiant, il y a trois phases dans l'établissement d'une session TLS :
- Définition des clés de session, et des paramètres cryptographiques, le client envoie un ClientHello, le serveur répond avec un ServerHello,
- Définition des autres paramètres (par exemple l'application utilisée au-dessus de TLS, ou bien la demande CertificateRequest d'un certificat client), cette partie est chiffrée, contrairement à la précédente,
- Authentification du serveur, avec le message Certificate (qui ne contient pas forcèment un certificat, cela peut être une clé brute - RFC 7250 (http://www.bortzmeyer.org/7250.html) ou une clé d'une session précédente - RFC 7924 (https://www.rfc-editor.org/rfc/rfc7924.txt)).
Un message Finished termine cette ouverture de session. (Si vous êtes fana de futurisme, notez que seule la première étape pourrait être remplacée par la distribution quantique de clés, les autres resteraient indispensables. Contrairement à ce que promettent ses promoteurs, la QKD ne dispense pas d'utiliser les protocoles existants.)
Comment les deux parties se mettent-elles d'accord sur les clés ? Trois méthodes :
- Diffie-Hellman sur courbes elliptiques (https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange) qui sera sans doute la plus fréquente,
- Clé pré-partagée (https://en.wikipedia.org/wiki/Pre-shared_key),
- Clé pré-partagée avec Diffie-Hellman,
- Et la méthode RSA (https://fr.wikipedia.org/wiki/Chiffrement_RSA), elle, disparait de la norme (mais RSA peut toujours être utilisé pour l'authentification, autrement, cela ferait beaucoup de certificats à jeter…)
Si vous connaissez la cryptographie, vous savez que les PSK (https://en.wikipedia.org/wiki/Pre-shared_key), les clés partagées, sont difficiles à gérer, puisque devant être transmises de manière sûre avant l'établissement de la connexion. Mais, dans TLS, une autre possibilité existe : si une session a été ouverte sans PSK, en n'utilisant que de la cryptographie asymétrique, elle peut être enregistrée, et resservir, afin d'ouvrir les futures discussions plus rapidement. TLS 1.3 utilise le même mécanisme pour des « vraies » PSK, et pour celles issues de cette reprise de sessions précédentes (contrairement aux précédentes versions de TLS, qui utilisaient un mécanisme séparé, celui du RFC 5077, désormais abandonné).
Si on a une PSK (gérée manuellement, ou bien via la reprise de session), on peut même avoir un dialogue TLS dit « 0-RTT ». Le premier paquet du client peut contenir des données, qui seront acceptées et traitées par le serveur. Cela permet une importante diminution de la latence, dont il faut rappeler qu'elle est souvent le facteur limitant des performances. Par contre, comme rien n'est idéal dans cette vallée de larmes, cela se fait au détriment de la sécurité :
- Plus de confidentialité persistante (https://fr.wikipedia.org/wiki/Confidentialit%C3%A9_persistante), si la PSK est compromise plus tard, la session pourra être déchiffrée,
- Le rejeu (https://fr.wikipedia.org/wiki/Attaque_par_rejeu) devient possible, et l'application doit donc savoir gérer ce problème.
La section 8 du RFC et l'annexe E.5 détaillent ces limites, et les mesures qui peuvent être prises.
Section 3 : Description informelle de TLS 1.3
Le protocole TLS est décrit avec un langage spécifique, décrit de manière relativement informelle dans la section 3 du RFC. Ce langage manipule des types de données classiques :
- Scalaires (uint8, uint16),
- Tableaux, de taille fixe - Datum[3] ou variable, avec indication de la longueur au début - uint16 longer<0..800>,
- Énumérations (enum { red(3), blue(5), white(7) } Color;),
- Enregistrements structurés, y compris avec variantes (la présence de certains champs dépendant de la valeur d'un champ).
Par exemple, tirés de la section 4 (l'annexe B fournit la liste complète), voici, dans ce langage, la liste des types de messages pendant les salutations, une énumération :
enum {
client_hello(1),
server_hello(2),
new_session_ticket(4),
end_of_early_data(5),
encrypted_extensions(8),
certificate(11),
certificate_request(13),
certificate_verify(15),
finished(20),
key_update(24),
message_hash(254),
(255)
} HandshakeType;
Et le format de base d'un message du protocole de salutation :
struct {
HandshakeType msg_type; /* handshake type */
uint24 length; /* bytes in message */
select (Handshake.msg_type) {
case client_hello: ClientHello;
case server_hello: ServerHello;
case end_of_early_data: EndOfEarlyData;
case encrypted_extensions: EncryptedExtensions;
case certificate_request: CertificateRequest;
case certificate: Certificate;
case certificate_verify: CertificateVerify;
case finished: Finished;
case new_session_ticket: NewSessionTicket;
case key_update: KeyUpdate;
};
} Handshake;
Section 4 : Protocole de salutation de TLS 1.3
La section 4 fournit tous les détails sur le protocole de salutation, notamment sur la délicate négociation des paramètres cryptographiques. Notez que la renégociation en cours de session (http://www.bortzmeyer.org/tls-renego.html) a disparu, donc un ClientHello ne peut désormais plus être envoyé qu'au début.
Un problème auquel a toujours dû faire face TLS est celui de la négociation de version, en présence de mises en œuvre boguées, et, surtout, en présence de boitiers intermédiaires (https://en.wikipedia.org/wiki/Middlebox) encore plus bogués (pare-feux ignorants, par exemple, que des DSI ignorantes placent un peu partout). Le modèle original de TLS pour un client était d'annoncer dans le ClientHello le plus grand numéro de version qu'on gère, et de voir dans ServerHello le maximum imposé par le serveur. Ainsi, un client TLS 1.2 parlant à un serveur qui ne gère que 1.1 envoyait ClientHello(client_version=1.2) et, en recevant ServerHello(server_version=1.1), se repliait sur TLS 1.1, la version la plus élevée que les deux parties gèraient. En pratique, cela ne marche pas aussi bien. On voyait par exemple des serveurs (ou, plus vraisemblablement, des pare-feux bogués) qui raccrochaient brutalement en présence d'un numéro de version plus élevé, au lieu de suggérer un repli. Le client n'avait alors que le choix de renoncer, ou bien de se lancer dans une série d'essais/erreurs (qui peut être longue, si le serveur ou le pare-feu bogué ne répond pas).
TLS 1.3 change donc complètement le mécanisme de négociation. Le client annonce toujours la version 1.2 (en fait 0x303, pour des raisons historiques), et la vraie version est mise dans une extension, supported_versions (section 4.2.1), dont on espère qu'elle sera ignorée par les serveurs mal gérés. (L'annexe D du RFC détaille ce problème de la négociation de version.) Dans la réponse ServerHello, un serveur 1.3 doit inclure cette extension, autrement, il faut se rabattre sur TLS 1.2.
En parlant d'extensions, concept qui avait été introduit originellement dans le RFC 4366 (http://www.bortzmeyer.org/4366.html), notre RFC reprend des extensions déjà normalisées, comme le SNI (Server Name Indication) du RFC 6066 (http://www.bortzmeyer.org/6066.html), le battement de cœur du RFC 6520 (http://www.bortzmeyer.org/6520.html), le remplissage du ClientHello du RFC 7685 (https://www.rfc-editor.org/rfc/rfc7685.txt), et en ajoute dix, dont supported_versions. Certaines de ces extensions doivent être présentes dans les messages Hello, car la sélection des paramètres cryptographiques en dépend, d'autres peuvent être uniquement dans les messages EncryptedExtensions, une nouveauté de TLS 1.3, pour les extensions qu'on n'enverra qu'une fois le chiffrement commencé. Le RFC en profite pour rappeler que les messages Hello ne sont pas protégés cryptographiquement, et peuvent donc être modifiés (le message Finished résume les décisions prises et peut donc protéger contre ce genre d'attaques).
Autrement, parmi les autres nouvelles extensions :
- Le petit gâteau (cookie), pour tester la joignabilité,
- Les données précoces (early data), extension qui permet d'envoyer des données dès le premier message (« O-RTT »), réduisant ainsi la latence, un peu comme le fait le TCP Fast Open du RFC 7413 (http://www.bortzmeyer.org/7413.html),
- Liste des AC (certificate authorities), qui, en indiquant la liste des AC connues du client, peut aider le serveur à choisir un certificat qui sera validé (par exemple en n'envoyant le certificat CAcert que si le client connait cette AC).
-
Section 5 : Décrit le protocole des enregistrements de TLS 1.3
La section 5 décrit le protocole des enregistrements (record protocol). C'est ce sous-protocole qui va prendre un flux d'octets, le découper en enregistrements, les protéger par le chiffrement puis, à l'autre bout, déchiffrer et reconstituer le flux… Notez que « protégé » signifie à la fois confidentialité et intégrité puisque TLS 1.3, contrairement à ses prédécesseurs, impose AEAD (https://en.wikipedia.org/wiki/Authenticated_encryption) (RFC 5116 (https://www.rfc-editor.org/rfc/rfc5116.txt)).
Les enregistrements sont typés et marqués handshake (la salutation, vue dans la section précédente), change cipher spec, alert (pour signaler un problème) et application data (les données elle-mêmes) :
enum {
invalid(0),
change_cipher_spec(20),
alert(21),
handshake(22),
application_data(23),
(255)
} ContentType;
Le contenu des données est évidemment incompréhensible, en raison du chiffrement (voici un enregistrement de type 23, données, vu par tshark) :
TLSv1.3 Record Layer: Application Data Protocol: http-over-tls
Opaque Type: Application Data (23)
Version: TLS 1.2 (0x0303)
Length: 6316
Encrypted Application Data: eb0e21f124f82eee0b7a37a1d6d866b075d0476e6f00cae7...
Et décrite par la norme dans son langage formel :
struct {
ContentType opaque_type = application_data; /* 23 */
ProtocolVersion legacy_record_version = 0x0303; /* TLS v1.2 */
uint16 length;
opaque encrypted_record[TLSCiphertext.length];
} TLSCiphertext;
(Oui, le numéro de version reste à TLS 1.2 pour éviter d'énerver les stupides middleboxes.) Notez que des extensions à TLS peuvent introduire d'autres types d'enregistrements.
Une faiblesse classique de TLS est que la taille des données chiffrées n'est pas dissimulée. Si on veut savoir à quelle page d'un site Web un client HTTP a accédé, on peut parfois le déduire de l'observation de cette taille (https://ieeexplore.ieee.org/document/6234422/?reload=true&arnumber=6234422). D'où la possibilité de faire du remplissage (https://fr.wikipedia.org/wiki/Remplissage_(cryptographie)) pour dissimuler cette taille (section 5.4 du RFC). Notez que le RFC ne suggère pas de politique de remplissage spécifique (ajouter un nombre aléatoire ? Tout remplir jusqu'à la taille maximale ?), c'est un choix compliqué. Il note aussi que certaines applications font leur propre remplissage, et qu'il n'est alors pas nécessaire que TLS le fasse.
Section 6 : Cas des alertes dans TLS 1.3
La section 6 du RFC est dédiée au cas des alertes. C'est un des types d'enregistrements possibles, et, comme les autres, il est chiffré, et les alertes sont donc confidentielles.
Une alerte a un niveau et une description :
struct {
AlertLevel level;
AlertDescription description;
} Alert;
Le niveau indiquait si l'alerte est fatale mais n'est plus utilisé en TLS 1.2, où il faut se fier uniquement à la description, une énumération des problèmes possibles (message de type inconnu, mauvais certificat, enregistrement non décodable - rappelez-vous que TLS 1.3 n'utilise que du chiffrement intègre, problème interne au client ou au serveur, extension non acceptée, etc).
La section 6.2 donne une liste des erreurs fatales, qui doivent mener à terminer immédiatement la session TLS.
Section 8 : 0-RTT
La section 8 du RFC est entièrement consacrée à une nouveauté délicate, le « 0-RTT (https://fr.wikipedia.org/wiki/Round-trip_delay_time) ». Ce terme désigne la possibilité d'envoyer des données dès le premier paquet, sans les nombreux échanges de paquets qui sont normalement nécessaires pour établir une session TLS. C'est très bien du point de vue des performances, mais pas forcèment du point de vue de la sécurité puisque, sans échanges, on ne peut plus vérifier à qui on parle. Un attaquant peut réaliser une attaque par rejeu en envoyant à nouveau un paquet qu'il a intercepté. Un serveur doit donc se défendre en se souvenant des données déjà envoyées et en ne les acceptant pas deux fois. (Ce qui peut être plus facile à dire qu'à faire ; le RFC contient une bonne discussion très détaillée des techniques possibles, et de leurs limites. Il y en a des subtiles, comme d'utiliser des systèmes de mémorisation ayant des faux positifs, comme les filtres de Bloom (https://fr.wikipedia.org/wiki/Filtre_de_Bloom), parce qu'ils ne produiraient pas d'erreurs, ils rejetteraient juste certains essais 0-RTT légitimes, cela ne serait donc qu'une légère perte de performance.)
Section 9 : Conformité des mises en œuvres de TLS 1.3 et comportement attendu des équipements intermédiaires
La section 9 de notre RFC se penche sur un problème difficile, la conformité des mises en œuvres de TLS. D'abord, les algorithmes obligatoires. Afin de permettre l'interopérabilité, toute mise en œuvre de TLS doit avoir la suite de chiffrement TLS_AES_128_GCM_SHA256 (AES (https://fr.wikipedia.org/wiki/Advanced_Encryption_Standard) en mode GCM (https://fr.wikipedia.org/wiki/Galois/Counter_Mode) avec SHA-256 (https://fr.wikipedia.org/wiki/SHA-2#SHA-256)). D'autres suites sont recommandées (cf. annexe B.4). Pour l'authentification, RSA (https://fr.wikipedia.org/wiki/Chiffrement_RSA) avec SHA-256 et ECDSA (https://fr.wikipedia.org/wiki/Elliptic_curve_digital_signature_algorithm) sont obligatoires. Ainsi, deux programmes différents sont sûrs de pouvoir trouver des algorithmes communs. La possibilité d'authentification par certificats PGP (https://fr.wikipedia.org/wiki/Pretty_Good_Privacy) du RFC 6091 (http://www.bortzmeyer.org/6091.html) a été retirée.
De plus, certaines extensions à TLS sont obligatoires, un pair TLS 1.3 ne peut pas les refuser :
- supported_versions, nécessaire pour annoncer TLS 1.3,
- cookie,
- signature_algorithms, signature_algorithms_cert, supported_groups et key_share,
- server_name, c'est à dire SNI (Server Name Indication), souvent nécessaire pour pouvoir choisir le bon certificat (cf. section 3 du RFC 6066 (http://www.bortzmeyer.org/6066.html)).
La section 9 précise aussi le comportement attendu des équipements intermédiaires (https://en.wikipedia.org/wiki/Middlebox). Ces dispositifs (pare-feux, par exemple, mais pas uniquement) ont toujours été une plaie pour TLS. Alors que TLS vise à fournir une communication sûre, à l'abri des équipements intermédiaires, ceux-ci passent leur temps à essayer de s'insérer dans la communication, et souvent la cassent. Normalement, TLS 1.3 est conçu pour que ces interférences ne puissent pas mener à un repli (le repli est l'utilisation de paramètres moins sûrs que ce que les deux machines auraient choisi en l'absence d'interférence).
Il y a deux grandes catégories d'intermédiaires, ceux qui tripotent la session TLS sans être le client ou le serveur, et ceux qui terminent la session TLS de leur côté. Attention, dans ce contexte, « terminer » ne veut pas dire « y mettre fin », mais « la sécurité TLS se termine ici, de manière à ce que l'intermédiaire puisse accéder au contenu de la communication ». Typiquement, une middlebox qui « termine » une session TLS va être serveur TLS pour le client et client TLS pour le serveur, s'insérant complètement dans la conversation. Normalement, l'authentification vise à empêcher ce genre de pratiques, et l'intermédiaire ne sera donc accepté que s'il a un certificat valable. C'est pour cela qu'en entreprise, les machines officielles sont souvent installées avec une AC contrôlée par le vendeur du boitier intermédiaire, de manière à permettre l'interception.
Le RFC ne se penche pas sur la légitimité de ces pratiques, uniquement sur leurs caractéristiques techniques. (Les boitiers intermédiaires sont souvent programmés avec les pieds (http://www.bortzmeyer.org/killed-by-proxy.html), et ouvrent de nombreuses failles (http://www.bortzmeyer.org/https-interception.html).) Le RFC rappelle notamment que l'intermédiaire qui termine une session doit suivre le RFC à la lettre (ce qui devrait aller sans dire…)
Section 11 : Registres IANA pour TLS 1.3
Depuis le RFC 4346 (https://www.rfc-editor.org/rfc/rfc4346.txt), il existe plusieurs registres IANA (https://fr.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority) pour TLS, décrits en section 11, avec leurs nouveautés. En effet, plusieurs choix pour TLS ne sont pas « câblés en dur » dans le RFC mais peuvent évoluer indépendamment. Par exemple, le registre de suites cryptographiques (https://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4) a une politique d'enregistrement « spécification nécessaire » (cf. RFC 8126 (http://www.bortzmeyer.org/8126.html), sur les politiques d'enregistrement). La cryptographie fait régulièrement des progrès, et il faut donc pouvoir modifier la liste des suites acceptées (par exemple lorsqu'il faudra y ajouter les algorithmes post-quantiques (http://www.bortzmeyer.org/pas-sage-en-seine-quantique.html)) sans avoir à toucher au RFC (l'annexe B.4 donne la liste actuelle). Le registre des types de contenu (https://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-5), lui, a une politique d'enregistrement bien plus stricte, « action de normalisation ». On crée moins souvent des types que des suites cryptographiques. Même chose pour le registre des alertes (https://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-6) ou pour celui des salutations (https://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-7).
-
Annexe C : Conseils pour une mise en œuvre correcte de TLS 1.3
L'annexe C du RFC plaira aux programmeurs, elle donne plusieurs conseils pour une mise en œuvre correcte de TLS 1.3 (ce n'est pas tout d'avoir un protocole correct, il faut encore qu'il soit programmé correctement). Pour aider les développeurs à déterminer s'ils ont correctement fait le travail, un futur RFC fournira des vecteurs de test.
Un des conseils les plus importants est évidemment de faire attention au générateur de nombres aléatoires (https://fr.wikipedia.org/wiki/G%C3%A9n%C3%A9rateur_de_nombres_al%C3%A9atoires), source de tant de failles de sécurité en cryptographie. TLS utilise des nombres qui doivent être imprévisibles à un attaquant pour générer des clés de session. Si ces nombres sont prévisibles, toute la cryptographie s'effondre. Le RFC conseille fortement d'utiliser un générateur existant (comme /dev/urandom sur les systèmes Unix) plutôt que d'écrire le sien, ce qui est bien plus difficile qu'il ne semble. (Si on tient quand même à le faire, le RFC 4086 (http://www.bortzmeyer.org/4086.html) est une lecture indispensable.)
Le RFC conseille également de vérifier le certificat du partenaire par défaut (quitte à fournir un moyen de débrayer cette vérification). Si ce n'est pas le cas, beaucoup d'utilisateurs du programme ou de la bibliothèque oublieront de le faire. Il suggère aussi de ne pas accepter certains certificats trop faibles (clé RSA de seulement 1 024 bits, par exemple).
Il existe plusieurs moyens avec TLS de ne pas avoir d'authentification du serveur : les clés brutes du RFC 7250 (http://www.bortzmeyer.org/7250.html) (à la place des certificats), ou bien les certificats auto-signés. Dans ces conditions, une attaque de l'homme du milieu (https://fr.wikipedia.org/wiki/Attaque_de_l%27homme_du_milieu) est parfaitement possibe, et il faut donc prendre des précautions supplèmentaires (par exemple DANE (https://fr.wikipedia.org/wiki/DNS_-_based_Authentication_of_Named_Entities), normalisé dans le [ur=http://www.bortzmeyer.org/6698.htmll]RFC 6698[/url], que le RFC oublie malheureusement de citer).
Autre bon conseil de cryptographie, se méfier des attaques fondées sur la mesure du temps de calcul (https://fr.wikipedia.org/wiki/Attaque_temporelle), et prendre des mesures appropriées (par exemple en vérifiant que le temps de calcul est le même pour des données correctes et incorrectes).
Il n'y a aucune bonne raison d'utiliser certains algorithmes faibles (comme RC4, abandonné depuis le RFC 7465), et le RFC demande que le code pour ces algorithmes ne soit pas présent, afin d'éviter une attaque par repli (annexes C.3 et D.5 du RFC). De la même façon, il demande de ne jamais accepter SSL v3 (RFC 7568 (http://www.bortzmeyer.org/7568.html)).
L'expérience a prouvé que beaucoup de mises en œuvre de TLS ne réagissaient pas correctement à des options inattendues, et le RFC rappelle donc qu'il faut ignorer les suites cryptographiques inconnues (autrement, on ne pourrait jamais introduire une nouvelle suite, puisqu'elle casserait les programmes), et ignorer les extensions inconnues (pour la même raison).[/size]
Annexe D : Problème de communication avec un partenaire qui ne connait pas TLS 1.3
L'annexe D, elle, est consacrée au problème de la communication avec un vieux partenaire, qui ne connait pas TLS 1.3. Le mécanisme de négociation de la version du protocole à utiliser a complètement changé en 1.3. Dans la 1.3, le champ version du ClientHello contient 1.2, la vraie version étant dans l'extension supported_versions. Si un client 1.3 parle avec un serveur <= 1.2, le serveur ne connaitra pas cette extension et répondra sans l'extension, avertissant ainsi le client qu'il faudra parler en 1.2 (ou plus vieux). Ça, c'est si le serveur est correct. S'il ne l'est pas ou, plus vraisemblablement, s'il est derrière une middlebox boguée, on verra des problèmes comme par exemple le refus de répondre aux clients utilisant des extensions inconnues (ce qui sera le cas pour supported_versions), soit en rejettant ouvertement la demande soit, encore pire, en l'ignorant. Arriver à gérer des serveurs/middleboxes incorrects est un problème complexe. Le client peut être tenté de re-essayer avec d'autres options (par exemple tenter du 1.2, sans l'extension supported_versions). Cette méthode n'est pas conseillée. Non seulement elle peut prendre du temps (attendre l'expiration du délai de garde, re-essayer…) mais surtout, elle ouvre la voie à des attaques par repli : l'attaquant bloque les ClientHello 1.3 et le client, croyant bien faire, se replie sur une version plus ancienne et sans doute moins sûre de TLS.
En parlant de compatibilité, le « 0-RTT » n'est évidemment pas compatible avec les vieilles versions. Le client qui envoie du « 0-RTT » (des données dans le ClientHello) doit donc savoir que, si la réponse est d'un serveur <= 1.2, la session ne pourra pas être établie, et il faudra donc réessayer sans 0-RTT.
Naturellement, les plus gros problèmes ne surviennent pas avec les clients et les serveurs mais avec les middleboxes. Plusieurs études ont montré leur caractère néfaste (cf. présentation à l'IETF 100 (https://datatracker.ietf.org/meeting/100/materials/slides-100-tls-sessa-tls13/), mesures avec Chrome (https://www.ietf.org/mail-archive/web/tls/current/msg25168.html) (qui indique également que certains serveurs TLS sont gravement en tort, comme celui installé dans les imprimantes Canon), mesures avec Firefox (https://www.ietf.org/mail-archive/web/tls/current/msg25091.html), et encore d'autres mesures (https://www.ietf.org/mail-archive/web/tls/current/msg25179.html)). Le RFC suggère qu'on limite les risques en essayant d'imiter le plus possible une salutation de TLS 1.2, par exemple en envoyant des messages change_cipher_spec, qui ne sont plus utilisés en TLS 1.3, mais qui peuvent rassurer la middlebox (annexe D.4).
Annexe E : propriétés de sécurité de TLS 1.3
Enfin, le RFC se termine par l'annexe E, qui énumère les propriétés de sécurité de TLS 1.3 : même face à un attaquant actif (RFC 3552 (http://www.bortzmeyer.org/3552.html)), le protocole de salutation de TLS garantit des clés de session communes et secrètes, une authentification du serveur (et du client si on veut), et une sécurité persistante, même en cas de compromission ultérieure des clés (sauf en cas de 0-RTT, un autre des inconvénients sérieux de ce service, avec le risque de rejeu). De nombreuses analyses détaillées de la sécurité de TLS sont listées dans l'annexe E.1.6. À lire si vous voulez travailler ce sujet.
Quant au protocole des enregistrements, celui de TLS 1.3 garantit confidentialité et intégrité (RFC 5116 (https://www.rfc-editor.org/rfc/rfc5116.txt)).
TLS 1.3 a fait l'objet de nombreuses analyses de sécurité par des chercheurs, avant même sa normalisation, ce qui est une bonne chose (et qui explique en partie les retards). Notre annexe E pointe également les limites restantes de TLS :
- Il est vulnérable à l'analyse de trafic (https://fr.wikipedia.org/wiki/Attaque_par_analyse_du_trafic). TLS n'essaie pas de cacher la taille des paquets, ni l'intervalle de temps entre eux. Ainsi, si un client accède en HTTPS à un site Web servant quelques dizaines de pages aux tailles bien différentes, il est facile de savoir quelle page a été demandée, juste en observant les tailles. (Voir « I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis (https://arxiv.org/abs/1403.0297) », de Miller, B., Huang, L., Joseph, A., et J. Tygar et « HTTPS traffic analysis and client identification using passive SSL/TLS fingerprinting (https://is.muni.cz/repo/1299983/https_client_identification-paper.pdf) », de Husak, M., Čermak, M., Jirsik, T., et P. Čeleda). TLS fournit un mécanisme de remplissage avec des données bidon, permettant aux applications de brouiller les pistes. Certaines applications utilisant TLS ont également leur propre remplissage (par exemple, pour le DNS, c'est le RFC 7858 (http://www.bortzmeyer.org/7858.html)). De même, une mise en œuvre de TLS peut retarder les paquets pour rendre l'analyse des intervalles plus difficile. On voit que dans les deux cas, taille des paquets et intervalle entre eux, résoudre le problème fait perdre en performance (c'est pour cela que ce n'est pas intégré par défaut).
- TLS peut être également vulnérable à des attaques par canal auxiliaire. Par exemple, la durée des opérations cryptographiques peut être observée, ce qui peut donner des informations sur les clés. TLS fournit quand même quelques défenses : l'AEAD (https://en.wikipedia.org/wiki/Authenticated_encryption) facilite la mise en œuvre de calculs en temps constant, et format uniforme pour toutes les erreurs, empêchant un attaquant de trouver quelle erreur a été déclenchée.
Le 0-RTT introduit un nouveau risque, celui de rejeu (https://fr.wikipedia.org/wiki/Attaque_par_rejeu). (Et 0-RTT a sérieusement contribué aux délais qu'à connu le projet TLS 1.3, plusieurs participants à l'IETF protestant contre cette introduction risquée (http://bristolcrypto.blogspot.com/2017/03/pkc-2017-kenny-paterson-accepting-bets.html).) Si l'application est idempotente (https://fr.wikipedia.org/wiki/Idempotence), ce n'est pas très grave. Si, par contre, les effets d'une requête précédentes peuvent être rejoués, c'est plus embêtant (imaginez un transfert d'argent répété…) TLS ne promet rien en ce domaine, c'est à chaque serveur de se défendre contre le rejeu (la section 8 donne des idées à ce sujet). Voilà pourquoi le RFC demande que les requêtes 0-RTT ne soient pas activées par défaut, mais uniquement quand l'application au-dessus de TLS le demande. (Cloudflare, par exemple, n'active pas le 0-RTT par défaut.)
Voilà, vous avez maintenant fait un tour complet du RFC, mais vous savez que la cryptographie est une chose difficile, et pas seulement dans les algorithmes cryptographiques (TLS n'en invente aucun, il réutilise des algorithmes existants comme AES ou ECDSA), mais aussi dans les protocoles cryptographiques, un art complexe. N'hésitez donc pas à lire le RFC en détail, et à vous méfier des résumés forcèment toujours sommaires, comme cet article.
-
Débats lors de la création de TLS 1.3, entre partisans et opposant à la surveillance du contenu des communications TLS 1.3
Au final, l'IETF est restée ferme et n'a pas accepté de compromissions sur la sécurité de TLS.
À part le 0-RTT, le plus gros débat lors de la création de TLS 1.3 avait été autour du concept que ses partisans nomment « visibilité » et ses adversaires « surveillance ». C'est l'idée qu'il serait bien pratique si on (on : le patron, la police, le FAI…) pouvait accéder au contenu des communications TLS. « Le chiffrement, c'est bien, à condition que je puisse lire les données quand même » est l'avis des partisans de la visibilité. Cela avait été proposé dans les Internet-Drafts draft-green-tls-static-dh-in-tls13 (https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/) et draft-rhrd-tls-tls13-visibility (https://datatracker.ietf.org/doc/draft-rhrd-tls-tls13-visibility/). Je ne vais pas ici pouvoir capturer la totalité du débat, juste noter quelques points qui sont parfois oubliés dans la discussion.
Côté partisans de la visibilité :
- Dans une entreprise capitaliste, il n'y pas de citoyens, juste un patron et des employés. Les ordinateurs appartiennent au patron, et les employés n'ont pas leur mot à dire. Le patron peut donc décider d'accéder au contenu des communications chiffrées.
- Il existe des règles (par exemple PCI-DSS (https://fr.wikipedia.org/wiki/Norme_de_s%C3%A9curit%C3%A9_de_l%E2%80%99industrie_des_cartes_de_paiement) dans le secteur financier ou HIPAA (https://fr.wikipedia.org/wiki/Health_Insurance_Portability_and_Accountability_Act) dans celui de la santé) qui requièrent de certaines entreprises qu'elles sachent en détail tout ce qui circule sur le réseau. Le moyen le plus simple de le faire est de surveiller le contenu des communications, même chiffrées. (Je ne dis pas que ces règles sont intelligentes, juste qu'elles existent. Notons par exemple que les mêmes règles imposent d'utiliser du chiffrement fort, sans faille connue, ce qui est contradictoire.)
- Enregistrer le trafic depuis les terminaux est compliqué en pratique : applications qui n'ont pas de mécanisme de journalisation du trafic, systèmes d'exploitation fermés, boîtes noires…
- TLS 1.3 risque de ne pas être déployé dans les entreprises qui tiennent à surveiller le trafic, et pourrait même être interdit dans certains pays, où la surveillance passe avant les droits humains.
Et du côté des adversaires de la surveillance :
- La cryptographie, c'est compliqué et risqué. TLS 1.3 est déjà assez compliqué comme cela. Lui ajouter des fonctions (surtout des fonctions délibérèment conçues pour affaiblir ses propriétés de sécurité) risque fort d'ajouter des failles de sécurité. D'autant plus que TLS 1.3 a fait l'objet de nombreuses analyses de sécurité avant son déploiement, et qu'il faudrait tout recommencer.
- Contrairement à ce que semblent croire les partisans de la « visibilité », il n'y a pas que HTTPS qui utilise TLS. Ils ne décrivent jamais comment leur proposition marcherait avec des protocoles autres que HTTPS.
- Pour HTTPS, et pour certains autres protocoles, une solution simple, si on tient absolument à intercepter tout le trafic, est d'avoir un relais (https://fr.wikipedia.org/wiki/Proxy) explicite, configuré dans les applications, et combiné avec un blocage dans le pare-feu des connexions TLS directes. Les partisans de la visibilté ne sont en général pas enthousiastes pour cette solution car ils voudraient faire de la surveillance furtive, sans qu'elle se voit dans les applications utilisées par les employés ou les citoyens.
- Les partisans de la « visibilité » disent en général que l'interception TLS serait uniquement à l'intérieur de l'entreprise, pas pour l'Internet public. Mais, dans ce cas, tous les terminaux sont propriété de l'entreprise et contrôlés par elle, donc elle peut les configurer pour copier tous les messages échangés. Et, si certains de ces terminaux sont des boîtes noires, non configurables et dont on ne sait pas bien ce qu'ils font, eh bien, dans ce cas, on se demande pourquoi des gens qui insistent sur leurs obligations de surveillance mettent sur leur réseau des machines aussi incontrôlables.
- Dans ce dernier cas (surveillance uniquement au sein d'une entreprise), le problème est interne à l'entreprise, et ce n'est donc pas à l'IETF, organisme qui fait des normes pour l'Internet, de le résoudre. Après tout, rien n'empêche ces entreprises de garder TLS 1.2.
Mises en œuvre de TLS 1.3 avec GnuTLS
Revenons maintenant aux choses sérieuses, avec les mises en œuvre de TLS 1.3. Il y en existe au moins une dizaine à l'heure actuelle mais, en général, pas dans les versions officiellement publiées des logiciels. Notons quand même que Firefox 61 sait faire du TLS 1.3. Les autres mises en œuvre sont prêtes, même si pas forcèment publiées. Prenons l'exemple de la bibliothèque GnuTLS (https://fr.wikipedia.org/wiki/GnuTLS). Elle dispose de TLS 1.3 depuis la version 3.6.3. Pour l'instant, il faut compiler cette version avec l'option ./configure --enable-tls13-support, qui n'est pas encore activée par défaut. Un bon article du mainteneur de GnuTLS (https://nikmav.blogspot.com/2018/05/gnutls-and-tls-13.html) explique bien les nouveautés de TLS 1.3.
Une fois GnuTLS correctement compilé, on peut utiliser le programme en ligne de commande gnutls-cli avec un serveur qui accepte TLS 1.3 :
% gnutls-cli gmail.com
...
- Description: (TLS1.3)-(ECDHE-X25519)-(RSA-PSS-RSAE-SHA256)-(AES-256-GCM)
- Ephemeral EC Diffie-Hellman parameters
- Using curve: X25519
- Curve size: 256 bits
- Version: TLS1.3
- Key Exchange: ECDHE-RSA
- Server Signature: RSA-PSS-RSAE-SHA256
- Cipher: AES-256-GCM
- MAC: AEAD
...
Et ça marche, on fait du TLS 1.3. Si vous préférez écrire le programme vous-même, regardez ce petit programme (http://www.bortzmeyer.org/files/test-tls13.c). Si GnuTLS est en /local, il se compilera avec cc -I/local/include -Wall -Wextra -o test-tls13 test-tls13.c -L/local/lib -lgnutls et s'utilisera avec :
% ./test-tls13 www.ietf.org
TLS connection using "TLS1.3 AES-256-GCM"
% ./test-tls13 gmail.com
TLS connection using "TLS1.3 AES-256-GCM"
% ./test-tls13 mastodon.gougere.fr
TLS connection using "TLS1.2 AES-256-GCM"
% ./test-tls13 www.bortzmeyer.org
TLS connection using "TLS1.2 AES-256-GCM"
% ./test-tls13 blog.cloudflare.com
TLS connection using "TLS1.3 AES-256-GCM"
Cela vous donne une petite idée des serveurs qui acceptent TLS 1.3.
Un pcap d'une session TLS 1.3 est disponible en tls13.pcap (http://www.bortzmeyer.org/files/tls13.pcap). Notez que le numéro de version n'est pas encore celui du RFC (0x304). Ici, 0x7f1c désigne l'Internet-Draft numéro 28. Voici la session vue par tshark :
1 0.000000 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 94 36866 → https(443) [SYN] Seq=0 Win=28800 Len=0 MSS=1440 SACK_PERM=1 TSval=3528788861 TSecr=0 WS=128
2 0.003052 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 86 https(443) → 36866 [SYN, ACK] Seq=0 Ack=1 Win=24400 Len=0 MSS=1220 SACK_PERM=1 WS=1024
3 0.003070 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [ACK] Seq=1 Ack=1 Win=28800 Len=0
4 0.003354 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TLSv1 403 Client Hello
5 0.006777 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 74 https(443) → 36866 [ACK] Seq=1 Ack=330 Win=25600 Len=0
6 0.011393 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TLSv1.3 6496 Server Hello, Change Cipher Spec, Application Data
7 0.011413 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [ACK] Seq=330 Ack=6423 Win=41728 Len=0
8 0.011650 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TLSv1.3 80 Change Cipher Spec
9 0.012685 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TLSv1.3 148 Application Data
10 0.015693 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 74 https(443) → 36866 [ACK] Seq=6423 Ack=411 Win=25600 Len=0
11 0.015742 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TLSv1.3 524 Application Data
12 0.015770 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [RST] Seq=411 Win=0 Len=0
13 0.015788 2400:cb00:2048:1::6814:55 → 2001:67c:370:1998:9819:4f92:d0c0:e94d TCP 74 https(443) → 36866 [FIN, ACK] Seq=6873 Ack=411 Win=25600 Len=0
14 0.015793 2001:67c:370:1998:9819:4f92:d0c0:e94d → 2400:cb00:2048:1::6814:55 TCP 74 36866 → https(443) [RST] Seq=411 Win=0 Len=0
Et, complètement décodée par tshark :
Secure Sockets Layer [sic]
TLSv1 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Version: TLS 1.2 (0x0303)
...
Extension: supported_versions (len=9)
Type: supported_versions (43)
Length: 9
Supported Versions length: 8
Supported Version: Unknown (0x7f1c)
Supported Version: TLS 1.2 (0x0303)
Supported Version: TLS 1.1 (0x0302)
Supported Version: TLS 1.0 (0x0301)Le texte complet est en tls13.txt (http://www.bortzmeyer.org/files/tls13.txt). Notez bien que la négociation est en clair.
Quelques autres articles à lire :
- L'annonce officielle de l'IETF (https://www.ietf.org/blog/tls13/),
- Le bon résumé de Cloudflare (https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/) sur la version 1.3,
- Discussion Ycombinator sur la visibilité (https://news.ycombinator.com/item?id=16564935),
- Liste complète des réponses aux partisans de la visibilité (https://github.com/sftcd/tinfoil),
- Bon article historique très détaillé sur l'histoire de TLS (https://tlseminar.github.io/tls-13/), jusqu'à la version 1.3,
- Un exemple d'un des ateliers où a été étudié la sécurité de TLS 1.3 (https://www.mitls.org/tls:div/), à Paris en 2017, et un autre (https://www.ietfjournal.org/tron-workshop-connects-ietf-tls-engineers-and-security-researchers/) à San Diego en 2016,
- Bon article sur la question des middleboxes (https://blog.cloudflare.com/why-tls-1-3-isnt-in-browsers-yet/), expliquant notamment les extensions « inutiles », mais permettant de tromper ces middleboxes pour ressembler à TLS 1.2.
Source : Blog de Stéphane Bortzmeyer (https://www.bortzmeyer.org/8446.html)
-
OpenSSL 1.1.1 est sorti le 11 septembre 2018 et apporte le support de TLS 1.3.
OpenSSL sera disponible avec Ubuntu 19.04 qui sortira en avril 2019.
Fedora 29, prévue pour début novembre, prendra en charge TLS 1.3 via GnuTLS, une libraire alternative à OpenSSL qui a mis en place le support de TLS 1.3 avec quelques mois d'avance sur OpenSSL.
Chrome 70 apportera le support de TLS 1.3 (RFC 8446) activé par défaut.
Pour Firefox, c'est activé par défaut depuis Firefox 61 :
Firefox 61 est la première version de Firefox vec le support de TLS1.3 activé par défaut
=> https://www.mozilla.org/en-US/firefox/61.0/releasenotes/
(https://lafibre.info/images/ssl/201806_firefox_61_tls13.png)
-
TLS v1.3 sera vraisemblablement proposé à la rentrée 2020 (1er octobre 2020 ?) en plus de TLS v1.2. Cela pourrait être avancé, si TLS v1.3 venait a être inclut dans Ubuntu 18.04 LTS, comme une mise à jour de sécurité. La configuration d'Apache permettant l'activation de TLS v1.3 dés qu'il est disponible, cela se ferait alors automatiquement, lors de le mise à jour d'OpenSSL.
Apparemment, OpenSSL 1.1.1 va être rétroporté (https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-18.04-OpenSSL-1.1.1-TLS) et Apache et OpenSSH mis à jour pour un support de TLSv1.3 dans les semaines suivantes.
-
Et nginx ? ::)
-
C'est une bonne nouvelle.
Je suis curieux de voir comment ces mises à jour sont proposés, car il me semble impossible de les pousser à tous comme une mise à jour de sécurité, il y a des choses qui ne peuvent plus marcher avec des versions plus récentes.
Par exemple la connexion a des vieux réseaux WiFi WPA2 Enterprise Protected EAP pose problème avec Open SSL 1.1.0 :
We suspected OpenSSL incompatibility in the OS, so as the PEAP is creating underlying TLS tunnel for auth and we see an error in wpa_supplicant regarding TLS negotiation (hello).
[...]
We think the issue directly relates to remove 3DES from Bionic:
openssl ciphers -V '3DES'
Error in cipher list
139999040823744:error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match:../ssl/ssl_lib.c:2129:
Source : Launchpad bug #1748839 (https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1748839)
J'imagine que la moise à jour pourrait être poussée avec les LTS Enablement Stacks qui permettent d'avoir un kernel et un serveur X plus récent sur une LTS.
( cf LTS Enablement Stacks (https://wiki.ubuntu.com/Kernel/LTSEnablementStack) )
-
Et nginx ? ::)
A priori (https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386/comments/6)pas besoin de mise à jour supplèmentaire dans ce cas-là.
J'imagine que la moise à jour pourrait être poussée avec les LTS Enablement Stacks qui permettent d'avoir un kernel et un serveur X plus récent sur une LTS.
( cf LTS Enablement Stacks (https://wiki.ubuntu.com/Kernel/LTSEnablementStack) )
Probablement pas, dans le message initial (https://lists.ubuntu.com/archives/ubuntu-devel/2018-December/040567.html) il est rappelé qu'au contraire de la version 1.1.1, la 1.1.0 n'est pas une version LTS au niveau de l'équipe OpenSSL, et que les API / ABI ne changent pas. Par ailleurs aucun problème significatif n'a été relevé pour l'instant ni sur le PPA de test ni sur Ubuntu 18.10 (ce qui ne veut pas dire pas de bug du tout, cf le lien du dessus pour ngix)
-
Effectivement, OpenSSL 1.1.1 sera proposé en remplacement d'OpenSSL 1.1.0 dans quelques mois.
Cf https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386
Attention, La version d'Apache livré avec Ubuntu 18.04 ou Ubuntu 18.10 n'est pas compatible TLS 1.3
Il y aura donc ultérieurement une mise à jour d'Apache, porbablement dans la version qui sera livrée avec Ubuntu 19.04... (ce sont des suppositions de ma part)
-
J'ai récemment changé mon serveur dédié et en ai profité pour y installer Debian 10 Buster (actuelle testing) ; j'ai openssl1.1.1, apache2.4.37, et du coup TLS1.3 actif. J'ai fêté ça en retirant TLSv1 et TLSv1.1
SSL Pulse (https://www.ssllabs.com/ssl-pulse/) de Qualys permet de suivre l'utilisation de ces protocoles côté serveurs.
-
Du côté de F5 (célèbre fabricant de load-balancers) le support de TLS1.3 n'est pas encore complet :
https://support.f5.com/csp/article/K10251520
F5 ne conseille pas de l'utiliser en production pour le moment.
-
Mettre à jour OpenSSL sans toucher au reste ne semble pas aussi simple.
Le mail envoyé ce soir par Dimitri John Ledkov qui travail pour mettre OpenSSL 1.1.1 sur Ubuntu 18.04 LTS :
There are many moving parts involved to safely land the OpenSSL 1.1.1
update in Bionic.
SRU bug report https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1797386
Landing OpenSSL and related updates (pythons, ruby, r-cran, etc) will
trigger many autopkgtests and may regress package buildability. Thus
before landing the update, I would like to land stand-alone SRUs that
fix and resolve FTBFS and autopkgtests regressions that will become
apparent once new OpenSSL is in proposed.
These are:
https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=uvloop
https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=libevent-rpc-perl
https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=python-httplib2
https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=python-imaplib2
https://launchpad.net/ubuntu/bionic/+queue?queue_state=1&queue_text=ruby2.5
The changes and fixes in above are openssl-version agnostic. Ideally
I'd want the above at least in -proposed, if not -updates, before
accepting openssl 1.1.1 update.
Then there is a bunch of syncs:
openssl (bionic-proposed/main) [1.1.0g-2ubuntu4.3 => 1.1.1-1ubuntu2.1~18.04.0]
python2.7 (bionic-proposed/main) [2.7.15~rc1-1ubuntu0.1 =>
2.7.15-4ubuntu4~18.04] (core) (sync)
python3.6 (bionic-proposed/main) [3.6.7-1~18.04 => 3.6.8-1~18.04.1]
(core) (sync)
python3.7 (bionic-proposed/universe) [3.7.1-1~18.04 =>
3.7.2-1~18.04.1] (no packageset) (sync)
python-cryptography (bionic-proposed/main) [2.1.4-1ubuntu1.2 =>
2.1.4-1ubuntu1.3] (core) (sync)
ruby2.5 (bionic-proposed/main) [2.5.1-1ubuntu1.1 => 2.5.1-1ubuntu1.3]
(kubuntu, ubuntu-desktop, ubuntu-server) (sync)
ruby-openssl (bionic-proposed/universe) [2.0.5-1build3 =>
2.0.9-0ubuntu1] (no packageset) (sync)
libio-socket-ssl-perl (bionic-proposed/main) [2.056-1 =>
2.060-3~ubuntu18.04.0] (core) (sync)
libnet-ssleay-perl (bionic-proposed/main) [1.84-1build1 =>
1.84-1ubuntu0.1] (core) (sync)
r-cran-openssl (bionic-proposed/universe) [1.0.1-1ubuntu1 =>
1.0.1-1ubuntu1.1] (no packageset) (sync)
nova (bionic-proposed/main) [2:17.0.7-0ubuntu2 => 2:17.0.7-0ubuntu2.1]
(openstack, ubuntu-server) (sync)
These were built in security pocket, in a bileto ppa, thus are
suitable for publishing in either (or both) -security or -updates
pockets.
These are built in correct order, thus e.g. python-cryptography was
built agains pythons that are built against openssl 1.1.1, and thus
all binaries are collectively installable on publication.
As you can notice 3.6 and 3.7 are point release bumps, that not only
introduce openssl 1.1.1 compatibility (fixes in test suite asumptions
re:tlsv1.3) but also add functionality to exploit/limit usage of
tlsv1.3.
Note that python3.7 is neither default nor supported python version,
it's standalone/inert in bionic by default - technology preview used
by some upstream CIs to gain access to python3.7 interpreter without
any other system dependencies.
Similarly with the rest of the syncs, they introduce
testsuites/adt-tests/ftbfs fixes and compatibility for openssl 1.1.1.
We (doko) do want to SRU the python3.6/3.7 point releases regardless
of openssl SRU, but doing this in one go, saves on validation
resources / adt testing, as python triggers a long tail of tests. Also
it may be cumbersome to split hairs of the python3.6/3.7 point release
update into openssl and non-openssl update portions.
The diffs for these uploads are quite large, and I am not sure what's
the best way to present these SRUs to the SRU team for review. In
addition to above syncs I could upload source only uploads into the
queue, however, the binaries here need to be built in security pocket
only (such that we have ability to push these update into security
pocket, if and when needed). Please let me know if you want any
changes from me to conquer reviewing all of the above SRUs.
--
Regards,
Dimitri.
-
Effectivement...
De mon coté, vu que tous mes serveurs Ubuntu sont en fait des VM Proxmox, je ferai des snapshots avant de me lancer dans les mises à jour... S’il y a un avantage à utiliser des VM c’est bien celui-là...
-
Et nginx ? ::)
Je suis en TLS 1.3 avec nginx sur serveur perso depuis début décembre, ça dépend surtout de la version d'OpenSSL associée.
-
Quand je vois que j'ai des serveurs Suse SLES11 SP4 au boulot qui ont une version d'OpenSSL qui ne supporte pas TLS 1.1/1.2 :P
-
Je viens de passer sous Debian 9 pensant passer à TLSv1.3, mais j'avais oublié qu'Apache2 n'était qu'en version 2.25 stable sur cette distrib.
Doit-on attendre Debian 10, où peut-on installer openssl 1.1.1 et apache2.35 ou autre, pour en bénéficier ?
J'ai lu qu'il valait mieux ne pas installer de version de paquet supérieur à celle fourni par défaut et en sécurité avec la distrib, sous peine de sortir des MAJ de sécurité et de se retrouver avec un programme non mis à jour. Bref qu'il était plus dangereux de mettre TLSv1.3 en upgradant soit même apache2 que de rester sur 1.2 avec MAJ auto de sécurité.
Que conseillez-vous ?
-
Que conseillez-vous ?
Docker et un container avec une version d'apache + openssl qui supporte TLS1.3 ?
-
Que conseillez-vous ?
virer Apache , mettre Caddy (https://caddyserver.com/) ;D
et accessoirement virer Debian pour mettre un OS minimalist (Container Linux par exemple).
Caddy avec Docker + certif Letsencrypt automatique + TLS 1.3:
installation du container
docker run -d \
--name caddy\
--restart unless-stopped\
-v /opt/web/Caddyfile:/etc/Caddyfile \
-v /opt/web/.caddy:/root/.caddy \
-v /opt/web/www:/www \
-v /opt/web/logs:/logs \
-p 80:80 -p 443:443 \
--log-driver=journald \
--log-opt tag="{{.Name}}" \
abiosoft/caddy -agree -conf /etc/Caddyfile
ajuster "/opt/web/" au dossier qu'on souhaite.
Dans ce dossier mettre le fichier Caddyfile:
Caddyfile:
https://monsite.com, http://monsite.com, https://www.monsite.com, http://www.monsite.com {
root /www/monsite.com
log / /logs/monsite.com/access.log {combined}
errors /logs/monsite.com/errors.log
gzip
tls mon@email.com
header / {
# a virer si on veux pouvoir utiliser http://...
Strict-Transport-Security "max-age=31536000;"
# trucs de renforcement sécurité (pas obligé)
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
}
}
mettre le contenu du site dans /opt/web/www/monsite.com
les logs d’accès seront dans /opt/web/logs/monsite.com/access.log, les erreurs dans errors.log
"journactl -t caddy" pour voir le log du container (ou "docker logs caddy").
"docker kill -s USR2 caddy" pour recharger la config (suite modif Caddyfile).
on peut ajouter autant de sites qu'on veut a la suite dans le Caddyfile.
si on veut du PHP, utiliser l'image docker "abiosoft/caddy:php".
sinon voir les exemples https://github.com/caddyserver/examples
-
Merci à tous les deux pour vos conseils.
Je vais regarder ça.
Par contre je pense garder debian enfin Raspbian qui est installé sur mon raspberry.
-
Le type est concerné par la sécurité (pour rappel, c'est un peu la base), l'abreuver de ce genre d'absurdité est-elle de l'inconscience, de l'ignorance, ou pire de la malveillance ?
La bonne réponse à la question de base: attendre que ta distribution te fournisse openssl 1.1.1
-
Le type est concerné par la sécurité (pour rappel, c'est un peu la base), l'abreuver de ce genre d'absurdité est-elle de l'inconscience, de l'ignorance, ou pire de la malveillance ?
La bonne réponse à la question de base: attendre que ta distribution te fournisse openssl 1.1.1
Chacun son avis. Ton opinion != faits.
En terme de sécurité mon opinion est qu'il est justement plus couvert avec un solution docker + un produit mis a jour rapidement comme Caddy que dépendre d'une usine a gaz dépassée que sont les grosses distribs Linux.
Apres si c'est pour un Pi ... *no comment*
peace.
-
Ton opinion != faits.
T'inquiètes, ce sont bien des faits que j'évoque :)
Ta non-acceptation reste ton problème personnel;
-
T'inquiètes, ce sont bien des faits que j'évoque :)
Ta non-acceptation reste ton problème personnel;
Des paroles en l'air , un ton très condescendant laissant percé une haute opinion de soi-meme associé avec un refus complet d'un échange d'idées argumentées, c'est tout ce que je vois pour l'instant.
Franchement ca sert a quoi de ce type d'échange a part polluer le forum ? y'a assez de spam comme ca.
-
En tous cas merci kgersen,
Suite à ton post j'ai testé Caddy, et wow c'est super propre :).
Site basculé en quelques minutes !
-
Je viens de passer sous Debian 9 pensant passer à TLSv1.3, mais j'avais oublié qu'Apache2 n'était qu'en version 2.25 stable sur cette distrib.
Doit-on attendre Debian 10, où peut-on installer openssl 1.1.1 et apache2.35 ou autre, pour en bénéficier ?
Salut,
As-tu tant besoin de TLS1.3 ? S'il s'agit de conseil je pense que tu devrais plutôt garder une bonne maîtrise de ton système : surtout pas d'openssl1.1.1 dans Debian9 donc. Je ne vois ensuite pas actuellement de "besoin" de supporter TLS1.3 pour un serveur, comparé à celui de correctement configurer TLS1.2 (ciphersuites & co) et virer TLS1.0 et 1.1.
S'il s'agit de discuter technique (je n'héberge que des services personnels), de mon côté j'ai Debian10+Apache, avec TLS1.3, tout ronronne (https://www.ssllabs.com/ssltest/analyze.html?d=www.sendell.com) (Debian buster installée après le freeze, je préfère procéder ainsi pour un nouveau serveur plutôt que gérer un dist-upgrade qui approche). %{SSL_PROTOCOL}x dans le LogFormat permet de suivre l'utilisation des différentes versions du protocole.
-
openssl 1.1.1 est maintenant disponible sur Ubuntu 18.04 LTS.
TLS 1.3 activé sans soucis jusqu'à présent sur mon reverse proxy nginx.
(https://lafibre.info/testdebit/ubuntu/201906_maj_openssl-111_ubuntu-1804_1.png)
-
C'est une bonne nouvelle.
Pour Apache il faudra par contre déployer une nouvelle version pour permettre d'avoir TLS 1.3
Ce que je trouve étonnant, c'est que sur un Ubuntu Desktop, la mise à jour n'est pas proposée par le gestionnaire de mise à jour graphique : il faut passer par apt pour faire la mise à jour !
Ce n'est d'ailleurs pas le seul paquet concerné :
(https://lafibre.info/testdebit/ubuntu/201906_maj_openssl-111_ubuntu-1804_2.png)
Si vous avez une idée du pourquoi, je cherche à comprendre pourquoi certains paquets ne sont pas proposés par le gestionnaire de mises à jour graphique.
Précision : capture d'écran réalisé sur un Ubuntu 18.04.1 clean sur lequel toutes les mises à jour par le gestionnaire de mises à jour graphique ont été réalisées. Aucun paquet n'a été rajouté ou enlevé à ceux qui sont installés par défaut par Ubuntu 18.04.1
-
Je me demande si ce n'est pas le fait qu'il soit nécessaire dans certains cas de redémarrer des services qui fait que la mise à jour n'est pas proposée directement.
Sur un serveur Ubuntu 18.04.2 configuré pour appliquer automatiquement les mises à jour de sécurité ("${distro_id}ESM:${distro_codename}") et les mises à jour recommandées ("${distro_id}:${distro_codename}-updates") la mise à jour OpenSSL 1.1.1 ne se fait pas.
Le début de mon fichier /etc/apt/apt.conf.d/50unattended-upgrades : (Note: je n'ai pas activé les mises à jour automatiques du débot non gérées "${distro_id}:${distro_codename}-backports"; et préversion "${distro_id}:${distro_codename}-proposed")
// Automatically upgrade packages from these (origin:archive) pairs
//
// Note that in Ubuntu security updates may pull in new dependencies
// from non-security sources (e.g. chromium). By allowing the release
// pocket these get automatically pulled in.
Unattended-Upgrade::Allowed-Origins {
"${distro_id}:${distro_codename}";
"${distro_id}:${distro_codename}-security";
// Extended Security Maintenance; doesn't necessarily exist for
// every release and this system may not have it installed, but if
// available, the policy for updates is such that unattended-upgrades
// should also install from here by default.
"${distro_id}ESM:${distro_codename}";
"${distro_id}:${distro_codename}-updates";
// "${distro_id}:${distro_codename}-proposed";
// "${distro_id}:${distro_codename}-backports";
};
Avec un simple apt upgrade j'ai par contre la mise à jour qui se lance et qui propose de redémarrer les services :
(https://lafibre.info/testdebit/ubuntu/201906_maj_openssl-111_ubuntu-1804_3.png)
-
Je suis mauvaise langue, il suffisait d'attendre : la mise à jour OpenSSL est disponible sur l'outil graphique :
(https://lafibre.info/testdebit/ubuntu/201906_maj_openssl-111_ubuntu-1804_4.png)
-
Ubuntu 18.04 propose TLS 1.3 avec Apache !
Je ne sais pas depuis quand c'est en place : je me suis apercus aujourd'hui mes serveurs sous Ubuntu 18.04 avaient du TLS 1.3
Je note bien les mises à jour proposées pour Apache, mais on est resté sur la même version et je ne pensais pas que le support de TLS 1.3 (inexistant dans la version 2.4.29 d'Apache) serait rétro-porté.
Il faut en effet OpenSSL 1.1.1 et une version d'Apache qui supporte TLS 1.3 pour avoir TLS 1.3 activé.
Je ne sais pas dans quelle mise à jour ci-dessous le patch TLS 1.3 est arrivé...
01/09/2018 : Apache/2.4.29 (Ubuntu) Server built: 2018-06-27T17:05:04
04/10/2018 : Apache/2.4.29 (Ubuntu) Server built: 2018-10-03T14:41:08
27/11/2018 : Apache/2.4.29 (Ubuntu) Server built: 2018-10-10T18:59:25
05/04/2019 : Apache/2.4.29 (Ubuntu) Server built: 2019-04-03T13:22:37
11/07/2019 : Apache/2.4.29 (Ubuntu) Server built: 2019-06-28T16:49:35
19/08/2019 : Apache/2.4.29 (Ubuntu) Server built: 2019-07-16T18:14:45
30/08/2019 : Apache/2.4.29 (Ubuntu) Server built: 2019-08-26T13:41:23
18/09/2019 : Apache/2.4.29 (Ubuntu) Server built: 2019-09-16T12:58:48
18/03/2020 : Apache/2.4.29 (Ubuntu) Server built: 2020-03-13T12:26:16
-
https://changelogs.ubuntu.com/changelogs/pool/main/a/apache2/apache2_2.4.29-1ubuntu4.13/changelog
Premier ajout du support TLS 1.3 le 3 décembre 2019, et patchs additionnels le 13 mars 2020 :)
-
Donc c'est la mise à jour qui a été poussée le 18 mars 2020 (mercredi dernier) qui apporte TLS 1.3
Il sera intéressant de voir le gain que cela va faire sur les stats, car c'est appliqué comme une mise à jour de sécurité sur Ubuntu 18.04.
-
Statistique du déploiement de TLS 1.3 sur Internet :
(https://lafibre.info/images/ssl/statistiques_sites_https_populaires.webp)
En mars 2020 l'ANSSI (Agence nationale de la sécurité des systèmes d'information) recommandait de prendre en charge TLS 1.3.
Extrait du guide ANSSI "Recommandations de sécurité relatives à TLS" :
(https://lafibre.info/images/ssl/202003_anssi_recommandations_de_securite_relatives_a_tls_1.webp)
Guide ANSSI "Recommandations de sécurité relatives à TLS" : (cliquez sur la miniature ci-dessous - le document est au format PDF)
(https://lafibre.info/images/ssl/202003_anssi_recommandations_de_securite_relatives_a_tls.webp) (https://lafibre.info/images/ssl/202003_anssi_recommandations_de_securite_relatives_a_tls.pdf)
-
Tu fais un beau A+ ( en dernière ligne) ;D
-
TLS 1.3 le support par l'ensemble des clients est enfin arrivé !
Si TLS 1.3 a été introduit rapidement dans les navigateurs web et en quelques semaines, ces mises à jour ont été diffusées à 99% des clients, on peut noter deux mauvais élèves :
- Apple : qui ne gère pas ça dans une mise à jour de Safari, mais dans une mise à jour majeure du système d'exploitation et pas dans Safari.
Résultats, ceux qui sont sous macOS 10.13 High Sierra ont encore reçu une mise à jour de sécurité le 12 novembre 2020, mettant à jour Safari et macOS, mais cette mise à jour ne permettrait pas d'avoir TLS 1.3, il faut passer à MacOS 10.14 Mojave. Cela fait 22 mois que la dernière version de macOS ne supportant pas TLS 1.3 n'est plus maintenue et on peut dire que tous les clients sont enfin compatibles TLS 1.3
- Microsoft : Aujourd'hui Microsoft Edge legacy (version 18) ne supporte pas TLS 1.3 et est très peu utilisée, mais certaines applications Windows intègrent une WebView et elles sont presque toutes encore basées sur l'ancien framework Microsoft Edge, Microsoft venant de lancer la migration vers WebView2 basée sur Chromium et supportant TLS 1.3, je ne serais pas étonné que certaines applications Windows ne supportent pas TLS 1.3.
(https://lafibre.info/images/ssl/tls13_support.webp)
-
Qualys SSL Labs - SSL Pulse (https://www.ssllabs.com/ssl-pulse/) donne des statistiques sur les 150 000 sites Web les plus populaires au monde.
Plus de 99,9% ont toujours le support de TLS 1.2.
Pour les 0,1% qui n'ont pas le support de TLS 1.2, on ne sait pas si c'est qu'ils ont uniquement TKS 1.0 + TLS 1.1 ou s'ils ont uniquement TLS 1.3.
Bien que le support de TLS 1.3 par tous les navigateurs web soit réalisé, on ne voit donc pas encore de retrait de TLS 1.2.
(https://lafibre.info/images/ssl/202403_qualys_ssl_labs_ssl_pulse_protocol_support.webp)
-
dans le TLS 1.2, il y a aussi différente variante.
Certaines sont encore tolérées car le site qui te donne des conseilles sur la sécurité des sites web TLS.
https://ssl-config.mozilla.org/
https://cryptcheck.fr/ (A+ avec ECDHE-RSA-AES128-GCM-SHA256 / ECDHE-RSA-AES256-GCM-SHA384 / ECDHE-RSA-CHACHA20-POLY1305 )
https://internet.nl Good:
ECDHE-ECDSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
ECDHE-ECDSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
ECDHE-ECDSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
ECDHE-RSA-AES256-GCM-SHA384 (TLS_AES_256_GCM_SHA384 in 1.3) [1.2]
ECDHE-RSA-CHACHA20-POLY1305 (TLS_CHACHA20_POLY1305_SHA256 in 1.3) [1.2]
ECDHE-RSA-AES128-GCM-SHA256 (TLS_AES_128_GCM_SHA256 in 1.3) [1.2]
Sufficient:
ECDHE-ECDSA-AES256-SHA384 [1.2]
ECDHE-ECDSA-AES256-SHA [1.0]
ECDHE-ECDSA-AES128-SHA256 [1.2]
ECDHE-ECDSA-AES128-SHA [1.0]
ECDHE-RSA-AES256-SHA384 [1.2]
ECDHE-RSA-AES256-SHA [1.0]
ECDHE-RSA-AES128-SHA256 [1.2]
ECDHE-RSA-AES128-SHA [1.0]
DHE-RSA-AES256-GCM-SHA384 [1.2]
DHE-RSA-CHACHA20-POLY1305 [1.2]
DHE-RSA-AES128-GCM-SHA256 [1.2]
DHE-RSA-AES256-SHA256 [1.2]
DHE-RSA-AES256-SHA [1.0]
DHE-RSA-AES128-SHA256 [1.2]
DHE-RSA-AES128-SHA [1.0]
et pas mal d'autres.
Donc pourquoi s'embêter à désactiver TLS 1.2 ... Puis 90+% des sites n'ont rien de méga confidentiel qui nécessite des niveaux de sécurité ultra élevé. (hors santé et paiement/banque ..). Il vaut mieux que les sysadmin mettent à jour les serveurs / installent les patchs de sécurité.
Il faut quand même rester compatible avec le plus grand nombre.
D'ailleurs lafibre.info supporte toujours de vieux ciphers d'après ce site : https://cryptcheck.fr/https/lafibre.info