TryQuickToolBox

Comment fonctionnent vraiment HTTPS et TLS : guide pratique

Security2026-11-10TryQuickToolBox

Vous avez probablement déjà vu le cadenas dans votre navigateur et savez qu'il signifie « sécurisé ». Mais que se passe-t-il réellement lorsque vous visitez un site HTTPS ? Comment votre navigateur sait-il qu'il parle au vrai serveur et non à un imposteur ? Et pourquoi TLS ralentit-il parfois les choses ? Ce guide décompose HTTPS et TLS en termes pratiques, pour que vous puissiez configurer, déboguer et sécuriser vos applications web en toute confiance.

Ce qu'est réellement HTTPS

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

Sans TLS, HTTP envoie tout en clair : mots de passe, cookies et données personnelles sont visibles par quiconque sur le chemin réseau. HTTPS corrige cela.

Le handshake TLS en langage clair

Avant que la moindre donnée chiffrée ne circule, le client et le serveur effectuent un handshake pour s'accorder sur les clés de chiffrement et vérifier l'identité. Voici ce qui se passe lors d'un handshake TLS 1.3 typique (le standard moderne) :

  1. Client Hello : Le navigateur envoie une liste de suites de chiffrement prises en charge, de versions TLS et une valeur aléatoire.
  2. Server Hello : Le serveur choisit une suite de chiffrement, envoie sa propre valeur aléatoire et fournit sa chaîne de certificats.
  3. Échange de clés : Les deux parties utilisent un algorithme d'échange de clés (comme ECDHE) pour dériver un secret partagé sans jamais le transmettre directement.
  4. Vérification du certificat : Le client vérifie le certificat du serveur par rapport aux AC racines de confiance, valide le nom de domaine et contrôle l'expiration.
  5. Finished : Les deux parties envoient un MAC pour confirmer l'intégrité du handshake, et les données applicatives chiffrées commencent à circuler.

TLS 1.3 réduit cela à un seul aller-retour (1-RTT) et prend même en charge la reprise 0-RTT pour les visiteurs récurrents, ce qui réduit considérablement la latence par rapport à TLS 1.2.

Les certificats : l'ancre de confiance

Un certificat lie une clé publique à un nom de domaine et est signé par une autorité de certification (AC). Les navigateurs et systèmes d'exploitation embarquent un magasin d'AC racines de confiance. Lorsqu'un serveur présente son certificat, le client vérifie la chaîne jusqu'à une racine de confiance.

Types de certificats courants :

Les certificats expirent, l'automatisation est donc essentielle. Des outils comme Certbot ou les clients ACME intégrés à votre reverse proxy gèrent le renouvellement automatiquement.

Configurer HTTPS sur votre serveur

Voici une configuration Nginx minimale qui active 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';
    ssl_prefer_server_ciphers off;

    # HSTS (enable after testing)
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

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

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

Points clés : utilisez uniquement TLS 1.2 et 1.3, privilégiez les suites de chiffrement ECDHE pour la confidentialité persistante (forward secrecy), et redirigez HTTP vers HTTPS. HSTS indique aux navigateurs d'utiliser toujours HTTPS pour votre domaine, mais testez soigneusement avant de l'activer avec un max-age long.

Pièges courants et comment les éviter

TLS 1.2 vs TLS 1.3 : ce qui a changé

FonctionnalitéTLS 1.2TLS 1.3
Aller-retours du handshake2-RTT1-RTT (0-RTT avec reprise)
Échange de clésRSA ou ECDHEECDHE uniquement (forward secrecy obligatoire)
Suites de chiffrementNombreuses, dont certaines faiblesEnsemble réduit, toutes AEAD
Données 0-RTTNon prises en chargePrises en charge (avec risque de rejeu)

TLS 1.3 est plus rapide et plus simple, en supprimant les algorithmes hérités. La plupart des clients modernes le prennent en charge, mais conservez TLS 1.2 pour les appareils plus anciens.

Déboguer les problèmes TLS

Lorsque HTTPS échoue, vérifiez ces points :

Si vous travaillez régulièrement avec les logs Nginx, l'Nginx Log Analyzer peut vous aider à repérer rapidement les échecs de handshake TLS et autres problèmes.

FAQ

Quelle est la différence entre HTTPS et TLS ?

HTTPS est HTTP sur TLS. TLS est le protocole cryptographique qui assure le chiffrement, l'intégrité et l'authentification. HTTPS est la version sécurisée de HTTP qui utilise TLS.

Ai-je besoin d'un certificat pour les services internes ?

Oui, pour les services internes en production, utilisez des certificats de votre propre AC ou d'une AC publique. Les certificats auto-signés causent des problèmes de confiance ; envisagez une PKI privée ou des outils comme mkcert pour le développement.

À quelle fréquence les certificats doivent-ils être renouvelés ?

La bonne pratique moderne consiste à utiliser des certificats de 90 jours avec renouvellement automatisé, comme le propose Let's Encrypt. Des durées de vie plus courtes réduisent le risque en cas de compromission d'une clé.

Prêt à sécuriser votre site ? Commencez par tester votre configuration TLS actuelle avec un vérificateur SSL, puis appliquez les paramètres Nginx ci-dessus. Pour approfondir la sécurité web, explorez nos autres guides sur le Top 10 OWASP et la prévention des XSS.