Certificats et TLS : comment un site HTTPS prouve son identité

Lorsque vous tapez l'adresse de votre banque, comment votre navigateur sait-il qu'il parle vraiment à votre banque et pas à un imposteur qui aurait détourné la connexion ? Le cadenas affiché dans la barre d'adresse est le résultat visible d'un mécanisme élégant : les certificats et le protocole TLS. Dans cette leçon, vous allez voir ce qui se cache derrière ce petit symbole, et le vérifier de vos propres mains dans votre laboratoire.

Dans les leçons précédentes, vous avez vu le hachage (intégrité) et la cryptographie à clé publique (échange de clés, signature). Un problème restait entier : comment être certain qu'une clé publique appartient bien à celui qui l'annonce ? Les certificats y répondent. Nous retrouvons ici le HTTPS du premier chapitre : « HTTP + TLS ».

Le certificat : une carte d'identité numérique

Un certificat numérique (au format X.509) est un document électronique qui associe une identité (un nom de domaine, par exemple) à une clé publique. Il contient notamment :

• le ou les noms pour lesquels il est valable (champ Subject Alternative Name, SAN) ;
• la clé publique du serveur ;
• la période de validité (date de début, date de fin) ;
• l'émetteur, c'est-à-dire l'autorité qui l'a délivré ;
• la signature numérique de cet émetteur, qui garantit que le contenu n'a pas été modifié.

Comme pour une carte d'identité, la valeur du certificat ne tient pas au document lui-même, mais à la confiance qu'on accorde à l'organisme qui l'a délivré.

Les autorités de certification et la chaîne de confiance

Une autorité de certification (AC) est un organisme qui vérifie qu'un demandeur contrôle bien le domaine concerné, puis signe son certificat. Votre système d'exploitation et votre navigateur embarquent une liste d'AC racines de confiance, le magasin de certificats.

La confiance fonctionne en chaîne :

1. Le certificat du site (feuille) est signé par une AC intermédiaire.
2. Le certificat de l'AC intermédiaire est signé par une AC racine.
3. Le certificat racine est présent, de façon préalable, dans le magasin de confiance de votre système.

Votre navigateur remonte la chaîne : il vérifie chaque signature avec la clé publique du certificat du dessus, jusqu'à arriver à une racine qu'il connaît déjà. Si la chaîne est complète et valide, le certificat est accepté.

Ce que le navigateur vérifie

Quand vous vous connectez à un site HTTPS, le navigateur contrôle plusieurs choses avant d'afficher le cadenas :

