Sécuriser un canal: TLS, HTTPS et mTLS

Sécuriser un canal: TLS, HTTPS et mTLS

TLS (Transport Layer Security) est sans doute le protocole cryptographique le plus utilisé au monde, et l’un des plus mal compris par ceux qui le déploient. Il assemble presque toutes les briques vues ailleurs dans ce parcours : certificats, échange de clés, dérivation, chiffrement authentifié, et une bonne dose d’exploitation. Ce chapitre le traite comme un cas d’intégration complet : ce que le canal garantit, comment il est construit, ce que TLS 1.3 a changé, et ce qui casse en production, c’est-à-dire surtout des dates.

Explication de la marmotte

Envoyer une information sur internet revient à la confier à une longue chaîne d’intermédiaires inconnus. Le canal sécurisé fonctionne comme un transporteur blindé qui vérifie d’abord l’identité du destinataire, puis garde le colis fermé tout le trajet. Il ne dit rien, en revanche, de l’honnêteté de celui qui ouvre le colis à l’arrivée.

→ Lire l’explication complète de la marmotte

TortueTech

Ce que garantit un canal

Trois propriétés

Un canal TLS correctement établi fournit trois garanties. La confidentialité en transit : un observateur du réseau ne lit pas le contenu. L’intégrité : toute modification, suppression ou réordonnancement des données est détecté, et la connexion est coupée. L’authentification du serveur : le client a vérifié, par le certificat, qu’il parle à une entité qui détient la clé associée au nom demandé. L’authentification du client est optionnelle ; c’est le cas du mTLS (mutual TLS), traité plus bas.

Ce qu’il ne garantit pas

Le canal protège le trajet, pas les extrémités. Un serveur compromis reçoit des données parfaitement déchiffrées ; un poste infecté envoie des données parfaitement chiffrées à l’attaquant qui le pilote ; une injection SQL (Structured Query Language) traverse TLS sans encombre, puisqu’elle fait partie du contenu légitime. Confondre HTTPS (HTTP over TLS, HTTP désignant le Hypertext Transfer Protocol) et sécurité applicative est l’erreur la plus répandue, et le cadenas du navigateur l’entretient avec constance.

Certaines métadonnées restent visibles : adresses IP (Internet Protocol) et ports, volume et rythme des échanges, et, sans extension particulière, le nom du site demandé, transmis en clair dans l’extension SNI (Server Name Indication) du premier message. Le chiffrement cache le contenu, pas le fait de la conversation.

Architecture TLS

Une brève histoire

Le protocole s’est appelé SSL (Secure Sockets Layer) chez Netscape : SSL 2.0 en 1995, SSL 3.0 en 1996. L’IETF (Internet Engineering Task Force) l’a repris sous le nom TLS : 1.0 en 1999 (RFC 2246), 1.1 en 2006, 1.2 en 2008 (RFC 5246), 1.3 en 2018 (RFC 8446). SSL 3.0 a été déclaré obsolète en 2015 après l’attaque POODLE, TLS 1.0 et 1.1 en 2021 (RFC 8996). Parler de « certificat SSL » en 2026 relève donc de la tradition orale ; aucune version de SSL n’a lieu d’être activée.

Handshake, record et clés

TLS se compose de deux couches. Le handshake (poignée de main) négocie la version et les algorithmes, authentifie le serveur, et établit un secret partagé. Le record protocol découpe ensuite les données applicatives en enregistrements d’au plus 16 Ko de clair, les chiffre et les authentifie avec les clés de trafic dérivées du secret. Le record layer ne connaît rien du protocole applicatif qu’il transporte, HTTP, SMTP (Simple Mail Transfer Protocol) ou autre : il voit des octets, ce qui explique qu’il ne puisse rien contre une faille applicative.

Une suite cryptographique (ciphersuite) désigne la combinaison d’algorithmes utilisée. En TLS 1.2, elle fixe tout d’un bloc, par exemple TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 : échange ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), authentification RSA, chiffrement AES-128 en mode GCM (Galois/Counter Mode), SHA-256 pour la dérivation. En TLS 1.3, la suite ne désigne plus que l’AEAD (Authenticated Encryption with Associated Data) et la fonction de hachage : TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256 pour l’essentiel, l’échange de clés et la signature étant négociés séparément.

