Raven - Blog
16. Avril 2022

Hardening TLS

Posté le 16. Avril 2022  •  11 minutes  • 2151 mots  • Autres langues:  English

Avant de débuter cet article, un petit point de langage important. Dans le jargon informatique, il y a un abus de langage courant : parler de SSL pour désigner TLS. En effet, cela fait environ 20 ans que TLS a remplacé SSL mais les habitudes sont tenaces. Allez, je compte sur vous, dans 66 jours vous ne parlerez plus jamais de SSL mais de TLS grâce à moi !

Dans cet article concernant la cyber sécurité et celle autour de TLS en particulier, je vais vous apprendre à renforcer vos configurations TLS sur vos serveurs. Cet article n’est pas exhaustif, mais je me suis attaqué aux réglages les plus pointilleux et qui sont généralement méconnus ou mal connus.

Les sujets que j’aborde sont :

HSTS (HTTP Strict-Transport-Security)

A - HSTS c’est quoi ?

HSTS pour HTTP Strict-Transport-Security existe depuis 2012 est une en-tête de réponse HTTP qui informe le navigateur (ou toute autre agent utilisateur compatible avec HSTS) de la politique de sécurité HTTP à adopter, à savoir celle de : se connecter à l’avenir exclusivement en HTTPS. De plus, cette politique définit également une durée applicable.

B - Différence entre redirection HTTP/HTTPS et HSTS

La différence est simple : une redirection permanente 301 est effectuée côté serveur, la politique HSTS (après la première connexion) est réalisée côté client et c’est exactement dans cette différence que se trouve l’apport de sécurité !

C - HSTS, la protection contre l’attaque MITM

HSTS est un mécanisme de sécurité qui vient protéger l’utilisateur contre une éventuelle attaque MITM (Man In The Middle). L’attaque dite de “l’homme du milieu” en français, est une attaque réalisée lorsqu’une personne se place entre vous et le serveur avec qui vous dialoguez ( MITM ).

L’exemple classique est l’utilisation d’une connexion WIFI publique : vous avez l’habitude d’aller travailler dans le café du coin et d’utiliser leur wifi public qui est même enregistré dans votre PC/smartphone. Sauf qu’une personne malveillante peut diffuser un signal WIFI qui aura le même SSID (nom du signal) et le même mot de passe (ne pensez pas que ce soit difficile, on peut même le faire depuis un PC portable…). Lorsque vous arrivez dans votre café habituel, vous ouvrez votre PC portable ou même votre smartphone comme d’habitude et vous commencez à surfer sur Internet. Sauf que sans le savoir vous n’êtes pas sur la connexion WIFI du café mais sur celle du pirate, vos terminaux s’y sont connectés en toute transparence car le nom du signal et le mot de passe sont déjà enregistrés.

Vous êtes désormais vulnérables à beaucoup de choses (DNS poisoning, ARP spoofing, DoS et j’en passe…) mais concentrons-nous sur notre sujet. À tort, vous pensez que HTTPS vous protège en chiffrant la connexion entre vous et le site web que vous consultez. Or, au moment où vous allez sur le site de votre banque qui n’a pas d’en-tête HSTS, le pirate entre vous et le serveur gérant le site fait en sorte que votre requête passe par le protocole HTTP sur le port 80, donc en clair. (Je ne détaille pas la méthode mais sachez que c’est également très simple à faire.)

Notez bien que même si le site que vous consultez possède une directive de redirection permanente 301 HTTP -> HTTPS, le mal est déjà fait car la première requête contenant par exemple votre cookie de session est partie en claire sur HTTP/80 et le site ne vous redirigera qu’à la requête suivante sur HTTPS/443. Pour vous, tout était transparent et le pirate a récupéré ce qu’il voulait.

Hors sujet : Il y a beaucoup de marketing idiot autour des VPN aujourd’hui, mais clairement si vous avez pour habitude d’utiliser des WIFI publics, souscrivez à une offre VPN ou, mieux, mettez le vôtre en place sur un VPS par exemple !

D - Le fonctionnement côté client

Vous l’aurez compris, c’est là que HSTS prend tout son sens. La première fois que vous visitez un site web avec votre navigateur, ce dernier stockera le domaine dans une liste pendant le temps indiqué dans l’en-tête HSTS du site visité. Ainsi, quoi qu’il advienne et indépendamment du réseau, votre navigateur ne dialoguera plus jamais avec ce site en HTTP/80. Aucune requête ne pourra plus être émise et la traduction d’adresse HTTP -> HTTPS sera effectuée en local par le navigateur.

