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 🙂. Regardons l'ordre défini pour les suites de chiffrements du protocole dans OpenSSL :

		# 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. Pour dire à Apache d'utiliser un ordre différent, on passe toujours par la directive SSLCipherSuite du mod_ssl. Ceci dit les suites de chiffrements étant gérées par un paramètre spécifique dans OpenSSL, il y a un twist et il faut indiquer à Apache qu'il s'agit des algorithmes de TLS 1.3. Il faut donc explicitement mettre TLSv1.3 après le nom de la directive. Ce qui implique qu'il faut désormais indiquer 2 fois la directive, une première fois pour TLS 1.2 et une deuxième pour TLS 1.3 :

# Suite de chiffrements TLSv1.2
		SSLCipherSuite ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384
		# Suite de chiffrements TLSv1.3
		SSLCipherSuite TLSv1.3 TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384

Attention, TLS 1.3 interdisant la renégociation, il est impossible de spécifier l'ordre des algorithmes dans un contexte de répertoire (<Directory>). Une ancienne version de cet article disait que SSLCipherSuite n'était pas capable de gérer l'ordre de chiffrement pour TLS 1.3 et qu'il fallait utiliser par l'API SSL_CONF d'OpenSSL via la directive SSLOpenSSLConfCmd et ainsi passer au mod_ssl la commande souhaitée. La technique fonctionnait mais le billet était faux sur ce point.

Petite astuce tout de même autour de la directive SSLOpenSSLConfCmd, c'est grâce à elle que je peux forcer les courbes elliptiques à utiliser pour ECDH dans la configuration d'Apache :

SSLOpenSSLConfCmd Curves X25519:sect571r1:secp521r1:secp384r1

Curves est ici un paramètre d'OpenSSL et non d'Apache. 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 🙂).