Le certificat présenté par le serveur lie son nom à sa clé publique ; sa vérification et ses pièges sont l’objet de Relier une clé à une identité. TLS dépend de la PKI (Public Key Infrastructure) sans se confondre avec elle : la PKI dit à qui appartient une clé, TLS utilise cette réponse pour établir un canal. Enfin, les clés de trafic peuvent être renouvelées en cours de connexion : TLS 1.3 prévoit un message KeyUpdate, utile pour les connexions longues qui approchent des limites d’usage d’une clé.

Atelier : comparer TLS 1.2 et TLS 1.3

Aspect	TLS 1.2	TLS 1.3
Allers-retours avant les données	2	1, ou 0 en reprise avec 0-RTT
Échange de clés	RSA statique ou (EC)DHE	(EC)DHE uniquement
Confidentialité persistante	Selon la suite choisie	Toujours
Chiffrement	CBC, RC4 ou AEAD selon la suite	AEAD uniquement
Certificat du serveur	Transmis en clair	Chiffré
Renégociation	Possible	Supprimée

Le tableau résume l’essentiel : TLS 1.3 n’a pas tant ajouté que retiré. La compression, la renégociation, le transport de clé RSA, les modes CBC (Cipher Block Chaining) avec MAC (Message Authentication Code) avant chiffrement et RC4 ont disparu, chacun avec son attaque célèbre au passif.

TLS 1.3 en pratique

Forward secrecy par défaut

En TLS 1.2 avec échange RSA statique, le client chiffrait le secret de session avec la clé publique du serveur. Quiconque enregistrait le trafic et volait la clé privée des années plus tard déchiffrait tout. TLS 1.3 impose un échange Diffie-Hellman éphémère : la clé du certificat ne sert qu’à signer le handshake, et les secrets de session sont oubliés après usage. C’est la confidentialité persistante (forward secrecy) : la compromission ultérieure de la clé longue ne rend pas lisibles les sessions passées. Elle ne protège pas les sessions futures, qui relèvent d’une autre propriété, la sécurité après compromission (post-compromise security), que fournissent par exemple les messageries à double cliquet, pas TLS.

Protection contre le downgrade

Un attaquant actif pourrait tenter de forcer une version plus ancienne. Deux mécanismes l’en empêchent. Le message Finished, qui clôt le handshake, authentifie toute la transcription : une modification des messages de négociation est détectée. Et un serveur TLS 1.3 contraint de négocier une version inférieure inscrit une valeur sentinelle dans les huit derniers octets de son aléa (DOWNGRD suivi de 01 pour TLS 1.2, de 00 pour les versions antérieures), qu’un client TLS 1.3 sait reconnaître.

Reprise de session et 0-RTT

Après une première connexion, le serveur peut remettre un ticket qui permet une reprise (resumption) par clé pré-partagée, sans repasser par la vérification du certificat. TLS 1.3 autorise même, dans ce cadre, l’envoi de données applicatives dès le premier message : le 0-RTT (zero round-trip time). Ces données précoces ne bénéficient pas de la protection contre le rejeu : un attaquant qui les capture peut les renvoyer au serveur. La RFC 8446 le dit sans détour. Le 0-RTT ne doit donc transporter que des requêtes idempotentes, un GET de page statique, jamais un virement ; de nombreux serveurs le laissent désactivé par défaut, et c’est un choix raisonnable.

ECH et channel bindings

L’extension ECH (Encrypted ClientHello), normalisée à l’IETF, chiffre la partie sensible du premier message, dont le SNI, avec une clé publiée dans le DNS (Domain Name System). Elle ne cache le nom que si le client et le serveur la prennent en charge et si le site partage son point d’entrée avec d’autres ; son déploiement dépend des navigateurs et des hébergeurs, et l’adresse IP reste visible de toute façon.

