Comment HTTPS et TLS fonctionnent réellement : guide étape par étape

Vous avez probablement déjà vu l'icône de cadenas dans votre navigateur et supposé que votre connexion était sécurisée. Mais que se passe-t-il réellement lorsque vous visitez un site HTTPS ? Comment votre navigateur sait-il qu'il parle au véritable serveur et non à un imposteur ? Et pourquoi TLS ralentit-il parfois votre site ?

Dans ce guide, nous allons démystifier HTTPS et TLS en détaillant le handshake étape par étape. Vous apprendrez les rôles des certificats, du chiffrement symétrique et asymétrique, et comment vérifier et optimiser TLS dans vos propres projets.

Ce que HTTPS et TLS font réellement

HTTPS est HTTP superposé à TLS (Transport Layer Security). TLS offre trois garanties :

• Confidentialité : Les données sont chiffrées afin que les oreilles indiscrètes ne puissent pas les lire.
• Intégrité : Les données ne peuvent pas être modifiées en transit sans être détectées.
• Authentification : Vous parlez au serveur légitime, pas à un attaquant.

Sans TLS, le trafic HTTP est envoyé en clair. Quiconque sur le chemin réseau (points d'accès Wi-Fi, FAI, routeurs compromis) peut le lire ou le modifier. TLS résout ce problème en établissant un canal sécurisé avant que toute donnée HTTP ne soit échangée.

Le handshake TLS : étape par étape

Le handshake est là où la magie opère. C'est une négociation qui établit des clés partagées et vérifie les identités. Voici le flux simplifié pour TLS 1.2 et 1.3 (les deux versions que vous rencontrerez aujourd'hui).

Étape 1 : Client Hello

Le client (navigateur) envoie un message ClientHello contenant :

