TLS 1.3 et HTTPS : comment fonctionne la poignée de main

TLS (Transport Layer Security) est le protocole qui chiffre et authentifie une connexion entre un client et un serveur ; HTTPS, c'est simplement HTTP transporté dans une connexion TLS, sur le port 443. Au début de chaque connexion, une poignée de main (handshake) permet au client de vérifier l'identité du serveur grâce à son certificat et aux deux parties de convenir d'une clé de session, qui chiffre ensuite tous les échanges en AES-GCM ou ChaCha20. Ce chapitre explique ce que TLS protège et ne protège pas, déroule la poignée de main TLS 1.3, montre comment tester un serveur et configurer HTTPS correctement.

Ce que TLS protège, et ce qu'il ne protège pas

TLS assemble toutes les briques des chapitres précédents : l'échange de clés Diffie-Hellman sur courbe elliptique (chapitre 4), le certificat et la signature (chapitres 7 et 8), le chiffrement authentifié (chapitre 3). Il apporte trois garanties :

• la confidentialité des données échangées : un espion ne voit que des octets chiffrés ;
• l'intégrité : toute modification d'un paquet en transit est détectée et la connexion est coupée ;
• l'authenticité du serveur : le certificat prouve que le client parle au bon serveur (et, si on le configure, l'authenticité du client avec un certificat client, en TLS mutuel).

Il ne fait pas tout :

Les versions : de SSL à TLS 1.3

On dit encore « certificat SSL » par habitude, mais SSL n'existe plus : un serveur correctement configuré n'accepte que TLS 1.2 et TLS 1.3. TLS 1.3 a fait le ménage : plus d'échange de clés RSA statique (qui ne garantissait pas la confidentialité persistante), plus de mode CBC, plus de MD5 ni de SHA-1, plus de compression ; il ne reste que des mécanismes sûrs.

La poignée de main TLS 1.3 étape par étape

En TLS 1.3, la poignée de main ne prend qu'un aller-retour entre le client et le serveur avant l'envoi des données (contre deux en TLS 1.2).

1. ClientHello (en clair). Le navigateur annonce les versions et les suites de chiffrement qu'il accepte, le nom du site demandé (extension SNI, pour qu'un serveur qui héberge plusieurs sites choisisse le bon certificat) et, déjà, sa part de clé Diffie-Hellman éphémère (key share), le plus souvent sur la courbe X25519, ou en mode hybride post-quantique X25519MLKEM768 (chapitre 11).
2. ServerHello (en clair). Le serveur choisit la suite et renvoie sa propre part de clé. Les deux parties calculent alors le même secret partagé (ECDHE), dont elles dérivent les clés de session avec la fonction HKDF.
3. Tout ce qui suit est chiffré. Le serveur envoie son certificat et la chaîne, puis CertificateVerify : une signature, avec la clé privée du certificat, de tous les messages échangés jusque-là. C'est elle qui prouve que le serveur possède la clé privée et que personne n'a modifié la négociation. Puis Finished, un HMAC de la poignée de main.
4. Le client vérifie la chaîne de certificats, le nom, la signature CertificateVerify, puis envoie son Finished.
5. Les données applicatives (la requête HTTP, la réponse) circulent chiffrées et authentifiées avec la clé de session.

Pour une reconnexion rapide, TLS 1.3 propose la reprise de session et même le mode 0-RTT, où le client envoie des données dès son premier message. Ces données peuvent être rejouées par un attaquant : on ne l'autorise que pour des requêtes sans effet (lecture d'une page), jamais pour un paiement ou une modification.

La confidentialité persistante

En TLS 1.2 avec l'ancien échange de clés RSA, le client choisissait la clé de session et l'envoyait chiffrée avec la clé publique du serveur. Un attaquant qui enregistrait le trafic pendant des années, puis volait un jour la clé privée du serveur, pouvait tout déchiffrer rétroactivement.

Avec l'échange éphémère (ECDHE), obligatoire en TLS 1.3, les secrets Diffie-Hellman sont tirés pour chaque connexion puis effacés. La clé privée du certificat ne sert qu'à signer, jamais à chiffrer la clé de session. Voler la clé privée du serveur permet d'usurper son identité à l'avenir (d'où la révocation), mais pas de déchiffrer les conversations passées. C'est la confidentialité persistante (forward secrecy).

Les suites de chiffrement de TLS 1.3

Une suite de chiffrement nomme les algorithmes utilisés. En TLS 1.2, le nom les décrivait tous : ECDHE-RSA-AES256-GCM-SHA384 signifie échange ECDHE, authentification par certificat RSA, chiffrement AES-256 en mode GCM, et SHA-384 pour la dérivation. En TLS 1.3, l'échange est toujours (EC)DHE et l'authentification dépend du certificat : la suite ne nomme plus que le chiffrement authentifié et la fonction de hachage. La RFC 8446 en définit cinq :

Tester une connexion TLS

openssl s_client ouvre une connexion TLS et affiche ce qui a été négocié :

echo | openssl s_client -connect portail.helianthe.example:443 -servername portail.helianthe.example -brief
# CONNECTION ESTABLISHED
# Protocol version: TLSv1.3
# Ciphersuite: TLS_AES_256_GCM_SHA384
# Peer certificate: CN=portail.helianthe.example
# Hash used: SHA256
# Signature type: ecdsa_secp256r1_sha256
# Verification: OK
# Negotiated TLS1.3 group: X25519MLKEM768

Tu y lis la version (TLS 1.3), la suite (AES-256-GCM), le certificat présenté, la signature utilisée (ECDSA sur P-256), le résultat de la vérification de la chaîne et le groupe d'échange de clés (ici l'hybride post-quantique). D'autres outils :