Les channel bindings lient une authentification de niveau applicatif au canal TLS sous-jacent : le protocole applicatif inclut dans sa preuve une valeur exportée du canal, ce qui empêche un intermédiaire de relayer l’authentification sur une autre connexion. Pour TLS 1.3, la RFC 9266 définit le type tls-exporter, utilisé notamment par les variantes -PLUS de SCRAM (Salted Challenge Response Authentication Mechanism). Leur disponibilité dépend des bibliothèques et des protocoles applicatifs concernés.

Exploitation

Diagnostiquer une chaîne

openssl s_client -connect api.exemple.fr:443 -servername api.exemple.fr -tls1_3 </dev/null
openssl s_client -connect api.exemple.fr:443 -servername api.exemple.fr -tls1_1 </dev/null

La première commande doit afficher Protocol: TLSv1.3, la suite négociée et Verify return code: 0 (ok). La seconde doit échouer : un serveur qui accepte encore TLS 1.1 garde une porte ouverte pour des clients qui ne devraient plus exister. Activer trop de versions anciennes « pour la compatibilité » n’apporte de compatibilité qu’avec des attaques documentées. Des outils comme testssl.sh ou le script ssl-enum-ciphers de nmap automatisent l’inventaire des versions et suites acceptées, et les profils du générateur de configuration de Mozilla fournissent des points de départ maintenus. Le guide Migrer de TLS ancien vers moderne détaille la démarche.

mTLS sur un schéma d’architecture

Un exemple d’architecture : un répartiteur de charge public termine le TLS des navigateurs avec un certificat de la WebPKI, puis ouvre des connexions mTLS vers trois services internes. Chaque service possède un certificat court délivré par une autorité interne, identifiant le service et non la machine ; chaque service n’accepte que les identités qui doivent l’appeler, par exemple le service de paiement n’accepte que la passerelle et la facturation. Le mTLS authentifie des machines et des services : l’utilisateur final reste authentifié par l’application, et l’identité du service ne dit rien de la personne derrière la requête. Voir mTLS.

Journaux et secrets

Les journaux TLS doivent enregistrer la version, la suite, le nom demandé et l’identité du client en mTLS, jamais de matériel de clé. La variable SSLKEYLOGFILE, reconnue par de nombreux navigateurs et bibliothèques pour le débogage avec Wireshark, écrit les secrets de session en clair dans un fichier : utile sur un poste de développement, désastreuse si elle traîne dans une image de production. Les captures de paquets complètes, ou les journaux de débogage d’une bibliothèque TLS, posent le même problème.

Atelier : un certificat expiré

Lundi, 7 h 02 : l’API mobile renvoie des erreurs de handshake, le site web fonctionne. L’analyse montre que le certificat du sous-domaine de l’API a expiré à 2 h 00 UTC (Temps universel coordonné), son renouvellement ACME échouant depuis six semaines parce qu’une règle de pare-feu bloquait le défi http-01. Les alertes d’échec partaient vers une liste de diffusion supprimée. La correction immédiate est un renouvellement manuel ; la correction durable porte sur trois points : superviser la date d’expiration de chaque certificat servi, par exemple avec openssl x509 -checkend 2592000 qui échoue à moins de trente jours, alerter vers une équipe vivante, et tester la chaîne de renouvellement, pas seulement le certificat. Avec des durées de vie publiques qui raccourcissent jusqu’à 47 jours d’ici 2029, ne pas surveiller l’expiration revient à planifier la panne.

Ce qui casse vraiment

Les menaces se rangent en quatre familles. Une autorité compromise permet de présenter un certificat valide pour un nom usurpé : DigiNotar, en 2011, en reste l’exemple. Un serveur compromis livre sa clé et ses données. Un client compromis accepte ce qu’on lui fait accepter. Et les bugs d’implémentation frappent quelle que soit la qualité du protocole : Heartbleed, en 2014, permettait de lire la mémoire de serveurs OpenSSL, clés privées comprises. Le guide TLS expliqué complète ce panorama.

À ne pas confondre

