6.3. Sécurisation avec HTTPS
6.3.1. Principes d’HTTPS et de TLS
Pour pouvoir authentifier les intervenants dans une conversation HTTP et chiffrer les données échangées, on peut utiliser le protocole TLS : Transport Layer Security. Le HTTPS n’est rien d’autre que la sécurisation du HTTP par du TLS.
Le protocole TLS est une évolution standardisée par l’IETF du protocole SSL, développé à l’origine pour le navigateur Netscape. C’est un protocole qui intervient au dessus de la couche Transport, et permet de sécuriser les échanges applicatifs. Il peut être utilisé pour sécuriser le HTTP, mais également les protocoles SMTP, FTP, POP, IMAP, ou même le DNS.
Pour garantir l’authentification du client et/ou du serveur, TLS utilise la cryptographie asymétrique : la clé publique d’un intervenant sera utilisée pour déchiffrer un message/challenge généré sur base de sa clé privée. Comme nous l’avons vu dans le cadre du DNSSEC, il faut néanmoins garantir l’authenticité de cette clé, via l’utilisation d’une chaîne de confiance. Avec TLS, un système de certificat (clé publique signée par une autorité de certification) est utilisé, comme nous le verrons plus loin.
Quant à la confidentialité, elle sera assurée par de la cryptographie symétrique. Cette dernière est plus performante que la cryptographie asymétrique, mais nécessite un secret partagé. L’échange de la clé partagée sera réalisé à l’aide de la cryptographie asymétrique.
6.3.2. Détails de l’échange TLS
Dans sa version 1.2, TLS nécessite deux aller-retours entre le client et le serveur pour établir la connexion sécurisée, et pouvoir commencer à échanger des données chiffrées :
- Un premier aller-retour avec un échange de messages ClientHello et ServerHello : ces derniers servirons à l’échange de certificats, et permettront de se mettre d’accord sur la technique et les algorithmes de chiffrement utilisés.
- Le second aller-retour servira à la génération et à l’échange de la clé secrète pour le chiffrement symétrique.
La version 1.3. de TLS simplifie cet échange afin que le chiffrement puisse s’établir en un aller-retour (RTT), ce qui permet d’augmenter les performances du HTTPS.
Dans sa version 1.2, TLS nécessite deux aller-retours entre le client et le serveur pour établir la connexion sécurisée, et pouvoir commencer à échanger des données chiffrées :
- Un premier aller-retour avec un échange de messages ClientHello et ServerHello : ces derniers servirons à l’échange de certificats, et permettront de se mettre d’accord sur la technique et les algorithmes de chiffrement utilisés.
- Le second aller-retour servira à la génération et à l’échange de la clé secrète pour le chiffrement symétrique.
La version 1.3. de TLS simplifie cet échange afin que le chiffrement puisse s’établir en un aller-retour (RTT), ce qui permet d’augmenter les performances du HTTPS.
6.3.3. Certificats et chaîne de confiance
L’authentification dans un système utilisant des clés publiques n’a de sens que s’il existe une chaîne de confiance permettant de garantir qu’une clé publique appartient bien à la personne qui la revendique. Nous avons déjà vu un tel système dans le cadre du DNSSEC .
Dans le cadre du TLS, les clés publiques seront certifiées par des autorités de certification. Comme déjà expliqué, une signature s’effectue en calculant un hash sur l’élément à signer (ici, la clé publique). L’autorité de certification signe ensuite ce hash avec sa clé privée, et cette signature est ajoutée à la clé publique et encodée sous forme de certificat signé au format X.509.
La vérification du certificat peut s’effectuer en utilisant la clé publique de l’autorité de certification.
Cette dernière devant également être vérifiée, l’autorité de certification elle-même est signée par une autre autorité de certification, et ainsi de suite jusqu’à une autorité de certification racine, bien connue, et dont les navigateurs possèdent nativement la clé publique.
La demande d’un certificat peut se faire manuellement, en contactant une autorité de certification par email, téléphone ou formulaire web. La procédure implique alors de prouver qu’on est bien propriétaire du domaine pour lequel on souhaite un certificat.
Pour faciliter cette procédure, un protocole de demande automatique de certificat (ACME) a été créé par l’Internet Security Research Group (ISRG), et consiste à utiliser un client à installer sur le serveur web pour lequel un certificat est requis. Ce client génère la demande, et répond à des challenges envoyé par l’autorité de certification pour prouver la propriété du domaine. Ces challenges peuvent se baser sur le service HTTP, ou bien sur le DNS.
Cette procédure est illustrée dans la figure ci-dessous, issue de l’article de Aas et al de 2019 ( Let’s Encrypt: An Automated Certificate Authority to Encrypt the Entire Web)
L’implémentation cliente de référence pour ce protocole ACME est l’outil certbot. Il permet une mise en oeuvre rapide de la configuration d’HTTPS et de l’obtention d’un certificat, notamment auprès de l’autorité de certification Let’s Encrypt, qui fournit des certificats gratuitement.