• Les versions TLS prises en charge (par exemple, TLS 1.3, TLS 1.2)
• Les suites de chiffrement prises en charge (combinaisons d'algorithmes)
• Une chaîne d'octets aléatoires (client random)
• Pour TLS 1.3, une part de clé pour l'échange Diffie-Hellman

Étape 2 : Server Hello et certificat

Le serveur répond avec un ServerHello (version choisie, suite de chiffrement, server random) et son certificat. Le certificat contient la clé publique du serveur et est signé par une autorité de certification (CA).

Le client vérifie le certificat : est-il expiré ? Est-il émis par une CA de confiance ? Le domaine correspond-il ? Sinon, le navigateur affiche un avertissement.

Étape 3 : Échange de clés

En utilisant la clé publique du serveur (ou les paramètres Diffie-Hellman), le client et le serveur dérivent un pre-master secret partagé. Dans TLS 1.3, cela se fait avec Diffie-Hellman éphémère (ECDHE), offrant la confidentialité persistante (forward secrecy) : même si la clé privée du serveur est compromise plus tard, les sessions passées restent sécurisées.

Étape 4 : Finished

Les deux parties envoient un message Finished chiffré avec les clés nouvellement dérivées. Si le déchiffrement réussit, le handshake est terminé. À partir de là, toutes les données applicatives (HTTP) sont chiffrées avec un chiffrement symétrique (par exemple, AES-GCM ou ChaCha20-Poly1305).

Améliorations de TLS 1.3

TLS 1.3 réduit le handshake à un aller-retour (1-RTT) et prend en charge la reprise 0-RTT pour les visiteurs récurrents. Il supprime également les algorithmes obsolètes, le rendant plus rapide et plus sécurisé. La plupart des navigateurs et serveurs modernes prennent en charge TLS 1.3.

Chiffrement symétrique vs asymétrique dans TLS

TLS utilise les deux types de chiffrement pour de bonnes raisons :

• Chiffrement asymétrique (à clé publique) : Utilisé pendant le handshake pour authentifier le serveur et échanger des clés en toute sécurité. Il est coûteux en calcul mais résout le problème de distribution des clés.
• Chiffrement symétrique : Utilisé pour le transfert de données en masse après le handshake. Il est rapide et efficace.

Cette approche hybride vous offre la sécurité de la cryptographie à clé publique avec les performances des chiffrements symétriques.

Certificats : ancres de confiance

Un certificat lie une clé publique à un nom de domaine et est signé par une CA. Les navigateurs et systèmes d'exploitation sont livrés avec un magasin de CA racines de confiance. Lorsqu'un serveur présente son certificat, le client construit une chaîne de confiance jusqu'à une racine de confiance.

Les certificats ont une durée de vie limitée (souvent 90 jours avec Let's Encrypt). Les certificats expirés provoquent des erreurs de navigateur, alors automatisez le renouvellement.

Pratique : inspecter TLS avec OpenSSL

Vous pouvez inspecter la configuration TLS d'un serveur à l'aide de l'outil en ligne de commande openssl. Cela aide à déboguer les échecs de handshake ou à vérifier les suites de chiffrement.

openssl s_client -connect example.com:443 -servername example.com -tls1_3

Cela se connecte au serveur et affiche la chaîne de certificats, le chiffrement négocié et les détails de la session. Recherchez Verify return code: 0 (ok) pour confirmer que le certificat est valide.

Pour vérifier l'expiration du certificat :

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Pièges TLS courants et comment les éviter

• Certificats expirés : Mettez en place un renouvellement automatisé et une surveillance. Utilisez des outils comme Certbot pour Let's Encrypt.
• Contenu mixte : Le chargement de ressources HTTP sur une page HTTPS compromet la sécurité. Utilisez des URL relatives ou assurez-vous que toutes les ressources sont en HTTPS.
• Suites de chiffrement faibles : Désactivez les protocoles obsolètes (TLS 1.0, 1.1) et les chiffrements faibles (RC4, 3DES). Activez TLS 1.3.
• HSTS manquant : Ajoutez l'en-tête Strict-Transport-Security pour forcer HTTPS lors des visites futures.
• Chaînes de certificats incomplètes : Certains serveurs oublient d'inclure les certificats intermédiaires, provoquant des erreurs sur certains clients. Utilisez SSL Labs pour tester.

Optimiser les performances TLS

TLS ajoute de la latence en raison du handshake. Voici comment la minimiser :

• Activez TLS 1.3, qui a un handshake plus rapide.
• Utilisez la reprise de session (session tickets ou clés pré-partagées) pour éviter les handshakes complets pour les visiteurs récurrents.
• Activez l'agrafage OCSP (OCSP stapling) pour réduire la latence de validation des certificats.
• Utilisez un CDN avec terminaison TLS en périphérie pour réduire les temps d'aller-retour.
• Gardez les certificats petits (utilisez ECDSA au lieu de RSA lorsque c'est possible).

FAQ

Quelle est la différence entre HTTPS et TLS ?

HTTPS est la version sécurisée de HTTP, et TLS est le protocole cryptographique qui fournit la sécurité. HTTPS utilise TLS pour chiffrer et authentifier la connexion.

Comment TLS assure-t-il la confidentialité persistante (forward secrecy) ?

La confidentialité persistante garantit que même si la clé privée du serveur est compromise, les clés de session passées ne peuvent pas être dérivées. Elle est obtenue en utilisant un échange de clés Diffie-Hellman éphémère (ECDHE) dans TLS 1.3 et les configurations modernes de TLS 1.2.

Pourquoi vois-je des erreurs de certificat sur certains sites ?

Les erreurs de certificat signifient généralement que le certificat est expiré, auto-signé, émis pour un domaine différent, ou que la chaîne de certificats est incomplète. Les navigateurs rejettent ces certificats pour vous protéger contre les attaques de l'homme du milieu (man-in-the-middle).

Lorsque vous avez besoin d'inspecter ou de déboguer des connexions TLS, des outils comme Timestamp Converter peuvent vous aider à décoder les périodes de validité des certificats et à déboguer les problèmes liés au temps.