Mon blog utilise TLS 1.3


Le votre aussi bientôt j'espère

10 ans après la normalisation de TLS 1.2 dans le RFC 5246, TLS 1.3 a finalement été finalisé en août 2018 dans le RFC 8446 après une gestation particulièrement longue et mouvementée (le premier brouillon date d'avril 2014). Dans la foulée, en septembre, la version d'OpenSSL le prenant en charge (1.1.1) sort. Le temps de vérifier et corriger les logiciels qui en dépendent, cette version est arrivée dans Debian Buster (actuelle branche de test) à la toute fin octobre. La version d'Apache compatible (2.4.36) n'a pas été mise à disposition dans Buster, qui est passé directement à la 2.4.37 quelques jours après OpenSSL 1.1.1.

Bref, ce site est désormais capable d'utiliser TLS 1.3 depuis novembre. Si les protocoles sont gérés de la sorte dans la configuration TLS de votre serveur Apache :

SSLProtocol ALL -SSLv3 -TLSv1 -TLSv1.1

Bravo, vous n'avez rien à faire, Apache est capable d'utiliser TLS 1.3 tout seul comme un grand pour peu que vos logiciels soient à jour 🙂. Petite astuce tout de même : les suites de chiffrement ne se définissent pas via la directive classique du mod_ssl d'Apache SSLCipherSuite car elles ne sont pas gérées par le même paramètre dans OpenSSL. Or si on jette un œil à ce dernier, on constate que l'ordre par défaut est le suivant :

		# openssl ciphers -v | grep TLSv1.3
		TLS_AES_256_GCM_SHA384  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(256) Mac=AEAD
		TLS_CHACHA20_POLY1305_SHA256 TLSv1.3 Kx=any      Au=any  Enc=CHACHA20/POLY1305(256) Mac=AEAD
		TLS_AES_128_GCM_SHA256  TLSv1.3 Kx=any      Au=any  Enc=AESGCM(128) Mac=AEAD

La machine hébergeant ce blog n'ayant pas les instructions AES-NI, je préfére mettre ChaCha20-Poly1305 en premier, puis AES-128 en deuxième. Donc comment dire à Apache d'utiliser un ordre différent ? Pas de soucis, il est possible d'accéder à l'API SSL_CONF d'OpenSSL via la directive SSLOpenSSLConfCmd et donc passer au mod_ssl des commandes qui ne sont pas encore implémentées dans ce dernier. Dans la configuration, on indique donc :

SSLOpenSSLConfCmd Ciphersuites TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384

en plus de SSLCipherSuite. Astuce bonus, c'est grâce à SSLOpenSSLConfCmd que je peux forcer les courbes elliptiques à utiliser pour ECDH :

SSLOpenSSLConfCmd Curves X25519:sect571r1:secp521r1:secp384r1

Vous remarquerez que prime256v1 est absente (et ce depuis fort longtemps) et que ça ne semble gêner personne. L'outil de test de SSLLabs est fort pratique pour tester la compatibilité théorique des clients et prendre des décisions en fonction.

Et côté client justement ? TLS 1.3 est activé par défaut depuis Firefox 60 (Il était présent depuis la version 52 mais devait être activé manuellement). Dans Chrome, il est activé par défaut depuis Chrome 70 – après une brève activation en 2017 (La Pieuvre du faire machine arrière à cause de middleboxes dangeuresement débiles, notamment celles des grands défenseurs des droits humains de chez BlueCoat).

Ceci étant dit, ces 2 navigateurs ne sont pas les seuls clients se connectant à ce site. Une grande majorité des requêtes vient plutôt de robots, que ce soit les crawlers des moteurs de recherches et surtout les agrégateurs de flux RSS/Atom tel que Tiny Tiny RSS.

J'ai donc activé le log des protocoles de chiffrement (j'en parlais dans mon précédent billet), écrit un petit script qui compte le nombre de connexions quotidiennes et le protocole utilisé, en dédoublonnant par IP (elles ne sont pas conservées outre la politique habituelle de log), agrégé le tout par semaine et passé le tout à gnuplot afin d'avoir un beau graphique permettant de suivre l'évolution de l'adoption de TLS 1.3 se connectant au site. Il sera mis à jour tous les dimanches, lors de la rotation de logs du serveur.

Une connexion correspond donc à la venue d'un client sur une journée de la semaine, quel que soit le nombre de requêtes effectuées par la suite (si le comptage se faisait par requêtes, mes appareils seraient sur-représentés). Les statistiques commencent au 18 novembre, dernier jour de la semaine 46. Les données pour cette semaine ne sont donc pas nécessairement fiables.

Il est aussi accessible via une page dédiée (regardez le menu 🙂).