From 7b82dbbf17b3c31e221087c3ef22ae8c565d8239 Mon Sep 17 00:00:00 2001 From: Mateo Date: Tue, 23 Jul 2024 07:27:45 +0000 Subject: [PATCH] Update Operation --- Operation.md | 24 +++++++++++++++++++----- 1 file changed, 19 insertions(+), 5 deletions(-) diff --git a/Operation.md b/Operation.md index 95570d3..c10203e 100644 --- a/Operation.md +++ b/Operation.md @@ -4,7 +4,7 @@ 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 : +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. @@ -12,15 +12,29 @@ Ce processus se déroule en plusieurs étapes : 3. 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. -**Et voilà !** Le serveur et le client sont maintenant tout les deux équipés d'une clé qui va leur permettre de communiquer de manière sécurisée. +### 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 : + +1. Le client et le serveur génèrent chacun un ensemble de clés publiques et privées Diffie-Hellman. +2. Le client envoie sa clé publique Diffie-Hellman au serveur. +3. Le serveur envoie sa clé publique Diffie-Hellman au client. +4. 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é. + +**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'a 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. A réception des données, le MAC est calculé a nouveau par le destinataire de la même façon. Ils doivent donc coordonner. Si ce n'est pas le cas, cela signifie que le message a été compromis et le message est rejetée. +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 2 ont donc déjà tout 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. \ No newline at end of file