Bonour,

Est il possible pour que je comprenne bien les certifical SSL htst, de faire un test du genre créer un serveur ssh sur linux avec une clef privée et public. Utiliser la clef privée via mon client pour me connecter au serveur ssh . Faire un echo avec un message...

Si je capture les trames avec wireshark à ce moent puis je lire l'echo grâce à la clef privée que je mets dans wireshark ?

Merci

Salut,

Je n'ai pas bien compris le début de ton message quand tu parles de certificats ssl.

Pour la session SSH, avoir la clef privée n'est pas suffisant pour déchiffrer les messages, car des clefs éphémères sont négociées en début de session, exactement pour éviter le scénario que tu décris ici. (Voir Diffie Helllan sur wikipédia)

N'hésite pas si tu as d'autres questions,

Bonjour,

Oui, (enfin j'en suis presque certain, vu qu'il sait le faire pour d'autres protocoles comme HTTPS, TLS ou même WPA en WiFi). À la condition que tu as capturé les paquets qui ont servit à établir la connexion SSH.

Pour détailler un peu plus, Wireshark va faciliter beaucoup les choses. https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange. Tu verras en capturant les trames que plusieurs «paramètres» sont fixés par le client et le serveur parmi une liste de paramètres possibles.

Cependant, il faut bien comprendre que SSH est différent de TLS même s'il existe de nombreuses similarités. Par contre, HSTS (si c'est ça que tu voulais dire par «htst»), c'est autre chose.

EDIT: modifié pour éviter la confusion sur les paires de clé asymétriques.

-
Edité par KoaTao 14 novembre 2021 à 21:41:31

Hello @KaoTao, grâce à Diffie Hellman, ce n'est pas possible de déchiffrer en ayant "seulement" la clef privée.

C'est aussi valable pour TLS (https://wiki.wireshark.org/TLS) il te faut soit les clefs éphémères, la clef privée RSA étant suffisante seulement si DH n'est pas utilisé.

C'est la propriété de forward secrecy: même si les clefs de long terme fuitent, cela n'a pas d'impact sur la confidentialité des échanges antérieurs (pourvu que le matériel éphémère ait bien été supprimé)

Autant pour moi, oui c'est vrai que seul l'hôte ou le serveur connaissent certains composants qui servent à déterminer le secret.

EDIT: C'est toujours en cours de développement du côté de Wireshark: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=16054 pour une fonctionnalité similaire dans l'idée à celle pour TLS.

-
Edité par KoaTao 11 novembre 2021 à 23:31:15

Déjà merci bcps pour vos réponses :)   re je vais vous expliciter demain .

d'accord donc en theorie ce n'est plus possible 

FantasMaths a écrit:

Hello @KaoTao, grâce à Diffie Hellman, ce n'est pas possible de déchiffrer en ayant "seulement" la clef privée.

C'est aussi valable pour TLS (https://wiki.wireshark.org/TLS) il te faut soit les clefs éphémères, la clef privée RSA étant suffisante seulement si DH n'est pas utilisé.

C'est la propriété de forward secrecy: même si les clefs de long terme fuitent, cela n'a pas d'impact sur la confidentialité des échanges antérieurs (pourvu que le matériel éphémère ait bien été supprimé)

Salut merci pour la réponse.

Mais Si je suis un tuto basique pour faire une paire de clée RSA avec linux afin de se connecter en ssh.
Lorsque je génère ma clée publique à partir de ma clef privée et que je communique ma clée publique à l'autre partie ma clée publique et privée, elles ne sont pourtant pas temporaires ? et elles ne changent que si je le veux ?

Peut etre que dans cette exemple que je viens te donner DH n'est pas utilisée ?

Dans tous les cas en faisant un test avec wireshark sur des trames capturées lors d'une connection ssh entre moi et mon serveur, wireshark me demande le passphrase quand je lui soumets ma clef privée afin de décrypter les trames.

Je connais le passphrase mais malgré tout il me dit que ce n'est pas le bon... bref.

KoaTao a écrit:

Bonjour,

