HTTPS

01 — DéfinitionQu'est-ce que HTTPS ?

HTTPS (HyperText Transfer Protocol Secure) est la version sécurisée du protocole HTTP utilisé pour transférer les pages web entre votre navigateur et un serveur. Il ajoute une couche de chiffrement TLS qui protège les communications.

Les trois garanties de HTTPS

• Confidentialité : personne sur le chemin (Wi-Fi public, FAI, attaquant MITM) ne peut lire le contenu — mots de passe, numéros de carte, messages restent privés.
• Intégrité : les données ne peuvent pas être modifiées en transit — un attaquant ne peut pas injecter du code malveillant, changer un destinataire de paiement ou altérer un téléchargement.
• Authenticité : le navigateur vérifie via un certificat que le serveur contacté est bien associé au domaine affiché.

HTTPS vs HTTP

La différence visible :

• HTTP : URL commence par http://, pas de cadenas, tout le trafic circule en clair.
• HTTPS : URL commence par https://, cadenas visible, trafic chiffré.

La différence technique : HTTPS n'est rien d'autre que HTTP qui passe à travers une connexion TLS. Le protocole HTTP lui-même n'a pas changé — c'est juste une couche de chiffrement ajoutée dessous.

Le cadenas dans le navigateur

Le cadenas affiché dans la barre d'adresse signale une connexion HTTPS valide. Cliquer dessus donne accès aux détails :

• Certificat utilisé et son émetteur (l'autorité de certification).
• Version TLS utilisée.
• Suite cryptographique (cipher suite).
• Date d'expiration du certificat.

Les navigateurs affichent des avertissements explicites quand le certificat est invalide (expiré, domaine incorrect, CA non reconnue). Ces avertissements doivent être pris au sérieux — cliquer « continuer malgré l'avertissement » sur un site sensible peut exposer à un MITM.

Pourquoi HTTPS a été généralisé

Plusieurs moteurs convergents depuis 2014-2016 :

• Révélations Snowden (2013) : prise de conscience massive de la surveillance étatique, pression pour le chiffrement par défaut.
• Google SEO (août 2014) : HTTPS devient facteur de classement — impact business immédiat.
• Let's Encrypt (avril 2016) : certificats gratuits et automatisés, élimine la barrière économique.
• Chrome/Firefox (2018) : les sites HTTP sont marqués « Non sécurisé » dans la barre d'adresse.
• HTTP/2 et HTTP/3 : exigent HTTPS en pratique, performance améliorée par rapport au HTTP classique.
• RGPD (2018) : chiffrement des données personnelles en transit, quasi-obligatoire.

L'histoire de HTTPS illustre comment un standard peut passer de « bon à avoir » à « indispensable » en moins de 10 ans, sous l'effet combiné d'une technologie (Let's Encrypt), d'une révélation (Snowden), d'incitations (SEO, warning navigateur) et d'exigences réglementaires (RGPD). En 2015, moins de 40% du trafic était en HTTPS. Aujourd'hui, un site en HTTP est une anomalie suspecte.

02 — FonctionnementComment HTTPS chiffre vos communications

Vue d'ensemble

HTTPS = HTTP + TLS. Le navigateur établit d'abord une connexion TLS avec le serveur, puis envoie ses requêtes HTTP à travers ce tunnel chiffré. Du point de vue d'un observateur extérieur (attaquant, opérateur réseau), il voit du trafic chiffré indéchiffrable.

Le handshake TLS (connexion initiale)

Séquence d'échanges quand un navigateur visite un site HTTPS pour la première fois :

1. Client Hello : le navigateur dit au serveur « je veux établir une connexion TLS, voici les versions que je supporte (TLS 1.2, 1.3), voici les suites cryptographiques disponibles ».
2. Server Hello + Certificat : le serveur choisit une version TLS et une suite, et envoie son certificat numérique.
3. Vérification du certificat : le navigateur vérifie que le certificat est valide (non expiré), signé par une autorité de confiance présente dans son trust store, et correspond au domaine demandé.
4. Échange de clés : les deux parties négocient des clés de session via un mécanisme d'échange asymétrique (ECDHE en pratique). Ces clés seront utilisées pour chiffrer les données.
5. Finished : les deux parties confirment que le handshake s'est bien déroulé.

Durée typique : 100-300 ms. En TLS 1.3 (2018), le handshake est optimisé à 1 aller-retour au lieu de 2 pour TLS 1.2 — gain de performance notable.

