Hypertext Transfer Protocol Secure

protocole réseau
(Redirigé depuis HTTPS)

L'Hypertext Transfer Protocol Secure (HTTPS, littéralement « protocole de transfert hypertextuel sécurisé ») est la combinaison du HTTP avec une couche de chiffrement TLS[3].

Hypertext Transfer Protocol Secure
Logiciel
Début d'une adresse web HTTPS dans la barre d'adresse d'un navigateur web.
Informations
Fonction Transmission d'hypertexte
Sigle HTTPS
Date de création 1994[1]
Port 443
RFC 2000 : RFC 2818[2]
Dans la plupart des navigateurs web, les adresses HTTPS sont indiquées par une icône représentant un cadenas.

HTTPS permet au visiteur de vérifier l'identité du site web auquel il accède, grâce à un certificat d'authentification émis par une autorité tierce, réputée fiable (et faisant généralement partie de la liste blanche des navigateurs internet et des systèmes d'exploitation). Il garantit théoriquement la confidentialité et l'intégrité des données envoyées par l'utilisateur (notamment des informations entrées dans les formulaires) et reçues du serveur. Il peut permettre de valider l'identité du visiteur, si celui-ci utilise également un certificat d'authentification client émis par une autorité fiable.

HTTPS est aussi utilisé pour la consultation de données privées, comme les courriers électroniques, par exemple.

En 2016, une campagne de l'Electronic Frontier Foundation, soutenu par les développeurs de navigateurs Web, a aidé à rendre le protocole beaucoup plus populaire[4]. HTTPS est maintenant utilisé plus souvent par les utilisateurs Web que le HTTP non sécurisé d'origine, principalement pour protéger l'authenticité des pages sur tous les types de sites Web, comptes sécurisés, et pour garder les communications des utilisateurs, l'identité et la navigation Web privées[5].

Depuis le début des années 2010, le HTTPS s'est également généralisé sur les réseaux sociaux.

Par défaut, les serveurs HTTPS sont connectés au port TCP 443. C'est un port très souvent ouvert derrière les pare-feux.

En , Google Chrome et Mozilla Firefox ont commencé à identifier et signaler les sites Web qui recueillent des informations sensibles sans utiliser le protocole HTTPS[6]. Ce changement a pour but d'augmenter de manière significative l'utilisation du HTTPS. En , le protocole de sécurité HTTPS était utilisé par environ 16,28 % de l'Internet français[7]. Depuis 2020, le protocole est utilisé dans 80% des pages Web chargées[8].

Historique

modifier

Netscape créa le HTTPS en 1994 pour son navigateur Netscape Navigator. HTTPS était initialement utilisé avec le protocole SSL, ce dernier ayant évolué vers TLS, HTTPS utilise maintenant TLS. Ceci est spécifié dans la RFC 2818 en .

Google annonça en que son navigateur afficherait les sites HTTP comme « non sécurisés » à partir du mois de [9]. Cela précipita l'adoption d'HTTPS par les sites web afin d'éviter une perte de trafic.

Certificat HTTPS

modifier

Les certificats HTTPS sont émis par des autorités de certification. Depuis le milieu des années 2000 et les révélations d'Edward Snowden, de nombreuses entités se sont mis à proposer des certificats HTTPS gratuitement pour sécuriser le Web. L'obtention de certificats sont soumis notamment au protocole ACME. Pour obtenir un certificat, il faut créer un CSR contenant les informations sur le site Internet et la clé générée par le site Internet pour sécuriser la connexion. Après validation de la propriété du site Internet, l'autorité signe le CSR, délivrant un certificat valide, lorsqu'il est associé à la clé privée utilisée dans le CSR. Cette technique empêche l'autorité d'avoir accès à la clé privée (le CSR ne contient pas cette clé) et donc de lire le trafic des sites Internet dont elle a autorité mais permet de prouver que le site Internet demandeur du certificat possède bien la clé privée (preuve de possession).

Un certificat a une durée de vie (entre 90 jours et 1 an) mais qui est très souvent de 3 mois et qui permet le renouvellement automatique de la clé privée et du certificat. Un certificat peut aussi être révoqué par l'autorité de certification si sa clé privée a été compromise.

Principe de fonctionnement

modifier

Description informelle : Le protocole est identique au protocole web habituel HTTP, mais avec un ingrédient supplémentaire dit TLS qui fonctionne assez simplement ainsi :

  • le client — par exemple le navigateur Web — contacte un serveur — par exemple Wikipédia — et demande une connexion sécurisée, en lui présentant un certain nombre de méthodes de chiffrement de la connexion (des suites cryptographiques) ;
  • le serveur répond en confirmant pouvoir dialoguer de manière sécurisée et en choisissant dans cette liste une méthode de chiffrement et surtout, en produisant un certificat garantissant qu'il est bien le serveur en question et pas un serveur pirate déguisé (on parle de l'homme du milieu).
    Ces certificats électroniques sont délivrés par une autorité tierce (autorité de certification) à laquelle le client comme le serveur ont choisi de faire confiance, un peu comme un notaire dans la vie courante, et le client peut vérifier, grâce à la signature de cette autorité sur le certificat présenté par le serveur, que celui-ci est authentique. Le client s’assure par ailleurs que le certificat n’est pas périmé et aussi éventuellement que l’autorité de certification ne l’a pas révoqué.
    Le certificat contient aussi une clé dite publique qui permet de chiffrer un message pour le rendre secret et uniquement déchiffrable par le serveur grâce à une clé dite privée que seul le serveur détient, on parle de chiffrement asymétrique.
  • cela permet au client d'envoyer de manière secrète un code aléatoire qu’il invente (une clé symétrique dite clef de session) qui sera mélangé à tous les échanges entre le serveur et le client de façon que tous les contenus de la communication soient chiffrés. Pour cela on mélange le contenu avec le code, ce qui donne un message indéchiffrable, et à l'arrivée refaire l’opération symétrique avec ce message redonne le contenu en clair.

