diff --git a/Operation.md b/Operation.md index c10203e..e0a40f8 100644 --- a/Operation.md +++ b/Operation.md @@ -6,7 +6,7 @@ Le serveur possède donc ces 2 clés sur son système. La clé publique va être Ce processus se déroule en plusieurs étapes, les plus importantes étant les suivantes : -1. Le serveur envoie sa clé publique au client. De par sa nature, cette dernière n'est pas chiffrée et est identique à tout les clients qui vont communiquer avec ce serveur. Elle permet donc uniquement de chiffrer les données. **A 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. +1. 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. 2. 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. @@ -23,18 +23,27 @@ En plus des clés publiques et privées, le protocole TLS peut utiliser l'algori 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 : + +1. Pour chaque session, une nouvelle paire de clés Diffie-Hellman est générée temporairement. +2. Ces clés temporaires sont utilisées uniquement pour la durée de la session. +3. 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. image - ## 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. +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: 1. Avant le transfert des données, le MAC est calculé à l'aide de la clé de session et est joint au message. 2. À 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. \ No newline at end of file +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.