Regardez dès maintenant la barre d’adresse de votre navigateur. L’URL commence très certainement par « https » et affiche un petit cadenas ; si ce n’était pas le cas, votre navigateur vous aurait probablement averti avant de vous laisser continuer. Cette lettre supplémentaire, le « s », a discrètement transformé le Web. Ce petit « s » signifie « sécurisé », et il est bien plus important que ce que l’on croit généralement. Cet article propose une comparaison simple entre HTTP et HTTPS : ce qui les différencie réellement, pourquoi c’est important, et où réside la véritable nuance.
HTTP et HTTPS : un aperçu rapide
Voici la réponse en bref avant d’entrer dans les détails. HTTP et HTTPS sont le même protocole. Mêmes méthodes, mêmes en-têtes, mêmes codes d’état, même structure d’URL. Une requête HTTPS est, octet par octet, la requête HTTP qu’elle aurait été ; elle est simplement transmise différemment. HTTPS est un protocole HTTP transporté au sein d’une session TLS , ce qui explique pourquoi sa définition est si succincte : un schéma, un port par défaut et une instruction visant à établir la poignée de main TLS avant d’utiliser HTTP. Ce qu’ TLS apporte, ce sont trois propriétés, et pas seulement le chiffrement.
Confidentialité: les données sont transmises sous forme chiffrée. Toute personne intervenant sur le trajet ne voit qu’un texte chiffré, impossible à distinguer du bruit, et non votre requête sous forme de texte lisible.
Intégrité: TLS utilise un chiffrement avec authentification, ce qui signifie que toute modification apportée à un enregistrement entraîne l'échec de l'authentification et la coupure de la connexion, au lieu de transmettre discrètement le contenu altéré.
Authentification: le serveur présente un certificat numérique associant sa clé publique au nom du serveur que vous avez saisi, et s'enchaînant à une racine de confiance déjà présente dans votre navigateur.
Ce dernier point est sans doute le plus important. Sans cela, un attaquant se trouvant sur le chemin établit simplement une connexion chiffrée avecvouset une autre avec la source, et la confidentialité ne sert alors à rien.
Port 80 vs port 443
Un port est un numéro qui indique à quel programme d’un ordinateur le trafic réseau est destiné. Lorsque le trafic réseau arrive à l’entrée de votre ordinateur, celui-ci examine le port qu’il utilise et le signale à l’ordinateur, qui l’achemine ensuite vers le programme approprié. Les navigateurs Web utilisent le port 80 pour se connecter aux serveurs Web via le protocole HTTP (HyperText Transfer Protocol). Le protocole HTTPS utilise le port 443, sur lequel la connexion est chiffrée et le serveur authentifié. Lorsqu’un navigateur a besoin d’une connexion sécurisée, il bascule automatiquement vers le protocole chiffré, à condition que le serveur dispose d’un certificat valide.
Texte clair ou chiffré ?
HTTP est un protocole en texte clair qui expose tout ce qui circule sur le réseau : en-têtes, cookies, corps de message, etc. Il est donc relativement facile pour un tiers d’intercepter et de lire les données en transit, et de découvrir tout ce qui a été envoyé pendant la communication. Ce protocole n’est pas adapté aux situations nécessitant la confidentialité. De plus, HTTP expose les utilisateurs à des serveurs non authentifiés susceptibles de contenir des logiciels malveillants ou de présenter d’autres menaces. Le protocole HTTPS, en revanche, chiffre la communication et authentifie le serveur. Même si un pirate intercepte le trafic, le contenu chiffré lui apparaîtra comme un charabia incompréhensible, à moins qu’il ne dispose de la clé de déchiffrement appropriée.
Comment s'en rendre compte
Le moyen le plus simple de vérifier est de regarder l'URL. Un site sécurisé commence par « https » et affiche une icône en forme de cadenas près de la barre d'adresse. Cliquez sur ce cadenas pour consulter les détails du certificat, notamment son émetteur et sa date d'expiration.
Dans le terminal, vous pouvez également surveiller toutes les connexions actuellement ouvertes et transitant par un port. Par exemple, pour le port 443,
ss -tnp état établi « ( dport = :443 ou sport = :443 ) »
Petit historique : comment le Web est devenu sécurisé par défaut
Le protocole HTTP est apparu en premier et, pendant des années, il a constitué la norme par défaut non chiffrée du Web. La sécurité a été intégrée progressivement, et les éléments qui ont rendu le protocole HTTPS possible ont été mis en place par étapes.
L'ère du texte brut
Aux débuts du Web, les données circulaient en clair. Le protocole HTTP transférait les pages et les soumissions de formulaires sous forme de texte lisible, en ce sens que quiconque disposait d’une capture de paquets pouvait faire défiler une session comme on ferait défiler un document. Il s’agissait d’un choix de conception, et non d’une négligence. Le protocole original de Tim Berners-Lee ne comportait qu’une seule méthode et aucun en-tête ; il récupérait des documents hypertextes sur des serveurs de physique à l’intention d’un public de physiciens. À cette époque, on était régi par la tradition académique d’ouverture, sans crainte d’acteurs malveillants. Le chiffrement aurait constitué une charge supplémentaire pour contrer une menace qui n’existait pas encore.
Ce n’est pas une faille du protocole HTTP qui a remis en cause cette hypothèse. Ce sont le commerce et la crainte des logiciels malveillants. Dès lors que le Web a commencé à transporter des numéros de carte bancaire et des identifiants de connexion, le fait que ces données soient « lisibles par n’importe qui sur le chemin » a cessé d’être une propriété neutre. Il était également important de se sentir en sécurité lorsqu’on visitait un site Web, en ayant la certitude que l’entité à l’autre bout était bien celle qu’elle prétendait être.
De Netscape SSL aux navigateurs modernes TLS
Netscape a développé le protocole « SSL » dans les années 1990 afin de chiffrer et de sécuriser les communications sur Internet.
- SSL La version 1.0 n'a jamais été publiée en raison de problèmes de sécurité.
- La version 2.0 est sortie en 1995 avec de nombreux défauts.
- La version 3.0 a suivi en 1996, apportant des améliorations majeures.
- L'Internet Engineering Task Force a ensuite élaboré le document « TLS » pour lui succéder : « TLS » v1.0 en 1999, v1.2 en 2008 et v1.3 finalisée en 2018.
- En 2020, le protocole SSL avait été complètement abandonné, et les protocoles TLS v1.2 et v1.3 étaient devenus les seuls encore utilisés, même si l’on entend encore parfois dire «SSL ».
Pour une comparaison complète entre SSL et TLS, consultez notre guide « HTTPS Everywhere ».
Les navigateurs modernes privilégient désormais la sécurité par défaut. Chrome, Firefox, Edge et d’autres utilisent le protocole HTTPS par défaut et signalent les pages non sécurisées ; c’est pourquoi un site fonctionnant uniquement en HTTP déclenche de plus en plus souvent un avertissement plutôt qu’un chargement silencieux. Ce paramètre par défaut est devenu, pour ainsi dire, « à plusieurs niveaux ».
- La première de ces couches concerne le comportement de la barre d'adresse : par exemple, lorsque l'on tape « keyfactor.com », cela renvoie vers «https://www.keyfactor.com ».
- Le deuxième concerne la mise à niveau de la navigation : si vous cliquez sur le lienhttp://www.keyfactor.com, ou sur un lien intégré à une page, la requête est automatiquement réessayée via HTTPS, avec un repli vers le texte en clair si la mise à niveau échoue.
- Le troisième est le mode « HTTPS-First » : celui-ci supprime la solution de repli et affiche une page d'avertissement complète. L'utilisateur peut toujours poursuivre, mais il doit en donner l'autorisation explicite.
Le modèle de menace : ce qui se passe réellement sur le protocole HTTP standard
La raison pour laquelle les navigateurs encouragent autant l'utilisation du protocole HTTPS n'est pas d'ordre purement esthétique. Le protocole HTTP standard présente des failles réelles et exploitables.
Écoutes clandestines et interceptions
Sur les connexions HTTP non sécurisées, toute personne se trouvant sur le chemin du réseau peut intercepter les messages échangés entre le navigateur et le serveur et les lire en clair. Les connexions chiffrées brouillent ces communications jusqu’à ce que le destinataire prévu les déchiffre ; ainsi, une personne qui les intercepte ne voit rien d’utilisable, ce qui est particulièrement important si la communication contient des informations permettant d’identifier une personne, des données sensibles, des mots de passe, etc.
Attaques de type « man-in-the-middle »
Lorsque vous consultez un site web, votre navigateur envoie une requête et le serveur renvoie une réponse. Sans protection, cette interaction est exposée aux attaques de type « man-in-the-middle », dans lesquelles un acteur malveillant intercepte les données en transit et peut les extraire ou les altérer. Par exemple, si vous vous connectez à un portail bancaire en ligne et que quelqu’un intercepte ce trafic, vos identifiants pourraient être exposés, ce qui pourrait entraîner une usurpation d’identité ou des pertes financières.
La confiance, le phishing et la nécessité d'une infrastructure à clé publique
Le chiffrement n'est qu'une partie du problème. Un certificat valide émis par une autorité de certification (CA) de confiance authentifie également le serveur, prouvant ainsi que le site est bien celui qu'il prétend être. Si un site web demande des informations sensibles et ne dispose d'aucun certificat, il ne faut pas lui confier de données privées via cette connexion. L'authentification du serveur prouve que le certificat appartient bien au domaine affiché dans la barre d'adresse, mais pas que ce domaine est celui que l'utilisateur avait l'intention de visiter. Le phishing exploite cette faille, car un pirate qui enregistre un domaine très similaire peut obtenir un certificat valide pour celui-ci et présenter une connexion entièrement authentifiée vers un site auquel l’utilisateur ne fait pas réellement confiance. Le protocole HTTPS protège donc à la fois la confidentialité des échanges et l’identité du site. Pour en savoir plus sur les autorités de certification, consultez notreguide dédié aux AC ou lisez notreanalyse approfondie sur PKIafin d’avoir une vision plus large de l’infrastructure de confiance.
La menace à venir : récolter maintenant, décrypter plus tard
Il existe également un risque à long terme. Les systèmes de chiffrement actuels sont sûrs face aux ordinateurs classiques, mais pas face à des ordinateurs quantiques suffisamment puissants, dont la mise au point est probable d’ici 5 à 15 ans. Cela a suscité des inquiétudes concernant les attaques de type « HNDL », dans lesquelles des attaquants enregistrent aujourd’hui le trafic chiffré dans l’intention de le déchiffrer plus tard, une fois que les capacités quantiques auront atteint leur maturité.
Pour se prémunir contre ce risque, le secteur s'oriente vers la cryptographie post-quantique, qui fonctionne sur des ordinateurs classiques tout en restant résistante aux attaques, même après la mise au point d'ordinateurs quantiques puissants. Cette migration cryptographique implique notamment le remplacement de l'échange de clés traditionnel par des mécanismes résistants aux attaques quantiques dans les futures versions d'TLS.
Ce que le protocole HTTPS ne parvient toujours pas à masquer
Voici la vérité, que l’on a souvent tendance à passer sous silence : le protocole HTTPS protège lecontenude vos requêtes, mais il ne vous rend pas invisible. Le chiffrement masque ce que vous envoyez et recevez, de sorte qu’un intercepteur ne voit qu’un charabia, mais plusieurs signaux restent visibles.
Des métadonnées qui restent visibles
L'adresse IP de destination reste visible, car le réseau doit acheminer votre trafic vers une destination. Dans de nombreuses configurations, le nom de domaine est également révélé lors des requêtes « DNS », et le nom du serveur est transmis dès le début de la connexion. Un observateur ne peut peut-être pas lire vos messages, mais il peut souvent déterminer à quel service vous vous connectez.
Modèles de circulation
Le volume et le moment où votre trafic est généré peuvent, à eux seuls, révéler des informations. Des schémas distincts, tels que le rythme d'un flux vidéo ou la structure d'une séquence de connexion, peuvent donner des indices sur ce qui se passe, même lorsque la charge utile est chiffrée.
Ce que le chiffrement ne peut pas résoudre
Le chiffrement protège les données en transit, mais pas aux extrémités de la communication. Un appareil piraté, un logiciel malveillant sur votre ordinateur ou un site malveillant disposant d’un certificat parfaitement valide ne relèvent pas du champ d’application du protocole HTTPS. Le cadenas indique que la connexion est chiffrée et que le certificat est valide ; il ne garantit en rien les intentions de la personne se trouvant à l’autre bout de la connexion.
Quand le protocole HTTP simple reste acceptable
Le protocole HTTP simple n'est pas systématiquement à proscrire. Il subsiste quelques cas légitimes présentant peu de risques, même si les recommandations en la matière se restreignent de plus en plus.
Contextes non sensibles, internes ou isolés
L'outillage interne et le développement local, où aucune donnée privée n'est échangée, peuvent fonctionner via HTTP sans grand souci. Le trafic vers votre propre machine ne passe jamais par un réseau ; il n'y a donc aucun intercepteur dont il faille se méfier. C'est également la raison pour laquelle les certificats « Domain Validated », les plus simples et les plus rapides à émettre, sont destinés aux sites personnels ou internes plutôt qu'aux sites web professionnels publics qui collectent des données.
Il existe également un cas de figure de principe où l’utilisation du protocole HTTP est justifiée par sa conception même. Certains objets signés conservent leur intégrité quel que soit leur mode de transmission ; leur diffusion via HTTP relève donc d’un choix délibéré plutôt que d’un simple raccourci. De plus, certaines étapes de démarrage, telles que la redirection initiale d’une adresse « http:// » vers « https:// », doivent s’effectuer sur le port 80 avant qu’une connexion sécurisée ne soit établie.
Pourquoi la notion d’« acceptable » se rétrécit
La liste des cas où l'utilisation du protocole HTTP est acceptable ne cesse de s'amenuiser, et ce pour de bonnes raisons. Les paramètres par défaut des navigateurs signalent désormais le HTTP « non sécurisé », quel que soit le contenu. Les certificats sont désormais gratuits et se renouvellent automatiquement via le protocole ACME, désormais largement pris en charge par plusieurs plateformes d'PKI , telles que EJBCA; l'ancienne excuse selon laquelle les certificats sont coûteux ou nécessitent une gestion manuelle n'est donc plus valable. De même, l’hypothèse d’un « réseau interne de confiance » est moins solide qu’auparavant, car l’approche « zero-trust » considère qu’aucun emplacement réseau n’est intrinsèquement sûr. Pour tout site public ou traitant des données utilisateur, le protocole HTTPS est la norme et le choix attendu.
Comment Keyfactor vous aider
Le protocole HTTPS ne fonctionne que si les certificats qui le sous-tendent sont valides et fiables, et c'est précisément là que de nombreuses organisations rencontrent des difficultés. La pression s'intensifie : le CA/Browser Forum a décidé de réduire la durée de validité des certificats à 200 jours maximum d'ici 2026, à 100 jours d'ici 2027 et à seulement 47 jours d'ici 2029. Un seul renouvellement manqué peut entraîner la mise hors service d'un site, la perte de confiance des utilisateurs et une détérioration de votre niveau de sécurité. Le suivi manuel ne permet pas de suivre ce rythme.
Keyfactor permet aux équipes de maintenir tous leurs sites en HTTPS sans interruption de service. EJBCA fournit la plateforme permettant de créer les certificats dont dépend TLS , tandis que Bouncy Castle propose une pile complète de services TLS aux développeurs. Côté découverte, AgileSec identifie les ressources cryptographiques et les certificats dans l’ensemble de votre environnement, afin qu’aucun élément ne passe inaperçu. Keyfactor Command gère les certificats à l’échelle de l’entreprise, en assurant le suivi des dates d’expiration et en automatisant leur provisionnement et leur renouvellement, de sorte que la prolifération des certificats et les expirations inattendues appartiennent désormais au passé. Ensemble, ces solutions couvrent l’automatisation du cycle de vie des certificats, PKI, et la découverte cryptographique, et aident les équipes à se préparer à l’ère post-quantique à mesure que les normes évoluent.
Vous vous posez des questions sur HTTP et HTTPS ? Nous avons les réponses.
Quelle est la principale différence entre HTTP et HTTPS ?
Le protocole HTTP transmet les données en clair via le port 80 ; celles-ci peuvent donc être interceptées et lues. Le protocole HTTPS utilise un chiffrement sur le port 443, ce qui brouille les données de sorte que seuls le serveur et le navigateur destinataires puissent les lire. Le protocole HTTPS permet également de vérifier l'identité du serveur.
Le protocole HTTPS est-il simplement une version chiffrée du protocole HTTP ?
Le protocole HTTPS est une version du protocole HTTPqui s'appuie sur une connexion chiffrée et authentifiée. Cette couche garantit la confidentialité, l'authentification du serveur et l'intégrité des données, autant d'éléments que le protocole HTTP standard ne fournit pas.
Comment savoir si un site utilise le protocole HTTPS ?
Regardez dans la barre d'adresse. L'URL d'un site sécurisé commence par « https » et est accompagnée d'une icône représentant un cadenas. En cliquant sur ce cadenas, vous pouvez consulter les détails du certificat du site.
Pourquoi les navigateurs m'affichent-ils des avertissements concernant les sites HTTP ?
Parce que les données transmises via HTTP peuvent être interceptées et lues en clair. Les navigateurs tels que Chrome utilisent désormais le protocole HTTPS par défaut et signalent les pages non sécurisées afin de protéger les utilisateurs contre l'espionnage et le hameçonnage.
Le protocole HTTPS masque-t-il toutes mes activités en ligne ?
Non. Le protocole HTTPS crypte le contenu de vos requêtes, mais certaines informations, telles que l'adresse IP de destination, le nom de domaine que vous visitez, ainsi que le volume et le moment du trafic, peuvent toujours être visibles. Il ne peut pas non plus protéger un appareil qui a déjà été piraté.
Peut-on jamais utiliser le protocole HTTP simple ?
Pour des outils internes isolés ou le développement local ne traitant aucune donnée sensible, le protocole HTTP peut être acceptable. Pour tout site public ou collectant des données utilisateur, le protocole HTTPS est la norme et le choix attendu.
Le protocole HTTPS a-t-il un impact positif sur le référencement naturel (SEO) ?
Oui. Le protocole HTTPS est un facteur de classement positif, et un certificat valide renforce la confiance des utilisateurs ; ces deux éléments favorisent la visibilité dans les résultats de recherche.
Pourquoi le protocole HTTPS est-il fiable ?
Un certificat SSL/TLS délivré par une autorité de certification de confiance atteste de l'identité du site et permet le chiffrement. Le navigateur vérifie ce certificat grâce à une chaîne de confiance remontant jusqu'à une racine de confiance.