Configurer HTTPS sur un serveur web

Une configuration nginx propre pour le portail : redirection permanente de HTTP vers HTTPS, TLS 1.2 et 1.3 seulement, en-tête HSTS. certbot remplit les chemins des certificats (chapitre 8).

server {
    listen 80;
    server_name portail.helianthe.example;
    return 301 https://$host$request_uri;          # tout le trafic HTTP part vers HTTPS
}

server {
    listen 443 ssl;
    http2 on;
    server_name portail.helianthe.example;

    ssl_certificate     /etc/letsencrypt/live/portail.helianthe.example/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/portail.helianthe.example/privkey.pem;
    ssl_protocols TLSv1.2 TLSv1.3;                  # ni SSL, ni TLS 1.0, ni TLS 1.1

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
}

Le fichier fullchain.pem contient le certificat du serveur et l'intermédiaire : sans l'intermédiaire, certains clients ne peuvent pas remonter la chaîne. Pour Apache, les directives équivalentes sont SSLEngine on, SSLCertificateFile, SSLCertificateKeyFile et SSLProtocol -all +TLSv1.2 +TLSv1.3. Pour choisir les suites, pars des profils du générateur de configuration de Mozilla (profil « intermédiaire » pour un site public) et des recommandations de l'ANSSI sur TLS.

HSTS (HTTP Strict Transport Security, RFC 6797) indique au navigateur de n'utiliser que HTTPS pour ce domaine pendant la durée max-age (ici deux ans), même si l'utilisateur tape http://. Sans HSTS, la toute première requête part en HTTP, et un attaquant sur le réseau peut l'intercepter et maintenir la victime en HTTP (attaque de rétrogradation, dite SSL stripping). Deux autres réglages vont avec : les cookies de session marqués Secure (jamais envoyés en HTTP) et HttpOnly, et l'absence de contenu mixte (une page HTTPS qui charge un script en HTTP perd sa protection ; les navigateurs bloquent ces ressources).

TLS partout : courriel, annuaires, bases de données

TLS ne sert pas qu'au web. Tous les protocoles qui transportent des identifiants ou des données personnelles doivent passer dans TLS, ou être remplacés par une version chiffrée :

STARTTLS démarre une connexion en clair puis la fait passer en TLS ; un attaquant peut supprimer l'annonce de STARTTLS et laisser la connexion en clair. Le TLS implicite (port 465 pour la soumission de courriel, 993 pour IMAPS) chiffre dès le début et doit être préféré. Pour MySQL, le cours SQL montre comment exiger TLS (require_secure_transport = ON).

HTTPS derrière un répartiteur de charge : terminaison TLS ou pass-through

Quand plusieurs serveurs web se partagent le trafic derrière un répartiteur de charge (HAProxy, nginx, l'équilibreur d'un fournisseur cloud), il faut décider où se termine la connexion TLS, c'est-à-dire quelle machine détient le certificat et sa clé privée, et déchiffre les requêtes.

Dans HAProxy, la terminaison se configure dans un frontend en mode http avec bind *:443 ssl crt /etc/haproxy/certs/site.pem ; le ré-chiffrement ajoute ssl verify required ca-file /etc/haproxy/ca-interne.pem sur chaque ligne server ; le pass-through utilise un frontend en mode tcp, sans le mot-clé ssl.

Pour un site ouvert au public, le certificat présenté aux visiteurs doit venir d'une autorité reconnue par les navigateurs : un certificat d'autorité interne ou autosigné provoque une alerte chez chaque visiteur, et des utilisateurs habitués à cliquer sur « Continuer » ne verront plus la différence avec une vraie attaque de l'homme du milieu. Entre le répartiteur et les serveurs, dans le réseau de l'organisation, un certificat d'autorité interne suffit.

L'inspection TLS en entreprise

Le chiffrement empêche aussi le pare-feu, l'antivirus de passerelle et le détecteur d'intrusion de voir ce qui entre et sort : un logiciel malveillant téléchargé ou une exfiltration de données passent dans le tunnel. Certaines organisations installent donc un proxy qui déchiffre le trafic HTTPS : il établit la connexion TLS avec le site à la place du poste, puis présente au poste un certificat généré à la volée, signé par une autorité interne déployée sur tous les postes gérés.

