Pourquoi le HTTP est-il remplacé par le HTTPS ?

I. Présentation

HTTP, qui a longtemps été le standard est aujourd’hui voué à disparaître, principalement en rapport à son côté non sécurisé, pouvant parfois amener à exposer certaines informations sensibles, ce qui a conduit les géants du web (Google en tête) à appliquer des mesures contre les sites en HTTP, allant même jusqu’à des malus dans les résultats de recherches.

Mais qu’est-ce que le HTTP ? Comment le sécurise-t-on ? C’est ce que nous allons tenter de voir dans cet article.

II. Le standard du Web

Créé par Tim Berners-Lee et formalisé en 1996 par la RFC 1945 (HTTP/1.0), le protocole a subi plusieurs transformations majeures pour être ce qu’il est aujourd’hui. Le principe de HTTP est l’utilisation des méthodes. Les méthodes sont des commandes qui appellent un type de requêtes au niveau du serveur, parmi les plus classiques, nous avons :

Nom	Description	Exemple
GET	Méthode la plus courante pour demander une ressource	GET /repertoire/page.html HTTP/1.1 Host: www.site.com Connection: Close
HEAD	Méthode servant à demander des informations sur la ressource sans demander la ressource elle-même.	HEAD /fichier.ext HTTP/1.1 Host: www.site.com Connection: Close
POST	Méthode permettant l’envoi de données vers le serveur, comme des formulaires HTML par exemple.	POST /fichier.ext HTTP/1.1 Host: www.site.com Connection: Close Content-type: application/x-www-form-urlencoded Content-Length: 33

Si vous êtes curieux, vous pouvez utiliser la touche F12 lorsque vous êtes sur votre navigateur, sélectionner l’onglet réseau et vous rendre sur n’importe quelle page (ou rafraîchir la page actuelle), vous verrez alors apparaître toutes les méthodes que votre poste envoie au(x) serveur(s).

Bien qu’étant parfaitement fonctionnel, le principal inconvénient de HTTP est son manque de sécurité.

En effet, tout circule en clair sur le réseau ainsi, une personne mal intentionnée peut tout à fait écouter les conversations entre le client et le serveur et récupérer des informations (comme le couple login/mot de passe !). Pour cela, il suffit simplement de « sniffer » le réseau avec un outil de type Wireshark. Si on fait attention aux requêtes « POST » de la part du client, on peut assez facilement récupérer son mot de passe.

Exemple ci-dessous :

Vous en conviendrez, ça n’est pas une condition très sécurisée.

III. La sécurité avant tout !

Pour pallier ce manque de sécurité, l’Internet Society formalise une version sécurisée du protocole à travers la RFC 2818 en 2000. Dans un premier temps, il s’agit de sécuriser les transactions bancaires alors émergentes sur le web, mais petit à petit, ce nouveau protocole s’est imposé sur la toile pour préserver l’authenticité des pages sur tous types de sites web, sécuriser les comptes et garder les communications, l’identité et la navigation privée.

En 2017, Google annonce que sa nouvelle version du navigateur Chrome signalera systématiquement les sites Web non sécurisés (et par la même occasion appliquerons un malus au niveau du référencement), poussant ainsi les webmasters à adopter ce standard.

En mai 2015, la RFC 7540 incorpore une nouvelle norme : le HTTP/2. Pour bénéficier des améliorations de ce standard, cette nouvelle version nécessite en pratique l’implémentation de TLS, ce qui présage une prépondérance de ce standard sur tout le web, même si selon des relevés du service Alexa Top site datant de juillet 2020, seul 26% des 1 million de sites web les plus populaires avaient basculé en HTTP/2.

Note : une nouvelle version (et oui, encore une…) nommée HTTP/3 a été adoptée en 2018, notamment grâce au protocole QUIC développé par Google, nous ne rentrerons pas dans les détails dans cet article.

A. Principe d’une connexion chiffrée

HTTPS signifie « HTTP over TLS » ou encore « HTTP over SSL ». SSL (plus ancien) et TLS (son successeur) sont 2 protocoles de sécurisation de la couche transport. Ils utilisent un couple de clés asymétriques et symétriques (voir plus bas) pour établir une session et garantir l’identité et la sécurité des données.

