[résolu]SSH:Système de chiffrement asymétrique&symétrique?Failles?

ixabro · Le 20/08/2010, à 11:56

Bonjour,

Je poste dans ce forum car j'ai un soucis de compréhension au niveau du système de chiffrement et de la technique de sécurisation des échanges client-serveur de SSH.
D'après ce que j'ai pu lire :

On dispose de deux machines :
*Machine A
*Machine B

Machine A -> envoie clé public A -> Machine B
Machine B -> envoie clé public B -> Machine A

Déjà il parait que l'envoie d'une clé public se fait accompagner d'un certificat qui permetterait de vérifier si la clé public est bien à celui qui le prétend. Est ce vraiment sécurisé ? Est cela le chiffrement par CA ?

Ensuite le systeme SSH utiliserait le système de chiffrement asymétrique juste pour l'authentification car il serait gourmant en ressource (CPU etc ...).

Donc pour le système de chiffrement asymétrique : [Lors de l'envoie du couple login/passwd] - Machine A chiffre les données donc le login/passwd avec la clé public B puis l'envoie à Machine B qui lui les déchiffre grâce à sa clé privée B.

* Nous avons connection TCP/IP établie + authentification OK

Après ce n'est pas fini la clé public B servirait à encrypter une clé symétrique pour ensuite permettre les échanges des données plus rapidement sans utiliser trop de ressources a contrario du chiffrement asymétrique.

[*] Là déjà il y a un petit quelque chose qui me perturbe ... qui encrypte le premier cette clé symétrique ? Puis qu'après je pense que cette dernière est envoyée de manière chiffrée à Machine B par exemple qui là va la déchiffrer et les communications + échanges vont uniquement être chiffrés et déchiffrés grâce à cette clé symétrique.

Pour finir il y a deux clés pubs générées la première fois par openSSH-client/serveur :
* Une clé pub DSA : algorithme de chiffrement pour la signature dit algorithme de signature des données et pour la confidentialité. Que veut dire algorithme de signature ? Pourquoi le RSA ne pourrait pas être un algorithme de signature ?
* Une clé pub RSA : algorithme de chiffrement basé sur la difficulté de décomposer un nombre en ses facteurs premiers.

Je conclut donc qu'il y a une clé pour la signature et l'autre pour la confidentialité ...

Vu que ces clés sont pubs, tous le monde peut y avoir accès alors si un gringo qui utilise les clés pubs ou qui intercepte l'envoie de la clé pub B par exemple : il pourrait se faire passer pour Machine A personnellement j'ai retourné le problème dans tous les sens et je pense que l'obtention de la clé pub B pour ensuite se faire passer pour Machine A pour enfin envoyer des données chiffrées à Machine B, ça ne sert à rien mais cela est très ennuyeux non ?

J'espère que la communauté ubuntu pour me renseigner et m'éclairer, cela m'aiderait beaucoup.

Merci de m'avoir lu.
En attente de votre réponse.

Dernière modification par ixabro (Le 21/08/2010, à 17:48)

slasher-fun · Le 20/08/2010, à 12:08

Bonjour,

On va résumer plutôt que de reprendre ton explication :

* chiffrer : modifier un message à l'aide d'une clé de chiffrement
* déchiffrer : retrouver le message original à l'aide d'une clé de chiffrement
* décrypter : retrouver un message sans avoir sa clé de déchiffrement
* crypter : modifier un message sans connaître la clé de chiffrement : impossible, puisqu'on la connait forcément (comment on chiffrerait sans clé ? ^^)
* encrypter : n'est pas français

Le chiffrement asymétrique est basé sur un couple clé publique / clé privée. Comme son nom l'indique, la clé publique est destinée à être publique, et la clé privée doit rester privée. Il n'est pas possible de retrouver la clé publique à partir de la clé privée et inversement.

Chiffrer un document à l'aide de la clé privée de l'émetteur permet de le signer : la clé permettant de le déchiffrer étant publique, cela prouvera simplement qu'il a forcément été chiffré à l'aide de la clé privée du propriétaire.
Chiffrer un document à l'aide de la clé publique du destinataire permet de le chiffrer (dans le sens "on veut le rendre confidentiel") : seule la personne disposant de la clé privée (donc le destinataire) pourra prendre connaissance de son contenu.

Lors d'une connexion SSH, le serveur envoie sa clé publique au client, qui l'accepte ou non. S'il l'accepte, une clé est alors choisie abitrairement par le client et envoyée au serveur chiffrée avec sa clé publique. Le serveur peut alors la déchiffrer, et l'échange peut commerncer. La clé est automatiquement modifiée régulièrement au long de la session.

ixabro · Le 20/08/2010, à 17:03

Merci beaucoup slasher-fun pour ton explication mais tu ne réponds à aucune de mes questions
Par contre je ne savais pas que la clé public était modifiée pendant l'échange ... ?
Tu voulais peut être parler de la clé pour le chiffrage symétrique ?

La clé est automatiquement modifiée régulièrement au long de la session.

L'échange peut commencer mais là aussi, la suite de l'échange se fera via une politique/concept de chiffrage symétrique après encryptage d'une clé symétrique qui s'échangera durant toute la conversation client/server. Il me semblait pourtant avoir lu qu'il y avait après authentification à l'asymétrique, le reste des communications chiffrées symétriquement car apparement il est trop gourmant de sécuriser toutes les communciations client/serveur avec la techinique du chiffrage asymétrique.

S'il l'accepte, une clé est alors choisie abitrairement par le client et envoyée au serveur chiffrée avec sa clé publique. Le serveur peut alors la déchiffrer, et l'échange peut commerncer.

Dernière modification par ixabro (Le 20/08/2010, à 17:12)

slasher-fun · Le 20/08/2010, à 19:12

Oui c'est ça : l'auth est asymétrique et permet l'échange d'une clé symétrique, qui sera régulièrement modifiée au long de la session.

nesthib · Le 20/08/2010, à 20:19

@ixabro : pour faire bref et répondre à certaines de tes questions. Le système par clé publique/privé est vulnérable à une attaque, l'attaque de l'homme du milieu (substitution des clés publiques). Cette attaque est parée en vérifiant la clé d'authentification du server lors de la première connexion. Par la suite tout changement de clé est détecté par ssh.

Pourquoi tel algorithme pour chiffrer, tel autre pour signer ? Tout simplement car certains sont plus efficaces que d'autres à cette tâche, certains algorithmes ne sont carrément pas capable de faire l'une des deux tâches.

si tu veux voir tout ce qu'il se passe lors d'une connexion ssh utilise l'option -vvv

ixabro · Le 20/08/2010, à 22:28

Merci nesthib.
Je comprends mieux, je me disais bien qu'il y avait une attaque de type spoofing capable de pimenter cette communication réseau qui semblait totalement sécurisée. Je ne savais pas que la fameuse attaque du Man in the middle intervenait là dedans quoi que ça m'avait traverssé l'esprit.

Donc en effet je connaissais le mode verbose + de la commande ssh mais bon quand je regarde la liste qui défile, je dois remonter tout le rapport et tout analyser j'ai commencé oui mais je n'ai jamais fini (je rigole)

Quoi qu'il en soit il reste donc cette commande : ssh-keygen -l -f /chemin/vers/clé/pub pour comme tu dis parer à cette attaque.

Mais quand est il du certificat ? J'ai lu aussi quelque chose dessus comme quoi il y a un certain chiffrement par certificat qui intervenait dans l'histoire ... peut être pour le protocol ssl ... hum je regarde ça.

slasher-fun · Le 20/08/2010, à 22:59

Le certificat est la signature par un "tiers de confiance" d'une clé publique. En gros "je soussigné machin (Verisign par exemple) certifie que la clé en question appartient bien à X" (oui parce que quand tu crées une clé tu peux la mettre au nom de n'importe qui)