C'est techniquement une attaque de l'homme du milieu, autorisée et maîtrisée. Elle impose des précautions, que détaillent les recommandations de l'ANSSI sur l'analyse des flux HTTPS : informer les salariés (charte informatique, consultation du CSE), exclure les sites de santé, de banque et les services publics personnels, protéger les journaux du proxy, et sécuriser la clé de l'autorité qui signe les faux certificats, car elle peut usurper n'importe quel site auprès des postes de l'organisation.

À l'E7 : comment la notion est demandée

• Justifier HTTPS. Un sujet SLAM de la session 2025 (cas Kirassur) : une API reçoit une clé d'accès dans l'adresse ; il faut expliquer l'événement redouté en HTTP (l'interception de la clé par un tiers sur le réseau, puis son utilisation frauduleuse) et comment HTTPS en protège (chiffrement des échanges, y compris l'URL, après authentification du serveur par son certificat). Puis expliquer pourquoi, malgré HTTPS, on ne renvoie pas cette clé à l'assuré : HTTPS protège le transport, pas ce que le destinataire fait de la clé ni les endroits où elle reste écrite (historique, journaux, poste partagé). Le moindre privilège impose de donner à chacun un jeton personnel et limité dans le temps.
• Le portail captif. Le sujet SISR 2025 (cas Blanca) fait écrire les règles qui redirigent le trafic HTTP et HTTPS des invités vers la page d'authentification du portail captif, présentée en HTTPS avec un certificat d'autorité interne. Intercepter une connexion HTTPS pour la rediriger provoque un avertissement de certificat : c'est le comportement normal d'un navigateur face à une interception.
• Repérer un protocole non chiffré. Le même sujet signale dans une capture de trames un partage de fichiers en SMB version 2, « non chiffré » : la réponse attendue propose de passer à SMB 3 avec chiffrement, comme on remplace Telnet par SSH ou FTP par SFTP.
• Déchiffrer HTTPS sur le pare-feu. Le sujet SISR 2024 (cas Clinique Martin) consacre une mission entière à l'inspection TLS décrite plus haut : expliquer pourquoi HTTPS complique la lutte contre les rançongiciels (le pare-feu, l'antivirus et la détection d'intrusion ne voient ni les téléchargements malveillants ni les exfiltrations qui passent dans le tunnel) ; schématiser le proxy SSL d'un pare-feu Stormshield en montrant les zones chiffrées (deux connexions TLS) et la zone en clair (dans le pare-feu) ; expliquer pourquoi une inspection sur le flux HTTPS exige une règle de déchiffrement préalable ; peser avantages et inconvénients à l'aide des recommandations de l'ANSSI ; diagnostiquer l'erreur de certificat d'un poste qui ne connaît pas l'autorité du proxy (remède : déployer son certificat racine sur les postes, par stratégie de groupe) ; citer les obligations envers les salariés et la CNIL. Le corrigé du sujet SISR 2024 Clinique Martin détaille chaque réponse.
• Terminaison TLS sur un répartiteur. Le sujet SISR 2023 (cas ville du Parc) demande pourquoi une mairie doit utiliser, avec ses administrés, un certificat TLS issu d'une autorité publique, puis, pour chacune des deux stratégies décrites (terminaison TLS et pass-through sur des répartiteurs HAProxy), sur quelles machines installer les certificats et jusqu'où les communications sont chiffrées : c'est le tableau de la section précédente.
• Syslog sur TLS. Le sujet SISR 2025 de Nouvelle-Calédonie (cas Everest) fait expliquer en quoi les certificats assurent l'authentification, la confidentialité et l'intégrité des journaux envoyés au serveur central. Le certificat du serveur de journaux (et celui de chaque émetteur, si on l'exige) authentifie les extrémités ; la clé de session convenue pendant la poignée de main chiffre les messages ; chaque enregistrement TLS est protégé par un chiffrement authentifié (AES-GCM ou ChaCha20-Poly1305), qui détecte toute modification.

Pour aller plus loin. Le proxy qui déchiffre le trafic HTTPS des salariés, ses règles d'exclusion et son cadre légal sont expliqués dans le chapitre Proxy, filtrage web et inspection TLS du cours Cybersécurité des infrastructures.

Exercices

Protocol version: TLSv1.2
Ciphersuite: ECDHE-RSA-AES256-GCM-SHA384
Peer certificate: CN=mail.helianthe.lan
Verification error: unable to get local issuer certificate

server {
    listen 80;
    listen 443 ssl;
    server_name portail.helianthe.example;
    ssl_certificate     /etc/ssl/portail.crt;
    ssl_certificate_key /etc/ssl/portail.key;
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
}