• La chaîne remonte bien à une AC de confiance.
• Le certificat est dans sa période de validité.
• Le nom demandé figure dans le certificat (le certificat de boutique.example.org n'est pas valable pour autre.example.net).
• Le certificat n'a pas été révoqué (annulé avant son expiration) ; plusieurs mécanismes de vérification existent.
• Le serveur prouve qu'il possède bien la clé privée associée, en signant un élément de l'échange.

Si l'une de ces vérifications échoue, le navigateur affiche un avertissement plein écran. Prenez ces avertissements au sérieux : un certificat expiré est souvent un oubli de l'administrateur, mais un certificat qui ne correspond pas au nom ou d'un émetteur inconnu peut signaler une interception. Ne cliquez jamais sur « continuer quand même » pour un site sensible. Rappelez-vous la leçon sur ARP : c'est précisément cette alerte qui protège l'utilisateur d'un homme du milieu.

Le déroulé d'une connexion TLS (simplifié)

TLS (Transport Layer Security) est le protocole qui chiffre la connexion. Les versions récentes ont remplacé les anciennes (SSL, TLS 1.0 et 1.1, aujourd'hui abandonnées). Voici le déroulé, en version simplifiée :

1. Bonjour du client : le navigateur indique les versions et les algorithmes qu'il supporte, le nom du site visé, et envoie une valeur publique éphémère pour l'accord de clé.
2. Réponse du serveur : il choisit les paramètres, envoie sa propre valeur éphémère et son certificat, et prouve qu'il détient la clé privée en signant des éléments de l'échange.
3. Vérification : le navigateur contrôle le certificat comme décrit ci-dessus.
4. Calcul des clés de session : les deux parties dérivent la même clé symétrique, sans jamais l'envoyer sur le réseau.
5. Échange chiffré : tout le trafic HTTP qui suit est chiffré avec cette clé de session, en symétrique.

Vous retrouvez les ingrédients des leçons précédentes : asymétrique pour s'authentifier et s'accorder sur la clé, symétrique pour chiffrer, signatures pour prouver l'identité, hachage pour l'intégrité. Vous pouvez d'ailleurs observer le début de cet échange dans Wireshark (filtre tls) : les messages d'accueil sont visibles, mais ce qui suit est chiffré.

Autres notions utiles

• Certificat auto-signé : un certificat signé par lui-même, sans autorité tierce. Aucun navigateur ne lui fait confiance par défaut. C'est parfait pour un laboratoire, et à proscrire pour un site public.
• Transparence des certificats : les autorités publient chaque certificat émis dans des registres publics, ce qui permet de détecter l'émission frauduleuse d'un certificat pour votre domaine. Ces registres sont aussi une source d'information publique sur les noms de domaine (nous y reviendrons en parlant d'OSINT).
• HSTS : un en-tête qui demande au navigateur de n'utiliser que HTTPS pour un site donné, ce qui empêche les attaques de rétrogradation vers HTTP.
• Automatisation : des autorités proposent des certificats gratuits délivrés et renouvelés automatiquement par un protocole standard. Cela a considérablement généralisé le chiffrement du web.

Expérimenter dans votre laboratoire

Vous allez créer votre propre certificat auto-signé, lancer un petit serveur TLS local et observer ce que voit un client. Tout se passe sur votre machine.

# 1. Générer une clé et un certificat auto-signé valable 30 jours
openssl req -x509 -newkey rsa:2048 -nodes -keyout labo.key -out labo.crt \
  -days 30 -subj "/CN=labo.local"

# 2. Lire le contenu du certificat
openssl x509 -in labo.crt -noout -subject -issuer -dates

# 3. Lancer un serveur TLS local sur le port 8443
openssl s_server -accept 8443 -cert labo.crt -key labo.key -www

# 4. Dans un autre terminal, s'y connecter en tant que client
echo | openssl s_client -connect 127.0.0.1:8443 -servername labo.local

À l'étape 2, remarquez que l'émetteur (issuer) et le sujet (subject) sont identiques : le certificat est auto-signé. À l'étape 4, la sortie du client contient une ligne du type « verify error: self-signed certificate » : le client ne fait pas confiance à ce certificat, car aucune autorité reconnue ne l'a signé. Sa version du protocole et le nom de la suite cryptographique négociée sont aussi indiqués.

À vous de jouer

1. Réalisez les quatre étapes ci-dessus et notez dans votre carnet : l'émetteur, la date d'expiration, la version de TLS négociée et le message d'erreur de vérification.
2. Dans Wireshark (interface de bouclage), filtrez tcp.port == 8443 pendant une connexion. Repérez les messages de début d'échange (Client Hello, Server Hello). Pouvez-vous lire le contenu qui suit ?
3. Dans votre navigateur, ouvrez un site HTTPS quelconque et inspectez son certificat (clic sur le cadenas). Notez l'émetteur et la date d'expiration, puis comparez-les au vôtre.
4. Réflexion : pourquoi un certificat valable pour boutique.example.org ne doit-il pas être accepté pour un autre nom ?

Vous savez maintenant comment les clés servent à protéger les échanges. Reste un point pratique, souvent la cause d'incidents réels : comment garder ces clés et ces secrets en sécurité. C'est le sujet de la dernière leçon de ce chapitre.