TLS n’est pas la PKI : l’un établit un canal, l’autre dit à qui appartient une clé. Le mTLS n’est pas une authentification d’utilisateur. La confidentialité persistante protège le passé contre une compromission future ; la sécurité après compromission protège l’avenir après une compromission présente, et TLS ne la fournit pas. Enfin, le record layer n’est pas le protocole applicatif : il chiffre fidèlement une requête malveillante.

🐝 Ce qui arrive si on s’en passe

Sans canal chiffré et authentifié, tout équipement placé sur le trajet lit les identifiants et les cookies de session en clair, puis les rejoue ailleurs sans avoir à casser quoi que ce soit. Il peut aussi modifier les réponses au passage : un script injecté dans une page ou un lien de téléchargement remplacé arrivent chez l’utilisateur avec toutes les apparences de la source légitime. Sans authentification du serveur, même un canal chiffré mène droit à l’imposteur, qui relaie la conversation en la lisant. À l’intérieur du réseau, l’absence de mTLS entre services laisse n’importe quelle machine se présenter comme un appelant légitime, et les journaux enregistrent fidèlement une identité que rien n’a vérifiée.

🦫 Explication de la marmotte 🍫

Quand un navigateur se connecte à un site protégé, les deux machines commencent par une phase de négociation, appelée poignée de main. Elles se mettent d’accord sur la version du protocole et sur les méthodes de chiffrement, puis le serveur présente un certificat : un document signé par une autorité reconnue, qui relie son nom à sa clé publique. Le navigateur vérifie cette signature, le nom et la date d’expiration. Les deux côtés calculent ensuite des clés temporaires, jetées après la session : même si la clé du serveur est volée plus tard, les échanges passés restent illisibles. Après la négociation, chaque morceau de données est chiffré et accompagné d’un code qui révèle toute modification. La version récente du protocole a supprimé d’anciennes méthodes faibles et détecte qu’un attaquant tente d’imposer une version plus ancienne. Elle permet aussi de reprendre une session, et même d’envoyer des données dès le premier message, au risque qu’elles soient rejouées. Dans la variante mutuelle, le client présente lui aussi un certificat, ce qui identifie une machine mais pas une personne. Le canal ne protège que le trajet : un serveur piraté, un client infecté ou une faille de l’application restent hors de sa portée, et certaines informations peuvent rester visibles. En exploitation, un certificat expiré coupe le service.

À lire aussi

• La poignée de main TLS 1.3 en une pageClientHello, ServerHello, dérivation des clés, certificat chiffré et Finished : la poignée de main TLS 1.3 (RFC 8446) animée en six étapes, avec le 0-RTT et ses risques de rejeu.
• Messageries, courrier sécurisé et groupes chiffrésTraiter le chiffrement de bout en bout comme un problème de protocole, de clés et de groupes, en intégrant courrier historique, PGP, MLS et limites de métadonnées.
• Établir une clé : Diffie-Hellman, KEM et HPKEÉtablir une clé sans canal sécurisé : Diffie-Hellman pour fabriquer le secret commun, KEM pour l'interface encapsuler/décapsuler, HPKE (RFC 9180) pour assembler KEM, KDF et AEAD.
• Principes de sécurité, identité et cryptographie utile au réseauPoser les bases de sécurité réseau : menaces, propriétés, identité, authentification, autorisation, chiffrement, non-répudiation et limites.

Pages voisines

La citent

• Frontières : cacher, coder, compresser et détruire
• JWE : chiffrer un jeton JSON sans se tromper
• La poignée de main TLS 1.3 en une page
• Récolter maintenant, déchiffrer plus tard
• Vérifier un protocole cryptographique avec Tamarin ou ProVerif

Sécuriser un canal: TLS, HTTPS et mTLS

Elle cite

• ⇄Lien dans les deux sens :Comprendre TLS : mécanismes, garanties et limites
• Migrer TLS legacy sans casser les clients anciens
• Relier une clé à une identité: certificats et PKI
• Certificats de courte durée
• mTLS
• Sécuriser un load balancer cloud et la terminaison TLS
• Wireshark, capturer et lire des trames réseau avec filtres et TLS

⇄ : les deux pages se citent l’une l’autre.