Quant au navigateur Mozilla Firefox, il tient un fichier qu’il complète au fur et à mesure de votre visite sur des sites avec des en-têtes HSTS. Ce fichier se nomme SiteSecurityServiceState.txt et est situé dans votre dossier de profil Firefox.

Si vous souhaitez réinitialiser HSTS pour un site en particulier, vous pouvez donc supprimer la ligne du fichier ou, de manière plus simple, dans l’historique de Firefox vous faites un clic droit sur le site et “oublier ce site”.

Pour ce qui est de la navigation privée, j’ai pu vérifier que les sites visités sur Firefox ne sont pas ajoutés dans le fichier SiteSecurityServiceState.txt.

E - Le fonctionnement côté serveur

Côté serveur, la mise en place est rapide : il suffit de rajouter une ligne dans votre vhost. Par exemple, sur Apache :

Header always set Strict-Transport-Security "max-age=63072000"

L’option max-age est en secondes et est par convention de 2 ans.

Vous pouvez ajouter les options :

Une fois HSTS mis en place, vous pouvez contrôler rapidement si c’est OK en récupérant l’en-tête avec curl

1
2

 curl -s -D- https://r4ven.fr | grep -i Strict
Strict-Transport-Security: max-age=63072000

Si HSTS n’est pas paramétré sur le domaine, il n’y aura aucun retour à cette commande. Par exemple, si vous êtes dans cette banque qui met certainement des millions d’euros dans “la sécurité informatique” mais qui ne sait pas mettre une en-tête HSTS sur son serveur (on parle d’une banque et d’un mécanisme de sécurité qui existe depuis 2012 🙄), vous n’aurez aucun retour :

1

curl -s -D- https://credit-agricole | grep -i Strict

F - Contournement d’une limite inhérente

Vous l’aurez compris, HSTS ne fonctionne qu’après la première visite d’un site. C’est une limite et en fonction de votre modèle de menace, et plus particulièrement de celui de vos utilisateurs (une banque se doit plus de sécurité pour ses utilisateurs qu’un blog sur le saucisson sec ), vous aurez peut-être besoin d’aller plus loin.

Google héberge et maintient une fonctionnalité qui n’est pas officielle et qui n’est pas dans les spécificités de HSTS : preload

Pour faire court, c’est une liste sur laquelle vous pouvez faire une demande d’inscription et qui contient la liste des sites pour lesquels même la première connexion doit se faire de manière sécurisée par HTTPS. Les navigateurs ont toute liberté pour l’utiliser. Le site pour inscrire votre domaine est ici : https://hstspreload.org/

G - Analyse de trames IP prouvant le fonctionnement HSTS

Lectrices, lecteurs, pour vous, j’ai poussé un peu mes recherches sur le fonctionnement de HSTS en surveillant les trames IP directement avec Wireshark, et si vous aviez l’ombre d’un doute, sachez que ça fonctionne 😁 !

Pour ce test, j’ai utilisé la fonction “oublier ce site” de Firefox. Après vérification, mon domaine r4ven.fr a bien disparu du fichier SiteSecurityServiceState.txt . J’ai ensuite réalisé une connexion sur : http://r4ven.fr et le site n’ayant jamais été visité, voici ce qu’il s’est passé :

  1. On voit bien que le premier paquet sortant est envoyé sur le port 80 du serveur distant.
  2. C’est le serveur distant qui indique une redirection permanente 301, il me ramène donc ensuite sur le port 443 du serveur
  3. Le protocole passe au HTTPS et la négociation TLS commence

Analyse de trame Wireshark

Une fois le site dans la liste de mon navigateur, si je retente une connexion sur http://r4ven.fr, les trames sur HTTP/80 n’apparaissent plus, on est directement en HTTPS/443. Le navigateur fait donc bien la translation d’adresse localement.

DNS CAA

Toute autorité de certification peut émettre un certificat pour un nom de domaine à partir du moment où le demandeur aurait prouvé qu’il contrôle ce domaine. Mais les processus de contrôle peuvent être divers et ne sont pas toujours basés sur un enregistrement DNS (par exemple un Défi HTTP-01 Let’s Encrypt). C’est là que l’enregistrement DNS CAA vient jouer son rôle !

