Avec SSL, utilise-t-on plusieurs fois la même clef RSA ?

Support Debian
#1

Bonsoir à tous,

Petite interrogation du soir… Je m’interrogeais sur le protocole SSL, et en particulier SSH.

Je suis A et je veux engager le dialogue avec un serveur distant, mettons B. Si j’ai bien compris, ça se fait en plusieurs étapes :
[ul][li]Les deux interlocuteurs échangent une clef RSA publique ;[/li]
[li]Grâce à cette clef RSA, ils échangent de manière sécurisée une clef de chiffrement symétrique pour toutes les autres communications (le chiffrement symétrique est bien plus rapide).[/li]
[li]Ils peuvent ensuite communiquer en chiffrant un message en symétrique qui n’est donc connue que d’eux seuls.[/li][/ul]

Dans le cas classique pour SSH :

1) Je suppose que la clef RSA fournie par B est toujours la même. Quand ce n’est pas le cas, le client SSH de A râle en disant “POSSIBLE BREAK IN ATTEMPT” (permet de devenir suspicieux en cas d’attaque de l’homme du milieu).
2) Est-ce que le client A fournit bien toujours la même clef publique RSA ?
3) Je suppose que la clef de chiffrement symétrique est toujours différente.

Ai-je raison ?

-> Du coup, si je veux faire une analyse forensics sur mon serveur B, est-ce que ça ne vaut pas le coup d’aller regarder du côté des empreintes des différentes clefs publiques RSA fournies par les clients qui ont tenté de se connecter ?

Ça ouvrirait des possibilités sympa, notamment avec fail2ban : si j’ai eu une attaque, toutes les IPs qui utilisent la même empreinte RSA sont bannies direct.

C’est d’ailleurs peut-être déjà mis en œuvre. Savez-vous quelque chose à ce sujet ? Qu’en pensez-vous ?

#2

Il y a eu une faille spécifique debian avec une modification par un mainteneur debian de la fabrication des clefs SSH, réduisant ainsi considérablement le nombre de clefs possibles. Le paquet openssh-blacklist est une liste noire contenant ces clefs. Tu peux l’enrichir. Sinon pour ta question, chacun envoit sa clef publique à l’autre, cette clef l’identifie de manière certaine. La clef de chiffrement symétrique est régulièrement changée le long de la connexion.

#3

Pour être plus précis, tu calcules une empreinte par
$ ssh-keygen -l -f clef_dsa.pub
Tu obtiens par exemple
1024 a9:28:da:cc:87:ec:26:a4:12:17:0d:36::28:da:cc:87 clef_dsa.pub (DSA)
Il te suffit de rajouter a928dacc87ec dans le fichier /usr/share/ssh/blacklist.DSA-1024
Notes que seuls les 12 premiers octets de l’empreinte sont utilisés.

Mais je ne vois pas où récupérer a posteriori l’empreinte ssh d’un client…

#4

C’est marrant qu’on n’en parle pas, j’ai eu cette idée l’autre fois, me disant que ça peut être un moyen de plus pour faire une analyse en cas de problème : qui s’est connecté en SSH, avec quelle(s) clef(s). -> Si plusieurs utilisateurs se sont connectés avec la même clef ssh, on peut éventuellement en faire des conclusions sur le lien entre ces connexions.

#5

Je suppose que tu veux dire “essai” de connexion ?
Car si tu as plein d’inconnus qui réussissent à se connecter sur ta machine sans to autorisation : aïe !
Sinon : $ grep sshd /var/log/auth.log
t’éclaire déjà pas mal.

#6

[quote=“ricardo”]Je suppose que tu veux dire “essai” de connexion ?
Car si tu as plein d’inconnus qui réussissent à se connecter sur ta machine sans to autorisation : aïe !
Sinon : $ grep sshd /var/log/auth.log
t’éclaire déjà pas mal.[/quote]

Tu parles de connexion ou de session réussie? Car sinon c’est très régulier les connexions (mais ils se font rejetés par sshd…)

#7

Oui, tu as raison, dans ma tête, je voyais les sessions qui aboutissaient :blush: