Comment fonctionnent HTTPS et TLS : Guide pratique

Security2026-11-02TryQuickToolBox

Vous avez vu le cadenas dans votre navigateur et vous savez qu'HTTPS est important. Mais comprenez-vous vraiment ce qui se passe lorsqu'un navigateur se connecte à un site HTTPS ? De nombreux développeurs considèrent TLS comme une boîte noire : configurez-le une fois et oubliez-le. Cela fonctionne jusqu'à ce que quelque chose casse, que les performances se dégradent ou qu'un audit de sécurité révèle des erreurs de configuration.

Ce guide explique HTTPS et TLS en termes pratiques. Vous apprendrez le processus de poignée de main, comment les certificats établissent la confiance, et les étapes pour implémenter TLS correctement sur vos serveurs. Pas de surcharge de jargon—juste les concepts dont vous avez besoin pour déboguer les problèmes et prendre des décisions éclairées.

Ce qu'est réellement HTTPS

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

TLS est le protocole qui rend cela possible. SSL est son prédécesseur—vous verrez encore « certificats SSL » dans le marketing, mais les systèmes modernes utilisent TLS (actuellement TLS 1.3 est la dernière version).

La poignée de main TLS : étape par étape

Avant que toute donnée HTTP ne circule, le client et le serveur effectuent une poignée de main pour s'accorder sur les paramètres de chiffrement et vérifier les identités. Voici le flux simplifié pour TLS 1.3, la norme moderne :

  1. Client Hello : Le navigateur envoie une liste de suites de chiffrement prises en charge, les versions de TLS et une valeur aléatoire (aléa client).
  2. Server Hello : Le serveur choisit une suite de chiffrement, envoie sa propre valeur aléatoire (aléa serveur) et fournit sa chaîne de certificats.
  3. Échange de clés : En utilisant Diffie-Hellman éphémère (ou similaire), les deux parties dérivent un secret partagé sans le transmettre directement. Cela assure la confidentialité persistante—compromettre la clé privée du serveur plus tard ne permettra pas de déchiffrer les sessions passées.
  4. Vérification du certificat : Le client vérifie le certificat par rapport aux autorités de certification racines de confiance, valide le nom de domaine et vérifie la date d'expiration et le statut de révocation.
  5. Finished : Les deux côtés envoient un MAC (code d'authentification de message) pour confirmer que la poignée de main n'a pas été altérée. Le trafic HTTP chiffré commence.

TLS 1.3 a réduit la poignée de main à un seul aller-retour (1-RTT) et prend en charge la reprise 0-RTT pour les visiteurs récurrents, améliorant la latence. TLS 1.2 nécessitait deux allers-retours.

Certificats : l'ancre de confiance

Un certificat TLS lie une clé publique à un nom de domaine et est signé par une autorité de certification (CA). Lorsque votre navigateur se connecte à example.com, il vérifie que le certificat :

Vous pouvez obtenir des certificats gratuitement auprès de Let's Encrypt, qui délivre des certificats de 90 jours via le protocole ACME. Des outils d'automatisation comme Certbot gèrent le renouvellement. Pour les services internes, vous pouvez exécuter votre propre CA, mais les clients doivent lui faire confiance explicitement.

Configuration de TLS sur votre serveur

Une configuration appropriée équilibre sécurité, compatibilité et performances. Voici une liste de vérification :

Pour Nginx, une configuration sécurisée minimale ressemble à ceci :

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-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
    ssl_prefer_server_ciphers off;

    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    ssl_stapling on;
    ssl_stapling_verify on;
    resolver 8.8.8.8;

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

    location / {
        proxy_pass http://localhost:3000;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

Testez votre configuration avec des outils comme SSL Labs' SSL Test ou testssl.sh. Visez une note A, mais ne cherchez pas des scores parfaits au détriment de la compatibilité avec les anciens clients si vous devez les prendre en charge.

Pièges courants et comment les éviter

FAQ

Quelle est la différence entre HTTPS et TLS ?

HTTPS est HTTP sur TLS. TLS est le protocole cryptographique qui fournit le chiffrement, l'authentification et l'intégrité. Vous ne pouvez pas avoir HTTPS sans TLS.

Ai-je besoin d'un certificat séparé pour www et non-www ?

Vous pouvez inclure les deux dans le champ Subject Alternative Names (SAN) d'un seul certificat. La plupart des CA délivrent des certificats couvrant les deux par défaut ou avec une configuration simple.

À quelle fréquence dois-je renouveler mes certificats TLS ?

Suivez la période de validité de la CA—90 jours pour Let's Encrypt. Automatisez le renouvellement avec une tâche cron ou un timer systemd. Renouvelez immédiatement si une clé privée est compromise.

Prêt à inspecter votre trafic web ? Utilisez l'Analyseur de logs Nginx pour analyser les logs d'accès et vérifier les requêtes HTTPS, les codes de statut et les problèmes potentiels.