Fonctionnement du protocole SSL

Support Debian
#1

Bonjour à tous,

je suis en train de mettre en place de l’openvpn pour l’un de mes projets d’entreprise. Pour se faire et pour bien comprendre son fonctionnement je suis en train d’étudier à fond les modes de fonctionnement de la librairie SSL. A première vue cela peut paraitre facile néanmoins dès que l’on essaye de rentrer dans les détails cela devient beacoup plus compliqué. je vais essayer d’expliquer ce que j’ai compris par des exemples concrets :

Exemple : connexion https :

le serveur envoie au navigateur de l’utilisateur sa clé publique que ce dernier vérifie avec la clé publique de l’autorité de certification. Une fois la vérification effectuée. Le client génére une clé aléatoire qu’il crypte avec la clé publique du serveur https. Ce dernier récupère la clé aléatoire en décryptant avec sa clé privée. La connexion est chiffrée avec cette clé aléatoire (nous passons donc en mode symétrique). A aucun moment le client ne possède de clé publique

Exemple 2:

connexion à un serveur vpn :

le serveur et le client ont tous les deux une clé publique. Ils se les échangent et ils vérifient avec la clé publique de l’autorité de certification. Ils échangent ensuite une clé aléatoire et la communication s’effectue avec cette clé.

D’après ce que j’ai compris les chiffrement asymétrique est surtout la pour s’assurer que l’interlocuteur est le bon et que l’échange de la clé aléatoire se fait de manière sécurisée, une fois ces étapes effectuées, un cryptage symétrique se met en place ce qui permet de gagner en temps de calcul

Dans la configuration de openvpn, le protocole d’échange de clé Diffie–Hellman est utilisé et je n’arrive pas à savoir à quel moment du protocole ssl il est utilisé.

Je souhaiterai également savoir si ce que j’ai écrit ci-dessus vous semble cohérent ou non pour ma bonne compréhension du sujet

Merci à tous pour votre aide,

Cordialement

#2
  1. La vérification ne se fait pas en envoyant la clef publique mais de la façon suivante:

B envoit sa clef publique à A

Si A veut voir si B est bien celui qui a la clef publique C1pub, il fait comme suit

A choisi un motif aléatoire “Gablofk765hjn” qu’il code avec la clef publique, il envoie le résultat à B. B décode ce qu’il a reçu avec sa clef privée et renvoie le résultat à A.

Si tout va bien, A reçoit en retour le motif “Gablofk765hjn” que seul B, possesseur de la clef privée correspondant à C1pub, pouvait retrouver. A sait que B est bien B.

  1. Mais ce qui est utile, c’est la négociation de la clef de dialogue se fait par un dialogue ou A décide d’une clef qu’il code avec C1pub, il envoie le tout à B qui décode ça avec sa clef privée. À ce stade A et B ont en commun une clef unique connue d’eux seuls et qui sert pour les échanges à venir.

La seule parade à cela consiste soit à décoder la clef négociée à la volée (pas simple), soit à se mettre entre A et B. Si C est une machine qui se met au milieu, A envoie ses données à C qui les envoie à B. C voit passer au mileu la clef de chiffrement négociée et peut décoder tout le traffic.

Il faut donc que A utilise la clef publique de C au lieu de la clef publique de B. Il importe donc d’être sur que la clef publique reçue par A identifie bien B et non C. Cette clef est envoyée avec un serveur qui authentifie la clef, en clair on lui donne la clef et il dit c’est telle machine. Ce serveur peut être B lui même ou une autorité de certification (ça devrait être l’état et ça devrait être un service public). Dans un tel cas C est coincé: soit il envoie la clef publique de B mais il sera incapable de déchiffrer les messages de A, soit il envoie sa clef publique à lui et l’autorité de certification dira à A qu’il ne connait pas cette clef.

#3

Merci bien pour la précision et pour ton aide,

la dernière petit inconnu qu’il me reste encore est :

A quel moment la clé de Diffie–Hellman dans ma configuration d’openvpn est-elle utilisée. De plus elle n’apparait pas dans beaucoup de configurations d’openvpn que j’ai visualisé, qu’elle est donc son véritable intérêt cela reste encore un mystère.

Si quelqu’un a une petite idée…

Merci d’avance

#4

L’algorithme d’échange de clef Diffie Hollman est une méthode permettant de se mettre d’accord sur la clef échangée. C’est une des méthodes permettant de se mettre d’accord sur une paire de clefs de chiffrement: fr.wikipedia.org/wiki/%C3%89chan … ie-Hellman
Ça se substitue au (2) dans ce que je t’ai dit plus haut.

#5

Merci bien pour ton aide,

Cordialement

#6

Bon…
On passe en résolu ?