Chiffrement symétrique des échanges

Une fois les clés de session établies, toutes les requêtes HTTP (et leurs réponses) sont chiffrées avec un algorithme symétrique rapide :

• AES-128-GCM ou AES-256-GCM : le plus courant, accéléré matériellement sur CPU modernes.
• ChaCha20-Poly1305 : alternative moderne, performante sur mobile et systèmes sans accélération AES.

Le chiffrement asymétrique est coûteux, le symétrique est rapide. Le handshake échange d'abord les clés symétriques de manière sécurisée, puis utilise ces clés pour le gros du trafic.

Ce qui est chiffré, ce qui ne l'est pas

HTTPS chiffre tout ce qui est dans la requête HTTP :

• URL complète (chemin, paramètres GET) : chiffrée.
• Headers (cookies, User-Agent, etc.) : chiffrés.
• Corps de la requête (formulaires, JSON, uploads) : chiffré.
• Réponse du serveur : entièrement chiffrée.

En revanche, certaines métadonnées restent visibles :

• Nom de domaine contacté : visible via DNS (non chiffré par défaut, sauf DoH/DoT) et via SNI (Server Name Indication) dans le handshake TLS. ECH (Encrypted Client Hello) qui chiffre le SNI est en déploiement mais pas universel fin 2026.
• Adresse IP : bien sûr visible — c'est le routage.
• Volumes échangés et timings : permettent des analyses statistiques (fingerprinting de trafic).

Un observateur voit donc « X a visité youtube.com pendant 30 minutes, téléchargé 200 Mo » mais pas quelles vidéos précises ont été regardées.

Versions de TLS

• SSL 1.0, 2.0, 3.0 : obsolètes et vulnérables. Désactivés partout.
• TLS 1.0 (1999) et 1.1 (2006) : dépréciés officiellement en 2020 par l'IETF. Plus supportés par Chrome, Firefox, Safari.
• TLS 1.2 (2008) : encore très répandu, toujours considéré sûr avec bonnes suites cryptographiques.
• TLS 1.3 (2018) : version moderne recommandée. Plus rapide (1-RTT handshake), plus sûre (suppression des suites faibles), design simplifié.

La PKI — infrastructure à clés publiques

HTTPS repose sur la PKI (Public Key Infrastructure) qui définit comment les certificats sont émis et vérifiés :

• Autorités de certification racines (CA) : entités de confiance dont les certificats sont pré-installés dans les navigateurs et systèmes d'exploitation (Mozilla, Microsoft, Apple, Google maintiennent chacun leur trust store).
• Autorités intermédiaires : signées par les racines, émettent les certificats aux sites finaux.
• Certificats serveurs : installés sur les sites web, présentés aux navigateurs.
• Chaîne de confiance : le navigateur vérifie que le certificat du site est signé par une intermédiaire, qui est signée par une racine de confiance.

Voir aussi notre fiche dédiée TLS/SSL pour les détails techniques.

03 — CertificatsTypes et autorités

Les trois niveaux de validation

Domain Validation (DV)

• Validation automatisée que le demandeur contrôle le domaine (via DNS TXT, HTTP challenge, email admin).
• Émission en quelques minutes.
• Let's Encrypt, ZeroSSL, la majorité des certificats gratuits.
• Affichage navigateur identique aux autres types : cadenas simple.
• >95% des certificats émis aujourd'hui.

Organization Validation (OV)

• Vérification de l'existence légale de l'organisation en plus du domaine.
• Émission en quelques jours, contrôle humain partiel.
• Coût : 50-300€/an.
• Utile pour signaler une organisation légitime dans les détails du certificat.

Extended Validation (EV)

• Validation poussée, y compris existence légale, adresse physique, cadre d'exercice.
• Émission en 1-2 semaines.
• Coût : 150-1000€/an.
• Historiquement : nom de l'organisation affiché en vert dans la barre d'adresse.
• Déprécié visuellement depuis 2019 : Chrome et Firefox ont retiré l'affichage distinctif, les utilisateurs ne le remarquaient pas.
• Utilité réduite aujourd'hui — les banques et grands acteurs en utilisent encore par tradition.

Certificats spéciaux

• Wildcard (*.example.com) : couvre tous les sous-domaines d'un niveau. Pratique pour déploiements multiples.
• SAN (Subject Alternative Name) : plusieurs domaines dans un même certificat (utile pour CDN, mutualisation).
• Multi-domaines : jusqu'à 100+ domaines sur un seul certificat.

