TryQuickToolBox

Comment HTTPS et TLS fonctionnent réellement : handshake et certificats

Security2026-10-30TryQuickToolBox

Pourquoi HTTPS est important (et pourquoi c'est mal compris)

Vous avez probablement vu l'icône de cadenas dans votre navigateur et supposé que le site est « sécurisé ». Mais qu'est-ce que cela signifie vraiment ? HTTPS ne concerne pas seulement le chiffrement ; il s'agit d'identité, d'intégrité et de confiance. Beaucoup de développeurs traitent TLS comme une boîte noire—configurez-le une fois et oubliez-le. Cela conduit à des mauvaises configurations, des certificats expirés et des suites de chiffrement vulnérables.

Dans cet article, nous allons décomposer comment HTTPS et TLS fonctionnent réellement, du handshake à la validation des certificats, et vous montrer comment le configurer correctement. Pas de blabla, juste des connaissances pratiques que vous pouvez appliquer dès aujourd'hui.

Le handshake TLS : ce qui se passe avant le premier octet

Lorsqu'un client (navigateur) se connecte à un serveur via HTTPS, ils effectuent un handshake TLS. Cela établit un canal sécurisé. Voici une version simplifiée (TLS 1.3) :

  1. Client Hello : Le client envoie les suites de chiffrement prises en charge, une valeur aléatoire et une part de clé (pour l'échange de clés).
  2. Server Hello : Le serveur choisit une suite de chiffrement, envoie sa propre valeur aléatoire et sa part de clé, et présente sa chaîne de certificats.
  3. Authentification : Le client vérifie le certificat du serveur auprès des AC de confiance et vérifie le nom d'hôte.
  4. Dérivation de clé : Les deux parties calculent le secret partagé en utilisant ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).
  5. Finished : Les deux envoient des messages « Finished » chiffrés pour confirmer le handshake.

Après cela, les données applicatives sont chiffrées avec des clés symétriques. TLS 1.3 réduit les allers-retours à un seul, améliorant la latence.

Échange de clés : ECDHE vs RSA

Les anciennes versions de TLS utilisaient l'échange de clés RSA, qui manque de confidentialité persistante. Si la clé privée du serveur est compromise, le trafic passé peut être déchiffré. Les configurations modernes utilisent ECDHE, qui offre une confidentialité persistante—chaque session a des clés uniques.

# Exemple : Vérifier les algorithmes d'échange de clés pris en charge
openssl s_client -connect example.com:443 -cipher 'ECDHE'

Certificats : les ancres de confiance

Un certificat lie une clé publique à une identité (nom de domaine). Il est signé par une autorité de certification (AC) à laquelle le client fait confiance. Les navigateurs sont livrés avec un magasin d'AC racines de confiance.

Lorsque vous visitez un site, le serveur envoie une chaîne : certificat feuille (pour votre domaine) → AC intermédiaire → AC racine. Le client vérifie chaque signature jusqu'à une racine de confiance.

Types de certificats

Étapes de validation des certificats

Les navigateurs vérifient :

Si une vérification échoue, vous obtenez un avertissement. Ne contournez jamais ces avertissements en production.

Configuration de HTTPS sur votre serveur

Regardons une configuration Nginx typique pour HTTPS avec 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:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers off;

    # HSTS (à utiliser avec prudence)
    add_header Strict-Transport-Security "max-age=63072000" always;
}

Remarques :

Obtention de certificats avec Let's Encrypt

Let's Encrypt fournit des certificats DV gratuits. Utilisez Certbot pour automatiser l'émission et le renouvellement :

sudo certbot --nginx -d example.com -d www.example.com

Certbot modifie votre configuration Nginx et met en place une tâche cron pour le renouvellement. Testez toujours le renouvellement avec --dry-run.

Pièges courants et comment les éviter

Tester votre configuration HTTPS

Utilisez des outils en ligne comme SSL Labs ou des outils en ligne de commande pour vérifier votre configuration.

# Vérifier les détails du certificat
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -text

# Tester la prise en charge de TLS 1.3
openssl s_client -connect example.com:443 -tls1_3

Recherchez :

FAQ

Quelle est la différence entre TLS et SSL ?

SSL est le prédécesseur de TLS. TLS 1.0 était essentiellement SSL 3.1. Aujourd'hui, « SSL » est souvent utilisé familièrement, mais vous devriez toujours utiliser TLS 1.2 ou 1.3.

Ai-je besoin d'un certificat payant pour HTTPS ?

Non. Les certificats DV gratuits de Let's Encrypt sont approuvés par tous les principaux navigateurs et offrent le même chiffrement que les payants. Les certificats payants offrent des garanties et un support, mais le chiffrement est identique.

Comment HTTPS affecte-t-il les performances ?

TLS ajoute de la latence en raison du handshake, mais TLS 1.3 le réduit à un seul aller-retour. Avec la reprise de session et HTTP/2, la surcharge est minimale. Les coûts de chiffrement/déchiffrement sont faibles sur les CPU modernes.

Prêt à inspecter la configuration TLS de votre serveur ? Utilisez notre Analyseur de logs Nginx pour repérer les modèles de trafic inhabituels et vous assurer que votre configuration HTTPS fonctionne comme prévu.