Oui, (enfin j'en suis presque certain, vu qu'il sait le faire pour d'autres protocoles comme HTTPS, TLS ou même WPA en WiFi). À la condition que tu as capturé les paquets qui ont servit à établir la connexion SSH.

Pour détailler un peu plus, Wireshark va faciliter beaucoup les choses, vu que la paire de clé asymétrique n'est pas utilisée pour échanger des données utiles entre le client et le serveur mais pour établir une connexion chiffrée et sécurisée entre les deux partis. https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange. Tu verras en capturant les trames que plusieurs «paramètres» sont fixés par le client et le serveur parmi une liste de paramètres possibles.

Cependant, il faut bien comprendre que SSH est différent de TLS même s'il existe de nombreuses similarités. Par contre, HSTS (si c'est ça que tu voulais dire par «htst»), c'est autre chose.

-
Edité par KoaTao 11 novembre 2021 à 21:15:23

Oui je me mélange les pinceaux le HSTS c'est pour empecher l'utilisation de faux certificat tls ou ssl ?

Je vais retenter merci.

-
Edité par DddDddds 14 novembre 2021 à 16:21:13

Bonjour,

De quelle paire de clé parles-tu? Si tu parles de celle qui sert à authentifier un utilisateur (pour éviter le mdp par exemple), alors elle n'intervient pas dans le chiffrement de la communication. C'est l'authentification justement et c'est propre à l'application qui utilise SSH pas au protocole en lui-même, ici un remote shell. Après j'avoue que le nom du protocole peut porter à confusion, mais SSH peut-être utilisé à d'autres fins qu'un remote shell (même si l'application principale avec SSH). Voit SSH comme un protocole qui permet de chiffrer une communication.

Tu peux faire deux choses pour comprendre un peu le mécanisme derrière SSH:

- Sniffer le trafic et regarder les trames échangées (surtout les premières).

- Utiliser ton client ou serveur SSH en mode debug (avec OpenSSH il suffit de fairessh -v [reste de la commande] avec le client, pour le serveur il faut augmenter la verbosité et le niveau de log.

Wireshark ne peut pas déchiffrer une communication chiffrée avec SSH. Le lien vers le bugzilla du logiciel montre que c'est une fonctionnalité qui est en cours de développement. Cependant, c'est difficile à implémenter semble-t-il.

Je pense aussi que tu mélanges des notions avec TLS.

HSTS sert à s'assurer que le client utilise uniquement HTTPS pour communiquer avec le serveur web et empêcher HTTP après la toute première connexion du client au serveur. Ça réduit la surface d'attaque, mais ça n'empêche pas dans tous les cas une attaque de type MITM.

-
Edité par KoaTao 14 novembre 2021 à 21:56:00

FantasMaths a écrit:

Hello @KaoTao, grâce à Diffie Hellman, ce n'est pas possible de déchiffrer en ayant "seulement" la clef privée.

C'est aussi valable pour TLS (https://wiki.wireshark.org/TLS) il te faut soit les clefs éphémères, la clef privée RSA étant suffisante seulement si DH n'est pas utilisé.

C'est la propriété de forward secrecy: même si les clefs de long terme fuitent, cela n'a pas d'impact sur la confidentialité des échanges antérieurs (pourvu que le matériel éphémère ait bien été supprimé)

Salut merci pour la réponse.

Mais Si je suis un tuto basique pour faire une paire de clée RSA avec linux afin de se connecter en ssh.
Lorsque je génère ma clée publique à partir de ma clef privée et que je communique ma clée publique à l'autre partie ma clée publique et privée, elles ne sont pourtant pas temporaires ? et elles ne changent que si je le veux ?

Peut etre que dans cette exemple que je viens te donner DH n'est pas utilisée ?

Dans tous les cas en faisant un test avec wireshark sur des trames capturées lors d'une connection ssh entre moi et mon serveur, wireshark me demande le passphrase quand je lui soumets ma clef privée afin de décrypter les trames.

Je connais le passphrase mais malgré tout il me dit que ce n'est aps le bon... bref.

Comme l'a indiqué @FantasMaths, les clés utilisées pour le chiffrement sont éphémères. SSH se divise en plusieurs couches dont la couche de transport et la couche d'authentification. C'est la couche de transport qui est chargée d'assurer le chiffrement de la communication, grâce notamment à Diffie-Hellman. Ces clés que tu génères sont utilisées par la couche d'authentification.

Wireshark ne peut pas déchiffrer du trafic SSH. C'est un fait. Ce que tu essaies de faire avec Wireshark, je ne sais pas ce que c'est, mais c'est autre chose. Génère des clés sans passphrase et tu verras bien où ça te mène.