Let's Encrypt — le changement de donne

Autorité de certification à but non lucratif lancée en avril 2016 par l'Internet Security Research Group (ISRG), soutenue par Mozilla, EFF, Akamai, Cisco. Révolutionnaire parce que :

• Gratuit : tous les certificats DV sans frais.
• Automatisé : protocole ACME (RFC 8555) permet l'émission/renouvellement sans intervention humaine.
• Courte durée : validité de 90 jours (contre 1-2 ans chez les CA commerciales). Force l'automatisation, limite l'impact d'une compromission.
• Universellement adopté : intégré dans la plupart des hébergeurs (OVH, Hostinger, Infomaniak), des CMS (WordPress, Joomla), des serveurs web (Caddy utilise Let's Encrypt par défaut).

Chiffres 2025 : Let's Encrypt émet des certificats pour plus de 500 millions de sites actifs. A fondamentalement transformé le web en rendant HTTPS accessible à tous.

Clients ACME

• Certbot : client officiel EFF, disponible sur tous les OS. Ligne de commande, plugins pour Apache/Nginx.
• acme.sh : alternative légère en shell.
• Caddy : serveur web moderne avec HTTPS automatique natif.
• Traefik : reverse proxy avec support Let's Encrypt.
• Plugins CMS : intégrations WordPress, etc.
• Intégration native chez tous les hébergeurs modernes.

Autorités commerciales

Les CA payantes existent toujours pour des besoins spécifiques :

• DigiCert : leader enterprise après rachat de Symantec CA en 2017.
• Sectigo (ex-Comodo CA) : acteur majeur.
• GlobalSign : présence internationale.
• Entrust : focus entreprise.

Ils gardent des parts de marché via : certificats EV/OV, validité plus longue (1-2 ans), support premium, garanties contractuelles (dédommagement en cas de compromission), certificats spéciaux (code signing, S/MIME pour email).

Certificate Transparency

Standard adopté en 2018 qui exige que tout certificat émis soit publié dans des logs publics auditables. Chaque émission laisse une trace cryptographique vérifiable. Impact :

• Un attaquant qui obtient un certificat frauduleux pour bank.com ne peut plus le cacher — la banque peut surveiller ses logs CT et détecter.
• Outils de surveillance : Censys, crt.sh, Hardenize, Facebook CT Monitor (gratuit pour les propriétaires de domaine).
• Conséquence directe du scandale DigiNotar 2011 et autres compromissions historiques.

Toute émission de certificat pour un domaine peut être surveillée par son propriétaire — infrastructure fondamentale pour la confiance dans la PKI.

04 — AdoptionL'évolution 2010-2026

Les chiffres clés

• 2010 : ~10% du trafic web en HTTPS.
• 2014 : ~35% — Google annonce HTTPS comme facteur SEO.
• 2016 : ~50% — lancement de Let's Encrypt.
• 2018 : ~75% — Chrome et Firefox marquent HTTP comme « Non sécurisé ».
• 2020 : ~90% — pandémie, migration massive vers le cloud.
• 2024-2026 : ~95-98% — HTTPS est devenu l'implicite.

Les sources : rapports annuels Google Transparency Report (Chrome), Mozilla Telemetry (Firefox), mesures Internet Society.

Les facteurs qui ont accéléré l'adoption

Pression des navigateurs

• 2014 : Chrome commence à montrer des indicateurs pour HTTP.
• 2018 : Chrome 68 marque tous les sites HTTP comme « Non sécurisé ». Firefox suit.
• 2020+ : les sites HTTP avec formulaires déclenchent des avertissements agressifs.
• 2023+ : « HTTPS-First » devient défaut dans les navigateurs modernes.

Économie du certificat

• Avant Let's Encrypt : certificats à 50-500€/an, barrière pour les petits sites.
• Depuis Let's Encrypt : gratuit et automatisé — plus d'excuse économique.
• Hébergeurs incluent désormais HTTPS par défaut dans tous les plans.

SEO et search

• Google depuis 2014 : HTTPS est facteur de classement.
• HTTP/2 et HTTP/3 (plus rapides) exigent HTTPS en pratique.
• Les sites restés en HTTP ont vu leur trafic organique baisser.

Cadre réglementaire

• RGPD (2018) : données personnelles doivent être chiffrées en transit.
• PCI DSS : HTTPS obligatoire pour traiter des paiements.
• Secteurs régulés (santé, finance) : HTTPS sans discussion.

Les 2-5% restants

Qui sont les sites encore en HTTP en 2026 ?

• Sites anciens abandonnés : mis en ligne il y a 10-20 ans, jamais mis à jour.
• Interfaces d'administration d'équipements : routeurs, imprimantes, IoT avec configuration en HTTP.
• Serveurs internes : certaines entreprises n'activent pas HTTPS en interne (mauvaise pratique).
• Sites obscurs : hébergement personnel, expérimentations.
• Contenu statique malveillant : certains serveurs de malware ou C2 (bien que la plupart utilisent HTTPS maintenant).

05 — LimitesCe que HTTPS ne protège pas

HTTPS est la base de la sécurité web, mais il est important de comprendre ce qu'il ne fait PAS pour éviter la fausse sécurité.

HTTPS ne garantit pas la légitimité du site

Problème majeur et source de confusion. Le cadenas dit seulement « la connexion est chiffrée et le serveur correspond au domaine demandé », pas « le site est digne de confiance ».

• Un site de phishing paypal-secure-login.com peut avoir HTTPS et cadenas.
• Selon diverses études, 80-90% des sites de phishing utilisent HTTPS aujourd'hui — c'est devenu le standard y compris chez les attaquants.
• Let's Encrypt est gratuit et rapide, idéal pour les campagnes de phishing de courte durée.

Conséquence : ne jamais se fier uniquement au cadenas pour juger d'un site. Vérifier le nom de domaine exact (attention au typosquatting), la qualité du site, la réputation.

HTTPS ne protège pas contre les failles applicatives

Un site en HTTPS peut parfaitement avoir :

• Des injections SQL.
• Du XSS.
• Du CSRF.
• Des failles d'authentification.
• Des fuites de données via APIs.

HTTPS sécurise le transport, pas l'application elle-même. L'OWASP Top 10 reste pleinement applicable.

HTTPS ne cache pas tout

Certaines informations restent visibles pour un observateur réseau :

• Domaine visité : via DNS (sauf DoH/DoT) et SNI (sauf ECH non universel).
• Adresse IP : visible dans le routage.
• Volumes et timings : permettent des analyses statistiques.
• Pattern de trafic : certaines techniques de fingerprinting peuvent identifier quelle page d'un site a été visitée via le volume de données.

HTTPS peut être contourné dans certains cas

• SSL stripping : si l'utilisateur tape juste example.com (sans https://), la première requête part en HTTP. Un MITM peut intercepter avant la redirection HTTPS. Protection : HSTS preload.
• Compromission de CA : historiquement, une CA compromise pouvait émettre des certificats frauduleux (DigiNotar 2011, Superfish 2015). Certificate Transparency limite ce risque depuis 2018.
• Rogue CA dans le trust store : malware qui installe sa propre CA racine, proxy d'inspection d'entreprise légitime ou malveillant.
• Protocoles faibles : TLS 1.0/1.1 mal désactivés, cipher suites vulnérables (Logjam, FREAK). Rare aujourd'hui mais pas disparu.

HTTPS n'empêche pas le suivi publicitaire

• Cookies tiers, fingerprinting navigateur, trackers : fonctionnent en HTTPS comme en HTTP.
• Le fournisseur VPN ou DNS sécurisé voit vos requêtes (confiance déplacée, pas supprimée).
• Les services que vous utilisez vous identifient indépendamment du transport.

Mixed content — piège fréquent

Une page HTTPS qui charge des ressources (images, scripts, CSS) en HTTP crée un mixed content problématique :

• Mixed content bloquant : scripts et CSS en HTTP sur page HTTPS sont bloqués par défaut par Chrome/Firefox depuis 2020. Peut casser l'affichage.
• Mixed content passif : images, vidéos en HTTP — affichées mais avec alerte.
• Solution : tout charger en HTTPS, utiliser // (protocol-relative URLs) devenu déconseillé, préférer https:// explicite.

06 — DéploiementMettre HTTPS en place

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

07 — FAQQuestions fréquentes

HTTP/2 et HTTP/3 exigent-ils HTTPS ?

Techniquement, HTTP/2 peut fonctionner en clair (h2c), mais en pratique tous les navigateurs exigent HTTPS pour activer HTTP/2. HTTP/3 (basé sur QUIC qui intègre TLS 1.3) est structurellement HTTPS-only. Les deux protocoles apportent des gains de performance significatifs : HTTP/2 multiplexe les requêtes sur une seule connexion TCP, HTTP/3 évite le head-of-line blocking de TCP via QUIC (sur UDP). Adopter HTTPS permet d'accéder à ces gains — c'est devenu un argument performance autant que sécurité. Adoption HTTP/3 en 2026 : ~35% du trafic mondial.

Pourquoi les certificats expirent-ils ?

Mécanisme de sécurité essentiel. Une validité limitée (90 jours pour Let's Encrypt, 1 an max pour CA commerciales depuis 2020) garantit que :

• Si une clé privée est compromise, la durée d'exploitation est limitée.
• Si un domaine change de propriétaire, le nouveau certificat nécessite une nouvelle validation.
• Les algorithmes et formats obsolètes sont progressivement remplacés.
• Le renouvellement force à vérifier périodiquement que tout fonctionne.

Tendance 2024-2025 : l'industrie discute de raccourcir encore la validité (45 jours envisagés). L'automatisation rend le renouvellement frequent indolore.

Puis-je faire du HTTPS sans acheter de certificat ?

Oui, gratuitement, en quelques minutes, avec Let's Encrypt. Solutions :

• Hébergeur avec HTTPS intégré : OVH, Hostinger, Infomaniak, Gandi, tous les hébergeurs modernes proposent HTTPS automatique en un clic.
• Cloudflare : proxy gratuit qui fournit HTTPS devant votre site, même si votre serveur est en HTTP (attention : end-to-end exige HTTPS sur le serveur aussi).
• Caddy : serveur web moderne qui gère Let's Encrypt automatiquement.
• Certbot : installation simple sur serveur Linux avec Apache/Nginx.
• Netlify, Vercel, GitHub Pages : HTTPS automatique pour sites statiques.

Il n'y a plus aucune raison technique ou économique d'héberger un site en HTTP en 2026.

Les pages internes d'entreprise doivent-elles aussi être en HTTPS ?

Oui, absolument — bonne pratique moderne. Raisons :

• Zero Trust : ne pas faire confiance au réseau interne, supposer qu'un attaquant peut y être présent.
• Déplacement latéral : un attaquant qui a pied dans le LAN pourrait sniffer les communications internes.
• BYOD et télétravail : les employés se connectent depuis des réseaux variés.
• Conformité : NIS2 et autres exigent le chiffrement des données en transit, y compris interne.
• Uniformité : plus simple d'avoir HTTPS partout que des règles différentes.

Pour les environnements internes, utiliser une PKI interne (CA privée) ou Let's Encrypt avec DNS challenge, ou des solutions comme HashiCorp Vault qui gèrent les certificats internes.

HTTPS va-t-il évoluer avec la cryptographie post-quantique ?

Oui, transition en cours. Les ordinateurs quantiques pourront théoriquement casser RSA, ECDSA, Diffie-Hellman quand ils atteindront suffisamment de qubits logiques (horizon incertain mais 10-20 ans). Évolutions :

• NIST a standardisé en 2024 plusieurs algorithmes post-quantiques : ML-KEM (Kyber), ML-DSA (Dilithium), SLH-DSA (SPHINCS+).
• Chrome et Firefox supportent des suites hybrides (classique + post-quantique) depuis 2024 pour l'échange de clés.
• Certificats post-quantiques : encore en expérimentation, déploiement progressif attendu 2026-2030.
• Exigence ANSSI : roadmap post-quantique publiée, transition recommandée d'ici 2030 pour données sensibles à long terme.
• Risque « harvest now, decrypt later » : adversaires peuvent stocker du trafic chiffré aujourd'hui pour le déchiffrer plus tard avec des ordinateurs quantiques — motivation pour passer tôt aux algorithmes résistants.

Les données très sensibles (défense, santé à long terme) devraient déjà envisager les suites hybrides. Le web généraliste suivra progressivement.

Quelle différence entre certificat auto-signé et Let's Encrypt ?

Certificat auto-signé : signé par lui-même, pas par une autorité de confiance. Les navigateurs affichent un avertissement majeur (« Votre connexion n'est pas privée »). Utile uniquement pour développement local ou environnements internes avec ajout manuel au trust store. Jamais en production publique. Certificat Let's Encrypt : signé par l'autorité ISRG Root X1 (présente dans tous les navigateurs/OS modernes). Validation standard sans avertissement. Le navigateur fait confiance car la chaîne remonte à une racine du trust store. Techniquement tous deux font du chiffrement valide — la différence est uniquement dans la confiance de la signature.