Qu'est-ce que SSL/TLS ? Le protocole qui sécurise le web

SSL/TLS expliqué simplement : fonctionnement du handshake, certificats, différences entre versions et commandes pour vérifier une connexion chiffrée.

Équipe Dig TraceÉquipe Dig Trace· Équipe d'Ingénierie Réseau5 min de lecture
Qu'est-ce que SSL/TLS ? Le protocole qui sécurise le web

SSL/TLS est le protocole cryptographique qui protège les échanges entre votre navigateur et un serveur web. Il chiffre les données, authentifie le serveur et garantit que rien n'a été modifié en route. C'est lui qui rend possible le HTTPS, symbolisé par le cadenas dans la barre d'adresse.

Le terme recouvre en réalité deux protocoles. SSL (Secure Sockets Layer) est l'ancêtre, développé par Netscape dans les années 1990. TLS (Transport Layer Security) est son successeur, aujourd'hui standard. Quand un site affiche un « certificat SSL », il utilise en pratique TLS.

SSL et TLS : quelle différence ?

SSL a connu trois versions publiques, de SSL 2.0 à SSL 3.0. Toutes présentent des failles documentées, comme POODLE ou BEAST, et sont bloquées par les navigateurs modernes. Garder SSL 3.0 actif sur un serveur revient à laisser une porte déverrouillée.

TLS 1.0 a remplacé SSL 3.0 en 1999. Le protocole a ensuite évolué jusqu'à TLS 1.3, publié en 2018 sous la RFC 8446. Seuls TLS 1.2 et TLS 1.3 restent recommandés. TLS 1.0 et 1.1 sont officiellement dépréciés depuis 2021.

Les améliorations sont concrètes. TLS remplace l'ancien MAC par HMAC, plus sûr. TLS 1.3 impose des suites AEAD comme AES-GCM ou ChaCha20-Poly1305 et supprime les algorithmes fragiles (RC4, DES, SHA-1). La confidentialité persistante (forward secrecy) devient obligatoire, ce qui protège les sessions passées même si la clé privée du serveur fuit un jour.

Comment fonctionne une connexion TLS ?

Tout commence par la poignée de main (handshake). Le client envoie un message ClientHello listant les versions TLS et les suites cryptographiques qu'il accepte. Le serveur répond avec un ServerHello et présente son certificat, au format X.509, qui contient sa clé publique.

Le client vérifie alors ce certificat. Il remonte la chaîne de confiance jusqu'à une autorité de certification (CA) racine connue de son navigateur. Si le domaine correspond et que la chaîne est valide, l'identité du serveur est confirmée. Le déroulé complet de cet échange est bien détaillé dans ce guide IONOS sur TLS.

Vient ensuite l'échange de clés. Client et serveur conviennent d'un secret partagé, généralement via Diffie-Hellman éphémère (ECDHE). Ce secret permet de dériver une clé de session symétrique unique. Le chiffrement asymétrique ne sert qu'au début, car il est lent. Ensuite, tout passe en symétrique, bien plus rapide.

Chaque paquet est aussi authentifié. Un code AEAD ou HMAC détecte la moindre modification des données en transit. Une fois la session établie, le HTTP circule chiffré sur le port 443. C'est le HTTPS. Les reconnexions peuvent être accélérées grâce à la reprise de session, voire au mode 0-RTT de TLS 1.3.

TLS 1.3 : qu'est-ce qui change ?

La version 1.3 simplifie et accélère. La poignée de main ne demande plus qu'un aller-retour (1-RTT) contre deux pour TLS 1.2, ce qui réduit la latence de chargement des pages. Les reconnexions peuvent même s'effectuer en 0-RTT.

Côté sécurité, la liste des algorithmes autorisés est drastiquement réduite. Impossible de configurer un chiffrement faible par erreur. La forward secrecy est systématique et une grande partie du handshake est désormais chiffrée, ce qui complique la surveillance passive. Comme le résume l'explication de Cloudflare, TLS 1.3 offre plus de sécurité avec moins de configuration.

Vérifier TLS en pratique

Pas besoin d'outils complexes pour inspecter une connexion. La commande openssl suffit.

# Ouvrir une connexion TLS et afficher le certificat du serveur
openssl s_client -connect digtrace.net:443 -servername digtrace.net

La sortie confirme la version négociée et le chiffrement retenu.

New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 2048 bit
Verify return code: 0 (ok)

Pour tester si un serveur accepte encore une version obsolète, forcez-la explicitement.

# Un serveur bien configuré doit rejeter TLS 1.1
openssl s_client -connect digtrace.net:443 -tls1_1

Si la configuration est correcte, la commande échoue avec une erreur du type tlsv1 alert protocol version. Dans le navigateur, un clic sur le cadenas affiche le certificat, son émetteur et sa date d'expiration.

Attention : activer SSLv3 ou TLS 1.0 « pour la compatibilité » expose le serveur à des attaques connues. Les navigateurs modernes les bloquent déjà.

Pourquoi TLS compte-t-il ?

Pour l'internaute, TLS protège les mots de passe, les paiements et les données personnelles contre l'écoute sur les réseaux publics. Un site marqué « Non sécurisé » mérite la méfiance, surtout s'il demande une saisie sensible.

Pour les administrateurs, les règles sont simples. Activer TLS 1.3 en priorité et TLS 1.2 en repli. Désactiver SSLv3, TLS 1.0 et 1.1. Automatiser le renouvellement des certificats, par exemple avec Let's Encrypt, et compléter avec HSTS pour bloquer les attaques de downgrade. Un certificat expiré ou une chaîne incomplète suffit à faire fuir des visiteurs.

TLS s'inscrit dans la pile réseau aux côtés des autres protocoles fondamentaux. Comprendre comment le DNS traduit un domaine en adresse, ou comment une adresse IP achemine les paquets, aide à situer TLS à sa juste place. Nos guides sur le DNS et les adresses IP complètent utilement ce panorama.

La suite est déjà en marche. Des extensions post-quantiques sont en cours d'intégration pour préparer TLS aux ordinateurs quantiques. Le protocole qui sécurise le web depuis trente ans continue d'évoluer, discrètement mais sans relâche.