En bref : serveur et client se sont reconnus, ont choisi une manière de chiffrer la communication et se sont passés de manière chiffrée un code (clé de chiffrement symétrique) pour dialoguer de manière secrète.

HTTPS et piratage

modifier

La sécurité des informations transmises par le protocole HTTPS est basée sur l'utilisation d'un algorithme de chiffrement, et sur la reconnaissance de validité du certificat d'authentification du site visité.

Partant du principe que les internautes précisent rarement le type de protocole dans les URL (le protocole HTTP étant historiquement sélectionné par défaut) et se contentent de suivre des liens, un chercheur en sécurité informatique, connu sous le pseudonyme de Moxie Marlinspike, a développé une attaque du type Attaque de l'homme du milieu (« Man in the middle » en anglais), afin de contourner le chiffrement de HTTPS[10]. Le pirate se positionne entre le client et le serveur et change les liens https: en http:, ainsi le client envoie ses informations en clair via le protocole HTTP et non HTTPS[11]. Ce type d'attaque a été présenté par Marlinspike à la Blackhat Conference 2009. Durant cette conférence, Marlinspike a non seulement présenté le fonctionnement de l'attaque, mais également quelques statistiques d'utilisation. Il a réussi à récupérer plusieurs centaines d'identifiants, informations personnelles et numéros de cartes bancaires en 24 heures, aucune personne ne se doutant de l'attaque en cours[10].

Une autre attaque de type Man in the middle a pu être mise en œuvre en juillet 2011[12], par l'obtention frauduleuse de certificats valides auprès de l'ancienne autorité de certification DigiNotar, piratée. Cette attaque fut utilisée pour mettre en place de faux sites Google (certificat frauduleux pour les domaines *.google.com) et ainsi espionner la consultation de plusieurs comptes Gmail d'utilisateurs iraniens.

En septembre 2011, Duong et Rizzo, deux chercheurs en sécurité informatique, ont présenté à la Ekoparty Security Conference un nouveau type d'attaque, basé cette fois sur le décryptage des paquets transmis sur le réseau. Cette attaque utilise une vulnérabilité du chiffrement Cipher Block Chaining du protocole TLS 1.0, connue de longue date. Pour exploiter cette vulnérabilité, il s'agit d'insérer dans la page consultée un code Javascript communiquant la valeur du cookie de session à un analyseur de paquets réseau, afin de l'utiliser pour décrypter le reste de la communication[13].

Seuls les sites supportant la version de chiffrement TLS 1.0 sont affectés par cette vulnérabilité ; cependant à la date de , cela concerne l'immense majorité des sites du fait de la réticence des sites et navigateurs à mettre en application les versions TLS 1.1 et 1.2[14].