nesthib · Le 21/08/2010, à 00:47

pour le particulier ça se passe ainsi :
- tu te connectes la première fois à un serveur ssh chez un ami
- ssh te donne le hash de la clé publique qu'il a reçue
- tu as ton ami au téléphone et tu lui lis la clé qu'il confirme
- s'il y a correspondance tu acceptes la connexion
- toutes les autres fois ssh saura que ce hash est valide et sûr

pour les plus grosses structures le tiers de confiance joue ce rôle de validation. Pour l'exemple du web lorsque tu te connectes à un site sécurisé, ton navigateur a en mémoire le hash du certificats d'un certain nombre d'autorités de certifications.
Lorsque tu te connectes sur un site sécurisé il vérifie si l'une de ces autorités a validé le certificats (avec papiers d'identité à l'appui normalement). Si c'est le cas il valide le certificat sinon il affiche un avertissement.

pour les clés PGP il existe le même principe de cercle de confiance, où tu ne signes la clé que de ceux dont tu as validé l'identité. C'est l'accumulation de petites preuves d'identité qui forge la confiance accordée à un inconnu

ixabro · Le 21/08/2010, à 17:47

d'accord j'ai tout compris ,
bah écoutez merci à vous deux ... pour m'avoir lu et répondu à toutes mes questions, je vous en suis très reconnaissant ...

Je vous souhaite une bonne journée, ou soirée selon l'heure à laquelle vous lirez ce message.

nesthib · Le 21/08/2010, à 19:02

de rien

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 20/08/2010, à 11:56

[résolu]SSH:Système de chiffrement asymétrique&symétrique?Failles?

#2 Le 20/08/2010, à 12:08

Re : [résolu]SSH:Système de chiffrement asymétrique&symétrique?Failles?

#3 Le 20/08/2010, à 17:03

Re : [résolu]SSH:Système de chiffrement asymétrique&symétrique?Failles?

#4 Le 20/08/2010, à 19:12

Re : [résolu]SSH:Système de chiffrement asymétrique&symétrique?Failles?

#5 Le 20/08/2010, à 20:19

Re : [résolu]SSH:Système de chiffrement asymétrique&symétrique?Failles?

#6 Le 20/08/2010, à 22:28

Re : [résolu]SSH:Système de chiffrement asymétrique&symétrique?Failles?

#7 Le 20/08/2010, à 22:59

Re : [résolu]SSH:Système de chiffrement asymétrique&symétrique?Failles?

#8 Le 21/08/2010, à 00:47

Re : [résolu]SSH:Système de chiffrement asymétrique&symétrique?Failles?

#9 Le 21/08/2010, à 17:47

Re : [résolu]SSH:Système de chiffrement asymétrique&symétrique?Failles?

#10 Le 21/08/2010, à 19:02

Re : [résolu]SSH:Système de chiffrement asymétrique&symétrique?Failles?

Pied de page des forums