Comment HTTPS et TLS fonctionnent vraiment : guide pratique

Vous tapez une URL, appuyez sur Entrée, et la page se charge. L'icône de cadenas indique que la connexion est sécurisée, mais que se passe-t-il réellement entre votre navigateur et le serveur ? Si vous êtes développeur, comprendre HTTPS et TLS n'est pas seulement théorique : cela affecte la configuration de vos serveurs, le débogage des erreurs de connexion et la protection des données utilisateur.

Ce guide décompose le handshake TLS, les couches de chiffrement et la validation des certificats en termes simples. Vous verrez comment HTTPS fonctionne réellement et vous découvrirez des conseils pratiques pour vos propres projets.

Ce que sont réellement HTTPS et TLS

HTTPS est HTTP sur TLS. TLS (Transport Layer Security) est le protocole cryptographique qui chiffre les données en transit. Lorsque vous visitez une URL HTTPS, votre navigateur et le serveur effectuent un handshake TLS pour convenir de clés de chiffrement avant tout échange de données HTTP.

TLS a remplacé SSL (Secure Sockets Layer) il y a des années, mais les termes sont souvent utilisés de manière interchangeable. Les navigateurs modernes prennent en charge TLS 1.2 et TLS 1.3 ; les versions plus anciennes sont obsolètes en raison de vulnérabilités connues.

Le handshake TLS : étape par étape

Le handshake établit un canal sécurisé. Voici ce qui se passe lors d'un handshake TLS 1.2 typique (TLS 1.3 simplifie encore cela) :

1. Client Hello : Le navigateur envoie une liste de suites de chiffrement prises en charge, les versions TLS et une valeur aléatoire (client random).
2. Server Hello : Le serveur choisit une suite de chiffrement, envoie sa propre valeur aléatoire (server random) et présente son certificat SSL/TLS.
3. Vérification du certificat : Le navigateur vérifie le certificat auprès des autorités de certification racines de confiance, valide le nom de domaine et contrôle l'expiration.
4. Échange de clés : À l'aide de la clé publique du certificat, le client chiffre un pré-secret maître et l'envoie au serveur. Les deux parties dérivent les mêmes clés de session.
5. Finished : Les deux parties envoient un message Finished chiffré avec les nouvelles clés de session, confirmant la réussite du handshake.

Dans TLS 1.3, le handshake est réduit à un aller-retour (1-RTT) et prend en charge la reprise 0-RTT pour les connexions répétées, améliorant la latence.

Chiffrement : symétrique et asymétrique

TLS utilise les deux types de chiffrement :

• Le chiffrement asymétrique (par exemple RSA, ECDHE) est utilisé pendant le handshake pour échanger les clés de manière sécurisée. Il est lent mais résout le problème de distribution des clés.
• Le chiffrement symétrique (par exemple AES-GCM, ChaCha20-Poly1305) est utilisé pour le transfert massif de données après le handshake. Il est rapide et efficace.

Les clés de session dérivées pendant le handshake sont des clés symétriques. Elles garantissent que même si quelqu'un capture le trafic chiffré, il ne peut pas le déchiffrer sans les clés.

Validation des certificats : faire confiance mais vérifier

Les certificats sont délivrés par des autorités de certification (CA). Les navigateurs et les systèmes d'exploitation sont livrés avec une liste d'autorités de certification racines de confiance. Lorsqu'un serveur présente un certificat, le navigateur vérifie :

• Le certificat est signé par une CA de confiance (directement ou via une CA intermédiaire).
• Le nom de domaine du certificat correspond à l'hôte demandé.
• Le certificat est dans sa période de validité.
• Le certificat n'a pas été révoqué (via CRL ou OCSP).

Si l'une de ces vérifications échoue, le navigateur affiche un avertissement. En tant que développeur, vous pouvez utiliser des outils comme openssl s_client pour inspecter les certificats et déboguer les problèmes de chaîne.

Mauvaises configurations TLS courantes et comment les corriger

Utilisez des vérificateurs SSL en ligne ou des outils en ligne de commande pour auditer régulièrement votre configuration.

Conseils pratiques pour les développeurs

• Activez HSTS : Ajoutez l'en-tête Strict-Transport-Security pour forcer les navigateurs à utiliser HTTPS lors des visites futures.
• Utilisez TLS 1.3 : Il est plus rapide et plus sécurisé. La plupart des serveurs modernes le prennent en charge ; configurez votre serveur pour le préférer.
• Automatisez la gestion des certificats : Des outils comme Certbot peuvent obtenir et renouveler automatiquement les certificats.
• Testez avec openssl : Exécutez openssl s_client -connect example.com:443 -servername example.com pour inspecter le handshake et la chaîne de certificats.

Voici un extrait de configuration Nginx pour activer des paramètres TLS modernes :

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';
    ssl_prefer_server_ciphers off;

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

Cette configuration active TLS 1.2 et 1.3, utilise des chiffrements forts et définit HSTS.

FAQ

Quelle est la différence entre HTTPS et TLS ?

HTTPS est HTTP superposé à TLS. TLS est le protocole qui fournit le chiffrement et l'authentification. Ainsi, HTTPS est la version sécurisée de HTTP, propulsée par TLS.

Comment le handshake TLS établit-il une clé partagée ?

Le client et le serveur utilisent la cryptographie asymétrique (comme ECDHE) pour convenir d'un secret partagé sans le transmettre directement. Ils dérivent ensuite des clés de session symétriques à partir de ce secret pour chiffrer les données.

Pourquoi les certificats expirent-ils ?

L'expiration limite les dommages si une clé privée est compromise et encourage l'automatisation du renouvellement. Les certificats à courte durée de vie sont une bonne pratique de sécurité.

Prêt à inspecter votre propre configuration TLS ? Utilisez l'analyseur de logs Nginx de TryQuickToolBox pour repérer les erreurs TLS et les échecs de handshake dans vos logs serveur.