Pourquoi HTTP n'est-il pas sécurisé ? | HTTP contre HTTPS

HTTP vs HTTPS : Quelles sont les différences ?

HTTPS est HTTP avec cryptage et vérification.La seule différence entre les deux protocoles est que HTTPS utilise TLS (SSL) pour chiffrer les demandes et les réponses HTTP normales, et pour signer numériquement ces demandes et ces réponses.Par conséquent, le protocole HTTPS est beaucoup plus sûr que le protocole HTTP. Un site web qui utilise le protocole HTTP a http:// dans son URL, tandis qu'un site web qui utilise le protocole HTTPS a https://.

Qu’est-ce que HTTP ?

HTTP signifie Hypertext Transfer Protocol. C'est un protocole (c'est-à-dire un ordre et une syntaxe prescrits pour présenter des informations) utilisé pour transférer des données sur un réseau. La plupart des informations envoyées sur Internet, y compris le contenu du site Web et les appels d'API, utilisent le protocole HTTP. Il existe deux principaux types de messages HTTP : les requêtes et les réponses.

Dans le modèle OSI (voir Qu'est-ce que le modèle OSI ?), HTTP est un protocole de la couche 7.

Qu'est-ce qu'une requête HTTP ? Qu'est-ce qu'une réponse HTTP ?

Les requêtes HTTP sont générées par le navigateur d'un utilisateur lorsque l'utilisateur interagit avec les propriétés web. Par exemple, si un utilisateur clique sur un lien hypertexte, le navigateur enverra une série de requêtes HTTP GET pour le contenu qui apparaît sur cette page. Si un internaute recherche dans Google « Qu'est-ce que HTTP ? » et que cet article apparaît dans les résultats de la recherche, lorsqu'il clique sur le lien, son navigateur crée et envoie une série de requêtes HTTP afin d'obtenir les informations nécessaires au rendu de la page.

Ces requêtes HTTP vont toutes à un serveur d'origine ou à un serveur de mise en cache proxy qui va générer une réponse HTTP. Les réponses HTTP sont des réponses aux requêtes HTTP.

À quoi ressemble une requête HTTP typique ?

Une requête HTTP n'est qu'une série de lignes de texte qui suivent le protocole HTTP. Une demande GET pourrait ressembler à ceci :

GET /hello.txt HTTP/1.1
User-Agent : curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host : www.example.com
Accept-Language : en

Cette section de texte, générée par le navigateur de l'utilisateur, est envoyée via Internet. Le problème est qu'il est envoyé sous cette forme, avec un texte en clair que toute personne surveillant la connexion peut lire (ceux qui ne connaissent pas le protocole HTTP peuvent trouver ce texte difficile à comprendre, mais quiconque ayant des connaissances basiques sur les commandes et la syntaxe du protocole peut le lire facilement).

Cela est particulièrement problématique lorsque les utilisateurs soumettent des données sensibles via un site web ou une application web. Il peut s'agir d'un mot de passe, d'un numéro de carte de crédit ou de toute autre donnée entrée dans un formulaire. En HTTP toutes ces données sont envoyées en clair et n'importe qui peut les lire (lorsqu'un utilisateur soumet un formulaire, le navigateur le traduit en une requête HTTP POST au lieu d'une requête HTTP GET).

Lorsqu'un serveur d'origine reçoit une requête HTTP, il envoie une réponse HTTP, qui est similaire :

HTTP/1.1 200 OK
Date : Wed, 30 Jan 2019 12:14:39 GMT
Server : Apache
Last-Modified : Mon, 28 Jan 2019 11:17:01 GMT
Accept-Ranges : bytes
Content-Length : 12
Vary : Accept-Encoding
Content-Type : text/plain

Hello World !

Si un site web utilise HTTP au lieu de HTTPS, toutes les requêtes et réponses peuvent être lues par une personne quelconque qui surveillerait la session. En fait, un acteur malveillant peut simplement lire le texte de la requête ou de la réponse et savoir exactement quelles informations une personne demande, envoie ou reçoit.

Qu'est-ce que HTTPS ?

Le S de HTTPS signifie « sécurisé ». HTTPS utilise TLS (ou SSL) pour chiffrer les requêtes et réponses HTTP, donc dans l'exemple ci-dessus, au lieu du texte, un attaquant verrait une série de caractères apparemment aléatoires.

Au lieu de :

GET /hello.txt HTTP/1.1
User-Agent : curl/7.63.0 libcurl/7.63.0 OpenSSL/1.1.l zlib/1.2.11
Host : www.example.com
Accept-Language : en

L'attaquant voit quelque chose comme :

t8Fw6T8UV81pQfyhDkhebbz7+oiwldr1j2gHBB3L3RFTRsQCpaSnSBZ78Vme+DpDVJPvZdZUZHpzbbcqmSW1+3xXGsERHg9YDmpYk0VVDiRvw1H5miNieJeJ/FNUjgH0BmVRWII6+T4MnDwmCMZUI/orxP3HGwYCSIvyzS3MpmmSe4iaWKCOHQ==

En HTTPS, comment TLS/SSL chiffre t-il les requêtes et les réponses HTTP ?

TLS utilise une technologie appelée cryptographie à clé publique : il existe deux clés, une clé publique et une clé privée. La clé publique est partagée avec les appareils clients via le certificat SSL du serveur. Lorsqu'un client ouvre une connexion avec un serveur, les deux appareils utilisent la clé publique et privée pour convenir de nouvelles clés, appelées clés de session, pour chiffrer la suite de leurs échanges.

Toutes les demandes et réponses HTTP sont ensuite chiffrées avec ces clés de session, de sorte que toute personne qui intercepte les communications ne peut voir qu'une chaîne de caractères aléatoire, et non le texte en clair.

Pour en savoir plus sur le fonctionnement du chiffrement et des clés, voir Qu'est-ce que le chiffrement ?

Comment HTTPS aide-t-il à authentifier les serveurs Web ?

L'authentification signifie la vérification qu'une personne ou une machine est bien celle qu'elle prétend être. En HTTP, il n'y a pas de vérification d'identité : le protocole est basé sur un principe de confiance. Les architectes de HTTP n'ont pas nécessairement décidé de faire implicitement confiance à tous les serveurs web. Simplement des priorités autres que la sécurité existaient à l'époque. Mais sur l'Internet moderne, l'authentification est essentielle.

Tout comme une carte d'identité confirme l'identité de son détenteur, une clé privée confirme l'identité du serveur. Lorsqu'un client ouvre un canal avec un serveur d'origine (par exemple, lorsqu'un utilisateur accède à un site web), la possession de la clé privée qui correspond à la clé publique dans le certificat SSL d'un site web prouve que le serveur est en fait l'hôte légitime du site web. Cela empêche ou aide à bloquer un certain nombre d'attaques possibles en l'absence d'authentification, telles que :

• Attaques de l'homme du milieu (on-path)
• Le détournement du DNS
• Le détournement BGP
• L'usurpation de domaine

En outre, le certificat SSL est signé numériquement par l'autorité de certification qui l'a émis. Cela permet de confirmer que le serveur est bien celui qu'il prétend être.

Comment Cloudflare permet-il aux sites web d'adopter le HTTPS ?

Cloudflare a publié Universal SSL en 2014 et a été la première société à proposer la gratuité des certificats SSL. Tout site Web inscrit aux services de Cloudflare peut activer HTTPS et abandonner HTTP en un seul clic. Cela rend le chiffrement TLS largement disponible, pour protéger les utilisateurs et les données des utilisateurs partout sur Internet.

Pour en savoir plus sur HTTP et HTTPS, voir Qu'est-ce qu'un contenu mixte ? Pour vérifier qu'un site Web propose HTTPS, visitez le Cloudflare Diagnostic Center.