Fonctionnement général

Handshake

La négociation TLS, plus communément appelée handshake, est l'opération qui va précéder toute connexion sur un serveur. C'est un moment décisif car c'est ce moment qui va déterminer si le client peut échanger avec le serveur ou non. Le chiffrement de la négociation est asymétrique. Cela signifie qu'il y a une clé différente pour chiffrer et déchiffrer des données. En d'autres termes il est impossible de déchiffrer des données avec la même clé que celle qui a été utilisée pour les chiffrer.
Le serveur possède donc ces 2 clés sur son système. La clé publique va être partagée avec les clients afin de chiffrer la connexion tandis que la clé privée sera conservée bien précieusement afin de déchiffrer les requêtes des clients.

Ce processus se déroule en plusieurs étapes, les plus importantes étant les suivantes :

Le serveur envoie sa clé publique au client. De par sa nature, cette dernière n'est pas chiffrée et est identique à tous les clients qui vont communiquer avec ce serveur. Elle permet donc uniquement de chiffrer les données. À ce stade, le seul à pouvoir déchiffrer quoi que ce soit, c'est le serveur ! Le client va donc souhaiter comprendre à son tour les requêtes du serveur. Ils vont donc tout d'abord échanger quelques informations utiles, sans aucun chiffrement, telles que la version du protocole TLS ou encore les différents algorithmes de chiffrement compatibles. Cela va leur permettre de s'accorder pour assurer une communication claire.
Afin d'atteindre son objectif, le client va à son tour créer une clé de chiffrement, dite clé de session qui va cette fois permettre un chiffrement symétrique. Cela signifie qu'elle sera utilisée à la fois pour chiffrer et déchiffrer les données. Elle ne doit donc en aucun cas être diffusée publiquement.
Seulement, le serveur aura besoin d'avoir en sa possession cette clé de session. Afin de la transmettre sans risque qu'un intrus l'intercepte durant la communication, le client va utiliser la clé publique du serveur précédemment reçue afin de chiffrer sa propre clé de session avant de la transmettre au serveur qui sera à même de l'interpréter correctement grâce à sa propre clé privée. Une personne qui arriverait à capter cette communication recevrait donc une clé inutilisable puisqu'il serait incapable de la déchiffrer.

Algorithme de Diffie-Hellman

En plus des clés publiques et privées, le protocole TLS peut utiliser l'algorithme de Diffie-Hellman pour établir des clés de session de manière sécurisée. Cet algorithme permet à deux parties de générer une clé de chiffrement partagée sur un canal non sécurisé. Voici comment cela fonctionne dans le cadre de TLS :

Le client et le serveur génèrent chacun un ensemble de clés publiques et privées Diffie-Hellman.
Le client envoie sa clé publique Diffie-Hellman au serveur.
Le serveur envoie sa clé publique Diffie-Hellman au client.
Les deux parties utilisent leurs propres clés privées et la clé publique de l'autre partie pour calculer une clé de session partagée.

Cette clé de session partagée est ensuite utilisée pour chiffrer les communications ultérieures. L'algorithme de Diffie-Hellman est particulièrement utile car il permet d'établir une clé de session sans jamais transmettre la clé elle-même sur le réseau, ce qui améliore la sécurité.

Perfect Forward Secrecy (PFS)

Une autre fonctionnalité cruciale de TLS est la Perfect Forward Secrecy (PFS). PFS garantit que même si les clés privées du serveur sont compromises, les sessions précédentes ne peuvent pas être déchiffrées. Cela est rendu possible par l'utilisation de clés de session temporaires qui ne sont pas dérivées directement des clés privées à long terme. Voici comment cela fonctionne :

Pour chaque session, une nouvelle paire de clés Diffie-Hellman est générée temporairement.
Ces clés temporaires sont utilisées uniquement pour la durée de la session.
Une fois la session terminée, les clés temporaires sont détruites.

Grâce à PFS, même si un attaquant parvient à obtenir la clé privée du serveur, il ne pourra pas déchiffrer les sessions passées car les clés de session utilisées pour ces sessions ne sont plus disponibles. Cela renforce considérablement la confidentialité des communications.

Et voilà ! Le serveur et le client sont maintenant tous les deux équipés d'une clé qui va leur permettre de communiquer de manière sécurisée.

Communication

La suite de la communication va ensuite s'effectuer de manière 100% symétrique. Les clés communes possédées par le serveur ne servent donc qu'à effectuer la négociation. Les messages sont donc systématiquement chiffrés avec la clé de session avant d'être transmis. Ils sont chacun associés à un MAC, pour Message Authentication Code, qui va permettre d'assurer l'intégrité et l'authenticité des messages.

Son fonctionnement se décline en 2 étapes:

Avant le transfert des données, le MAC est calculé à l'aide de la clé de session et est joint au message.
À réception des données, le MAC est calculé à nouveau par le destinataire de la même façon. Ils doivent donc correspondre. Si ce n'est pas le cas, cela signifie que le message a été compromis et le message est rejeté.

Afin d'assurer la sécurité de la transmission, des nouvelles clés de session doivent être générées régulièrement. Ce processus consistait à simplement exécuter une nouvelle fois la négociation tout en maintenant la connexion pour l'utilisateur. Ce protocole a drastiquement changé avec la version 1.3 de TLS. Maintenant les nouvelles clés sont juste des versions dérivées des anciennes clés de session. Autrement dit, il n'y a plus besoin de transmettre de données entre le client et le serveur pour la régénération si ce n'est un message KeyUpdate afin de demander à l'autre partie de générer des nouvelles clés. Les deux ont donc déjà tous les éléments nécessaires afin de générer une clé identique.

HTTP Strict Transport Security (HSTS)

Le HTTP Strict Transport Security (HSTS) est une politique de sécurité web qui aide à protéger les sites contre les attaques de type downgrade et les attaques de cookie hijacking. HSTS permet aux serveurs web de déclarer que les navigateurs ou autres agents doivent interagir avec eux en utilisant uniquement des connexions sécurisées (HTTPS). Lorsqu'un navigateur voit un en-tête HSTS d'un site web, il sait qu'il doit automatiquement effectuer toutes les futures requêtes vers ce site en utilisant HTTPS, sans permettre à l'utilisateur de passer à HTTP non sécurisé.

Chiffrement symétrique VS asymétrique

On pourrait maintenant se poser la question suivante : Pourquoi ne pas chiffre asymétriquement les données tout le long de la communication ? Il existe 3 raisons principales à cette façon de faire :

Performance et Efficacité

Les algorithmes de chiffrement asymétrique (comme RSA) sont beaucoup plus lents et consomment plus de ressources en comparaison avec les algorithmes de chiffrement symétrique (comme AES). Chiffrer et déchiffrer chaque message avec un algorithme asymétrique entraînerait une surcharge significative sur le serveur et le client, ralentissant considérablement la communication. La taille des clés de chiffrement asymétrique est aussi généralement plus élevée, augmentant la charge de stockage et de traitement.

Simplicité de la Gestion des Clés

Le nombre de clés étant moins important en chiffrement symétrique (1 clé commune) qu'en chiffrement asymétrique (2 clés publiques et 2 clés privées). La gestion et la distribution de ces paires de clés pour chaque session de communication seraient complexes et peu pratiques.

Sécurité

Certains standards de sécurité, tel que PFS, ne seraient pas applicables dans le cas d'un chiffrement asymétrique. Cela garantit que même si la clé privée du serveur est compromise à un moment donné, les communications passées restent sécurisées.