Le protocole SSL a été développé à l’origine par Netscape. L’IETF en a poursuivi le développement en le rebaptisant Transport Layer Security (TLS). On parle parfois de SSL/TLS pour désigner indifféremment SSL ou TLS. Le protocole SSL est banni en 2014, à la suite de la publication de la faille POODLE, ce bannissement est définitivement ratifié en juin 2015 (RFC 7568).

Concrètement, voici comment se passe une connexion en HTTPS :

• Le client (par le biais du navigateur) envoie une demande de mise en place d’une connexion sécurisée par TLS.
• Le serveur envoie alors son certificat au client
• Le navigateur tente alors de déchiffrer la signature numérique grâce aux certificats qu’il contient
• En cas de réussite, le navigateur génère une clé symétrique (appelée clé de session) qu’il chiffre à l’aide de la clé publique contenue dans le certificat du serveur
• Le serveur déchiffre la clé de session du client grâce à sa clé privée
• Le client et le serveur échangent des données qu’ils chiffrent grâce à la clé de session.
• À la fin de la « conversation », le serveur révoque la clé de session du client

La sécurisation est réalisée avec un chiffrement tel RSA (asymétrique) pour la paire clé publique/privée du serveur et le chiffrement de la clé de session par le client plus un algorithme tel AES (symétrique) pour les échanges de données une fois la session établie. A cela s’ajoute l’utilisation de SHA (fonction de hachage) pour assurer l’intégrité des données.

IV. DNS et certificats

A. La nécessité d’un DNS

Pour avoir un certificat valide, il faut impérativement que celui-ci ait été créé en fonction du site internet qu’il doit sécuriser. Pour rappel, un serveur DNS sert à faire correspondre une adresse IP à un nom, plus facile à retenir pour les humains. Pour ce faire, le serveur DNS contient des enregistrements, ceux-ci comportent d’une part l’adresse IP et d’autre part, ce que l’on appelle le FQDN (Fully Qualified Domain Name) composé du nom de la machine plus le nom de domaine à qui doit correspondre cette IP.

Par exemple, si on prend Google :

Dans un certificat, nous verrons plus tard qu’il existe un champ nommé « CName » qui DOIT contenir le FQDN du serveur, sans quoi le certificat sera refusé.

Par ailleurs, une autorité de certification attribue un certificat liant une clé publique à un nom distinctif (Distinguished Name) ou encore à un nom alternatif (Alternative Name) tel qu’une adresse électronique ou un enregistrement DNS.

B. Rôle des certificats

Un certificat électronique regroupe un ensemble de données servant essentiellement à garantir :

• La non-répudiation et l’intégrité des données avec la signature numérique ;
• La confidentialité des données grâce au chiffrement des données ;
• L’authentification d’un individu ou d’une identité numérique

Il est composé d’une clé publique, d’informations d’identité (nom, localisation, etc.) ainsi qu’une signature numérique crée à partir d’un condensat des informations précédentes chiffrées par la clé privée de l’autorité de certification (CA).

À l’heure actuelle, les certificats connaissent diverses implémentations : sites web, messagerie électronique, SSH, VPN, etc.

C. Types de certificats

Actuellement, il existe deux types de certificats électroniques, tous deux régis par des normes.

Le premier, le X.509 est le plus prépondérant dans le domaine des sites web, normalisé par la RFC 5280, il fait partie de ce qu’on appelle la PKI (Public Key Infrastructure).

Le certificat X.509 est signé par une autorité de certification qui diffuse toujours sa clé publique (d’où le « PK » de PKI). Chaque client va calculer un condensat (hash) du certificat, cette clé publique permet de déchiffre le condensat fait par l’autorité de certification. Si les deux sont identiques, alors ont peut garantir l’intégrité du certificat. La clé publique de l’autorité de certification est elle-même contenue dans un certificat qui peut être signé à son tour par une autorité de certification supérieure, on parle alors de certificat intermédiaire, le tout formant une chaîne de certification (d’où le « I » de PKI). Tout en haut de la chaîne, on trouve les certificats les plus importants : les certificats racines.

