La sécurisation des communications : HTTPS

icône de pdf
Signaler

Assurer la sécurité des machines reliées à Internet c’est être sûr de l’identité de la machine distante, sécuriser les échanges, limiter l’accès à certaines données. L’une des solutions possibles est la mise en œuvre du protocole HTTPS.

I. Le chiffrement symétrique

Depuis l’antiquité, les êtres humains ont cherché à sécuriser leurs communications, notamment dans le domaine militaire. Le code le plus connu est celui de Jules César, plus techniquement dénommé chiffrement par décalage : on décale en effet chaque lettre de l’alphabet d’un certain nombre de rangs fixe qui est appelé la clé de chiffrement. Par exemple avec la clé 3, A devient D, B devient E, etc.

Cette clé doit rester secrète car sa connaissance permet de déchiffrer un message. C’est l’un des inconvénients des chiffrements symétriques. Même si la clé est gardée secrète, un chiffrement symétrique doit avoir une clé suffisamment compliquée pour ne pas être attaquée. Dans le cas du chiffrement par décalage, il y a 25 clés possibles ce qui n’est pas compliqué à attaquer par force brute.

Mot-clé

Effectuer une attaque par force brute signifie ici essayer toutes les clés possibles sans stratégie jusqu’à trouver la clé.

Le standard actuel, AES (Advanced Encryption Standard), a une clé qui peut avoir une taille allant jusqu’à 256 bits ce qui laisse 2256 possibilités soit environ 1077 clés à tester ! Les attaques, alors, ne se portent pas sur le message lui-même mais sur les machines qui implémentent le programme de chiffrement.

II. Le chiffrement asymétrique

Pour résoudre le problème d’échange de la clé secrète, Whitfield Diffie et ­Martin Hellman présentèrent en 1976 le principe d’un chiffrement à clé publique.

Résumons comment un utilisateur Albert peut envoyer un message à Barbara :

Barbara fabrique un cadenas (sa clé publique) et une clé pour l’ouvrir (sa clé privée). Le cadenas doit être suffisamment compliqué pour ne pas être ouvert sans clé. La clé privée n’est connue que de Barbara.

Barbara envoie en clair sa clé publique à Albert (son cadenas ouvert) : tout le monde peut la voir.

Albert utilise la clé publique pour chiffrer son message (il enferme son message dans une boîte fermée avec le cadenas). Connaître la clé publique ne suffit pas à déchiffrer le message sans connaître la clé privée (contempler le cadenas ne suffit pas à l’ouvrir sans clé).

Barbara ouvre le cadenas avec sa clé privée qui n’a pas quitté son bureau donc n’a pas pu être interceptée.

6b8b0719-6559-42d3-8fa7-c0f03b2e3a00

Deux ans plus tard, en 1978, Ronald Rivest, Adi Shamir et Leonard Adleman mettent ce principe en pratique. Ils proposent un algorithme qui porte leurs initiales, RSA, largement utilisé de nos jours, et qui utilise des théorèmes d’arithmétique bien connus, notamment le petit théorème de Fermat (étudié par les élèves ayant choisi l’option maths expertes).

III. Le protocole HTTPS

L’échange de données par le protocole HTTP présente plusieurs failles dont les principales sont :

les données transitent en clair et peuvent être lues par un tiers ;

un tiers peut se faire passer pour le serveur et recevoir les données transmises par le client.

Le protocole SSL, qui a évolué en TLS, permet, au niveau de la couche de session – couche 5 du modèle OSI, de combler ces deux failles.

Décrivons le protocole HTTPS en considérant un échange entre un client et un serveur selon le protocole HTTP mais avec quelques ajouts :

Le client envoie une demande de connexion sécurisée au serveur (Hello).

Le serveur envoie alors sa clé publique (asymétrique) et sa signature.

Le client vérifie la signature en faisant appel à des autorités de certification (CA, certificate authorities) extérieures.

Après vérification que le serveur n’est pas frauduleux, le client génère une clé de chiffrement symétrique (AES), sa clé de session, et la chiffre avec la clé publique du serveur. Elle transite donc en toute sécurité.

Le serveur reçoit donc la clé symétrique en toute sécurité. C’est la fin de la phase de poignée de main (handshake) entre client et serveur.

Client et serveur peuvent maintenant s’échanger « rapidement » des données en utilisant la clé de session qu’ils sont les seuls à connaître.

On trouve le même type d’utilisation de TLS pour sécuriser l’échange d’emails.