HTTPS et NSA

modifier

En , plusieurs journaux révèlent, grâce aux documents fournis par Edward Snowden, que la NSA, via son programme Bullrun, cherche à casser ou affaiblir le protocole HTTPS ou ses mises en œuvre par les constructeurs de matériel et de logiciel, rendant accessible en clair aux services américains de nombreuses communications pourtant chiffrées[15].

Début 2014, une vulnérabilité visant tous les appareils Apple sous iOS 6 / 7 et Mac OS X 10.9, permettant à ceux qui ont eu le moyen de l'exploiter, de corrompre le chiffrement HTTPS (ou plus particulièrement les technologies TLS / SSL), a été corrigée par la firme[16]. Certaines rumeurs laissent entendre que cette vulnérabilité aurait été utilisée par la NSA[17], voire que c'est l'organisation gouvernementale qui a sollicité l'aide d'Apple pour créer cette faille (ce que l'entreprise dément)[18].

HTTP Strict Transport Security (HSTS) est un mécanisme de politique de sécurité proposé, permettant à un serveur web de déclarer à un agent utilisateur (comme un navigateur web) compatible, qu'il doit interagir avec lui en utilisant une connexion sécurisée (comme HTTPS). La politique est donc communiquée à l'agent utilisateur par le serveur, via la réponse HTTP, dans le champ d'entête nommé « Strict-Transport-Security ». La politique spécifie une période de temps durant laquelle l'agent utilisateur doit accéder au serveur uniquement de façon sécurisée.

HTTPS et cache intermédiaire

modifier

Le HTTPS du fait qu'il est chiffré ne permet pas à un serveur intermédiaire d'avoir une mémoire cache qui mémorise l'information. De ce fait, le navigateur ne peut pas afficher l'information sans la demander directement au serveur.

Pour cette raison, certains serveurs intermédiaires comme Cloudflare émettent des certificats pour les sites qu'ils gèrent avec leur clé privée ce qui leur permet d'obtenir le trafic en clair et de le contrôler[19].

Notes et références

modifier

Références

modifier
  1. « Introduction to SSL », sur Google Livre, (consulté le )
  2. (en) « HTTP Over TLS », Request for comments no 2818,
  3. Les chiffrement SSL sont obsolètes depuis plusieurs années et seul TLS est maintenant utilisé.
  4. (en) « Encrypting the Web », sur Electronic Frontiers Foundation, (consulté le )
  5. (en) « HTTP, HTTPS, SSL Over TLS », (consulté le )
  6. (en-US) « Moving towards a more secure web », Google Online Security Blo,‎ (lire en ligne, consulté le )
  7. « Statistiques sur l'internet français. udomo.fr », sur www.udomo.fr (consulté le )
  8. « Statistiques sur Let's Encrypt - Let's Encrypt - Certificats SSL/TLS gratuits », sur letsencrypt.org (consulté le )
  9. « A secure web is here to stay » [archive du ], sur Chromium Blog (consulté le )
  10. a et b https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf.
  11. « Blog », sur orange-business.com (consulté le ).
  12. Dan Goodin, « Hackers break SSL encryption used by millions of sites », sur theregister.co.uk, (consulté le ).
  13. « Des hackers cassent le chiffrement SSL utilisé par des millions de sites », sur journaldunet.com (consulté le ).
  14. Dan Goodin, « Hackers break SSL encryption used by millions of sites », sur theregister.co.uk, (consulté le ).
  15. Le Monde.fr, « Affaire Snowden : comment la NSA déjoue le chiffrement des communications », sur Le Monde.fr, (consulté le ).
  16. « Pourquoi la faille "goto fail" des OS d'Apple est très grave », Journal du net,‎ (lire en ligne)
  17. Olivier, « Goto fail : après iOS, Apple bouche enfin la faille SSL sur OS X », Journal du geek,‎ (lire en ligne)
  18. (en) Charles Arthur, « Apple's SSL iPhone vulnerability: how did it happen, and what next? », The Guardian,‎ (lire en ligne)
  19. (en) « SSL FAQ · Cloudflare Support docs », sur developers.cloudflare.com, (consulté le )

Voir aussi

modifier

Articles connexes

modifier

Liens externes

modifier

  NODES
Done 1