Les certificats racines représentent les autorités suprêmes de confiance, leurs certificats sont enregistrés dans nos navigateurs et clients web pour permettre la validation automatique des certificats des sites que l’on visite. Si j’affiche le certificat de Google par exemple, je constate ceci :

On voit le certificat (www.google.com), le certificat intermédiaire (GTS CA 101) qui est l’autorité de certification de Google et enfin le certificat racine de GlobalSign. Donc en gros, GlobalSign fait confiance à GTS qui fait confiance à google.com; comme votre navigateur fait confiance à GlobalSign, alors tout va bien.

Si l’autorité de certification n’est pas connue, alors votre navigateur vous enverra un avertissement vous prévenant qu’il ne peut assurer l’identité du site ni faire confiance à son certificat, c’est ce qui arrive par exemple lors de l’utilisation de certificats auto-signés, où aucune autorité de certification n’a validé celui-ci (en gros, on a attesté nous même qu’on est bien celui qu’on prétend être).

Le deuxième type de certificat est OpenPGP, plus utilisé dans les échanges de mails.

Défini dans la RFC 4880, ce type de certificat est surtout utilisé dans le chiffrement et l‘authentification des e-mails. Toutefois, la RFC 5081 prévoit également l’utilisation d’OpenPGP pour le protocole TLS bien que la RFC 5246 (qui concerne TLS) définit X.509 comme standard. Ce standard est très utilisé dans la communauté Linux, comme par exemple pour le projet Debian où chaque développeur qui souhaite se joindre au projet doit s’identifier en fournissant une clé OpenPGP signée par au moins deux membres du projet. Les contributions sont aussi signées avec la clé OpenPGP du développeur, protégeant ainsi les utilisateurs des falsifications.

V. Certificats auto-signés et certificats payants

Pour pouvoir assurer une identité formelle, il est nécessaire à un moment ou à un autre de faire appel à un tiers qui pourra confirmer l’identité en question et nous assurer de son origine, c’est le rôle d’une Autorité de Certification. Une autorité de certification délivre des certificats décrivant des identités numériques et met à disposition les moyens de vérifier la validité des certificats qu’elle a fournis.

Voici les étapes de la création du certificat :

1. Le serveur qui hébergera le site internet génère une clé publique, une clé privée puis envoie à une Autorité de Certification une demande de signature de certificat (en anglais CSR : Certificate Signing Request) contenant sa clé publique ainsi que des informations sur son identité (coordonnées postales, téléphoniques, email…).
2. Une fois l’identité du demandeur vérifiée par une autorité d’enregistrement (RA), l’Autorité de Certification signe le CSR grâce à sa propre clé privée (et non pas avec la clé privée de la personne donc) qui devient alors un certificat puis le transmet en retour à la personne qui en a fait la demande.
3. Le certificat est alors intégré dans le serveur web du demandeur. Lorsqu’un utilisateur se connecte à ce serveur web, celui-ci lui transmet à son tour le certificat fourni précédemment par l’Autorité de Certification.
4. Le navigateur vérifie les informations

Toutes ces étapes se passent lorsque le site en question a fait appel à une autorité de certification dans le cadre d’un certificat payant. Toutefois, ce type de certificat est onéreux et il est fréquent que les personnes utilisant un serveur web utilisent des certificats auto-signés, à ce moment-là, tout se passe sur la même machine.

Il est déconseillé d’utiliser un certificat auto-signé pour un site internet visible sur le web. Il peut en revanche être intéressant de l’utiliser dans un cadre local ou pour tester son site dans des conditions d’utilisation au plus proche de la réalité.

VI. Conclusion

Dans cet article, nous avons vu comment Internet est passé d’une version non sécurisée à une version utilisant les certificats et les PKI pour assurer à la fois l’identité de la source, le chiffrement des échanges et l’intégrité des données.

Nul doute que dans les années à venir verront de nombreux changements, à commencer par HTTP/3 et le protocole QUIC qui va quelque peu bouleverser les communications sur Internet tel que nous les connaissons aujourd’hui.