En sécurité informatique, on vient souvent s’appuyer sur le protocole DNS afin de permettre à un acteur extérieur de faire une vérification, comme par exemple :

Quant à l’enregistrement DNS CAA (pour Certification Authority Authorization), il permet quant à lui au propriétaire d’un nom de domaine de lister les autorités de certifications qui peuvent délivrer des certificats pour son domaine.

Il est à noter que le CAA ne sert pas au navigateur à contrôler que l’émetteur du certificat soit autorisé lors d’une négociation client/serveur TLS. Le CAA ne sert qu’aux autorités de certification qui doivent, lorsqu’elles émettent un certificat, vérifier cet enregistrement. Pour résumer, le CAA est un contrôle supplémentaire effectué par l’autorité de certification afin d’éviter une délivrance de certificat frauduleuse.

Sa mise en place est simple comme bonjour, enfin simple comme un enregistrement DNS 😁

Sans rentrer dans les détails (je vous laisse consulter la RFC si besoin), la structure d’un enregistrement DNS CAA sera :

Sur OVH par exemple, une modale est prévue pour l’enregistrement CAA afin de vous guider :

DNS CAA OVH

Au niveau du domaine en lui-même, pour avoir plus d’informations sur l’endroit où placer votre enregistrement CAA, je vous conseille ce paragraphe très clair sur le site de l’autorité LetsEncrypt : letsencrypt.org

Au final, vous pouvez vérifier la bonne mise en place avec dig. Ici pour l’autorité Let’s Encrypt :

1
2
3

dig CAA r4ven.fr
;; ANSWER SECTION:
r4ven.fr.		60	 IN	CAA	0 issue "letsencrypt.org"

Cipher Suite

Avant d’aller plus loin, si vous ne savez pas ce qu’est une suite cryptographique, je vous invite à consulter cette page Wikipedia.

Pour commencer, il est important de noter que les technologies de chiffrement sont en constante en évolution, et je vous conseille d’avoir une veille technologique ( comme mon flux RSS par exemple ? :) ) autour de ces sujets afin de vous tenir au courant de l’état de l’art.

Comme souvent en sécurité informatique, il s’agit aussi de s’adapter à son modèle de menace et à ses utilisateurs. Personnellement, je pars du principe qu’une personne utilisant Internet Explorer 8 ou un PC qui n’est pas mis à jour depuis plusieurs années aura d’autres problèmes que de celui d’accéder à mon site internet parce que je n’autoriserais que les protocoles les plus récents de chiffrement. Et si ça lui permet de percuter qu’il faut mettre son PC à jour ou de ne plus utiliser Internet Explorer mais plutôt Mozilla Firefox, alors c’est gagné !

Par conséquent, vous aurez compris mon avis sur le sujet : limitez-vous au maximum à l’état de l’art actuel, point barre.

Pour vous aider dans cette tâche, je partage avec vous un lien à bookmarker d’urgence ! Il s’agit de l’excellent https://ssl-config.mozilla.org/

Mozilla configurateur

En quelques cases, vous aurez une conf TLS aux petits oignons 👌

Let’s Encrypt : RSA 4096

Si vous utilisez l’autorité de certification Let’s Encrypt comme moi, retenez que par défaut le certbot génère des clés RSA d’une longueur de 2048bits. Je vous recommande de modifier cette valeur pour une longueur de 4096 bits.

Pour modifier ce paramètre sur Debian, éditez le fichier /etc/letsencrypt/cli.ini en ajoutant :

1

rsa-key-size = 4096

Si vous avez déjà généré des certificats pour des domaines, vous pouvez également les modifier au cas par cas dans le dossier /etc/letsencrypt/renewal

Si ça vous intéresse, je vous donne le lien de ce site qui recense les recommandations des différentes autorités (ANSSI, BSI etc…) en matière de taille de clés : https://www.keylength.com/fr/

Tester votre configuration TLS

Vous avez suivi mon article avec minutie et vous souhaitez savoir si vous avez fait les choses correctement ?

Il existe plusieurs sites internet qui testeront le réglage et vous attribueront une notation ! Parmi les plus célèbres, je vous conseille : https://www.ssllabs.com

Mais vous avez aussi un site développé par l’excellent @aeris22 qui vous permettra de tester votre configuration, ça se passe ici : https://tls.imirhil.fr/

J’espère que vous obtiendrez un magnifique A+ comme moi ! À vous de jouer maintenant.

Test de configuration TLS

Follow me

Subscribe to my RSS feed !