HTTP, HTTPS et certificats SSL/TLS : ce que le cadenas protège vraiment
HTTP organise l’échange, HTTPS le protège et le certificat aide le navigateur à vérifier le serveur. Décryptage simple, sans confondre chiffrement, identité et fiabilité du site.
HTTP, HTTPS, SSL, TLS, certificat et cadenas sont souvent utilisés comme s’ils désignaient la même chose. Ils appartiennent au même mécanisme, mais chacun joue un rôle différent.
La distinction la plus simple est la suivante : HTTP définit comment un navigateur et un serveur web se parlent. HTTPS utilise ce même langage à l’intérieur d’un canal protégé par TLS. Le certificat numérique permet au navigateur de vérifier qu’il établit ce canal avec le domaine demandé.
Comprendre ces trois niveaux évite deux erreurs fréquentes : croire que HTTPS garantit qu’un site est honnête, ou penser qu’un certificat ne sert qu’à afficher un cadenas.
HTTP : le langage des échanges sur le web
HTTP signifie Hypertext Transfer Protocol. Lorsqu’une personne ouvre une page, son navigateur envoie une requête au serveur. Celui-ci renvoie une réponse contenant un statut, des en-têtes et généralement le contenu demandé.
Une requête peut demander une page, envoyer un formulaire, charger une image ou appeler une API. Une réponse peut indiquer que tout s’est bien passé, que la ressource a changé d’adresse ou qu’elle n’existe pas.
HTTP organise donc la conversation. À lui seul, il ne protège pas le trajet. Sur une connexion HTTP non chiffrée, une personne capable d’observer le réseau peut potentiellement lire des informations échangées ou tenter de les modifier. C’est particulièrement dangereux sur un réseau Wi-Fi non fiable ou lorsqu’un formulaire transmet un identifiant, une adresse ou une donnée de paiement.
HTTPS : HTTP transporté dans un canal TLS
Le S de HTTPS signifie secure. Avant d’échanger les requêtes et réponses HTTP, le navigateur et le serveur établissent une connexion TLS.
Cette couche apporte trois garanties principales pendant le transport.
- Confidentialité : les données échangées sont chiffrées et ne peuvent pas être lues simplement par un intermédiaire.
- Intégrité : une modification clandestine du trafic peut être détectée.
- Authentification : le navigateur vérifie que le certificat présenté correspond au nom de domaine demandé et qu’il remonte à une autorité reconnue.
HTTPS protège les en-têtes et le corps des messages HTTP pendant leur trajet. Un fournisseur d’accès ou une personne présente sur le même réseau peut encore observer certaines informations techniques, comme l’adresse IP contactée et le volume de trafic, mais pas normalement le détail de la page, du formulaire ou des paramètres protégés dans la connexion.
SSL ou TLS : quel terme faut-il employer ?
SSL, pour Secure Sockets Layer, est l’ancien protocole qui a précédé TLS. Les versions de SSL sont obsolètes et ne doivent plus être utilisées. Dans une configuration moderne, le terme correct est TLS, généralement en version 1.2 ou 1.3.
L’expression « certificat SSL » reste pourtant très répandue dans les offres d’hébergement. Elle désigne presque toujours un certificat utilisé avec TLS. Ce n’est pas nécessairement une erreur commerciale grave, mais il faut retenir que la sécurité réelle repose aujourd’hui sur TLS, pas sur l’ancien SSL.
Le certificat numérique : une carte d’identité pour le domaine
Un certificat contient notamment le ou les noms de domaine couverts, une clé publique, une période de validité, l’identité de l’émetteur et une signature numérique.
Lors de la connexion, le navigateur vérifie plusieurs points :
- le certificat couvre bien le domaine affiché dans l’adresse ;
- il est actuellement valide ;
- sa signature et la chaîne de certificats mènent à une autorité de certification reconnue ;
- il n’est pas présenté dans un contexte manifestement invalide.
L’autorité de certification ne possède pas la clé privée du site. Cette clé reste sur le serveur et ne doit jamais être divulguée. Le certificat relie la clé publique au domaine ; la clé privée permet ensuite au serveur de prouver qu’il contrôle la clé correspondante.
Ce qui se passe lors de la connexion
Le mécanisme complet est complexe, mais son principe peut être résumé en quatre étapes.
- Le navigateur contacte le serveur et propose les versions et paramètres cryptographiques qu’il accepte.
- Le serveur choisit des paramètres compatibles et présente son certificat.
- Le navigateur valide le certificat et les deux parties établissent des secrets de session sans les transmettre directement comme un simple mot de passe.
- Les requêtes et réponses HTTP circulent ensuite dans le canal chiffré.
Les techniques modernes combinent ainsi la cryptographie asymétrique, pratique pour l’authentification et l’établissement des secrets, avec la cryptographie symétrique, plus rapide pour protéger le volume de données échangé.
Ce que HTTPS garantit et ce qu’il ne garantit pas
HTTPS signifie que la connexion vers le domaine affiché est protégée. Il ne signifie pas que le propriétaire de ce domaine est honnête, que les informations publiées sont exactes ou que le serveur ne sera jamais piraté.
Un fraudeur peut enregistrer un nom ressemblant à celui d’une banque et obtenir un certificat valide pour ce faux domaine. La connexion au site frauduleux sera alors chiffrée, mais elle restera frauduleuse. Il faut donc lire le véritable nom de domaine, pas seulement rechercher une icône de sécurité.
HTTPS ne protège pas non plus une donnée après son arrivée. Si le site stocke les mots de passe en clair, partage des informations avec des tiers sans base valable ou présente une faille dans son application, le certificat ne résout pas ces problèmes.
Enfin, le chiffrement ne remplace ni les mises à jour, ni l’authentification multifacteur, ni une politique de confidentialité, ni un développement sécurisé.
Les erreurs de certificat les plus courantes
Certificat expiré
Chaque certificat possède une date de début et de fin. Son renouvellement doit être automatisé et surveillé. Une automatisation sans alerte n’est pas suffisante : le site doit détecter l’échec avant que les visiteurs ne le découvrent.
Nom de domaine différent
Un certificat délivré pour un domaine ne couvre pas automatiquement toutes ses variantes. Les sous-domaines et noms alternatifs nécessaires doivent figurer dans le certificat.
Chaîne incomplète
Le serveur doit parfois fournir des certificats intermédiaires pour permettre au navigateur de reconstruire la chaîne de confiance. Une mauvaise configuration peut fonctionner sur certains appareils et échouer sur d’autres.
Contenu mixte
Une page principale chargée en HTTPS peut encore appeler une image, une feuille de style ou un script en HTTP. Ce contenu mixte affaiblit la protection et les navigateurs bloquent généralement les ressources actives les plus dangereuses.
Anciennes versions de TLS
TLS 1.0 et 1.1 sont dépassés. Un serveur moderne doit prendre en charge TLS 1.2 et privilégier TLS 1.3 lorsque l’environnement le permet.
Redirection HTTPS et HSTS
Un site qui fonctionne en HTTPS doit aussi gérer les personnes qui saisissent encore une adresse commençant par HTTP. Le serveur redirige normalement ces requêtes vers la version HTTPS.
Cette première requête non protégée peut cependant être interceptée. L’en-tête HSTS indique au navigateur qu’il doit utiliser directement HTTPS pour les visites suivantes. Une inscription correcte dans une liste de préchargement HSTS peut également protéger la première visite, mais elle exige une configuration rigoureuse de tous les sous-domaines concernés.
HSTS est utile, mais une mauvaise décision peut rendre un sous-domaine inaccessible. Il doit être déployé progressivement, après avoir confirmé que tout le périmètre fonctionne durablement en HTTPS.
Comment un visiteur doit-il vérifier un site ?
- Lisez le nom de domaine complet, surtout avant une connexion ou un paiement.
- Méfiez-vous des lettres remplacées, mots ajoutés et domaines inhabituels.
- N’ignorez pas un avertissement de certificat pour un service sensible.
- Ouvrez vous-même le site officiel plutôt que de suivre un lien reçu par message.
- Rappelez-vous qu’une connexion chiffrée peut mener à un site frauduleux.
La checklist du propriétaire de site
- Servir toutes les pages et ressources en HTTPS.
- Rediriger HTTP vers HTTPS.
- Automatiser le renouvellement du certificat et surveiller son expiration.
- Prendre en charge TLS 1.2 et 1.3 avec une configuration actuelle.
- Supprimer le contenu mixte.
- Tester le domaine principal et tous les sous-domaines.
- Déployer HSTS avec prudence.
- Protéger la clé privée et limiter les personnes qui y ont accès.
- Continuer à sécuriser l’application et les données après le transport.
Conclusion
HTTP décrit l’échange entre le navigateur et le serveur. HTTPS protège cet échange grâce à TLS. Le certificat fournit au navigateur les éléments nécessaires pour authentifier le domaine et établir le canal sécurisé.
Le cadenas n’est donc ni un label de qualité ni une preuve d’honnêteté. Il indique que la connexion vers le domaine affiché bénéficie de garanties de confidentialité, d’intégrité et d’authentification. C’est indispensable sur le web moderne, mais ce n’est qu’une couche de la sécurité globale.