Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1 dans RouterOs 7.4

2022-08-30 Par sujet Vincent Bernat

On 2022-08-30 08:17, Vincent Bernat wrote:
Je ne suis pas sur d'avoir bien tout compris mais il semble bien que 
le fameux algo de hash sha1 ou sha2-256 ou autre soit inclus dans le 
"rsa_signature_blob"


Cette partie est utilisée dans le protocole SSH lors de 
l'authentification, pas dans le format de la clef.


Dans le code source de OpenSSH:

#v+
static const struct keytype keytypes[] = {
...
{ "ssh-rsa", "RSA", NULL, KEY_RSA, 0, 0, 0 },
{ "rsa-sha2-256", "RSA", NULL, KEY_RSA, 0, 0, 1 },
{ "rsa-sha2-512", "RSA", NULL, KEY_RSA, 0, 0, 1 },
{ "ssh-dss", "DSA", NULL, KEY_DSA, 0, 0, 0 },
...
#v-

Donc les trois types sont mappés sur KEY_RSA. Hors signature par une CA 
(avec -s), il n'y a pas de différence entre ces 3 options.



---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1 dans RouterOs 7.4

2022-08-30 Par sujet Vincent Bernat

On 2022-08-30 03:21, Pierre Colombier via frnog wrote:

Je ne suis pas sur d'avoir bien tout compris mais il semble bien que le 
fameux algo de hash sha1 ou sha2-256 ou autre soit inclus dans le 
"rsa_signature_blob"


Cette partie est utilisée dans le protocole SSH lors de 
l'authentification, pas dans le format de la clef.



aug/30 01:23:26 ssh,debug pki algorithm: ssh-rsa


Ca ressemble pas aux messages de debug de OpenSSH. C'est un OpenSSH qui 
tourne sur les Mikrotik ? Elle fait quelle taille cette vieille clef ? 
Les releases notes de la 7.4 disent que le change ne concerne que ceux 
qui ont activé strong-crypto=yes, est-ce ton cas ?



---
Liste de diffusion du FRnOG
http://www.frnog.org/


Re: [FRnOG] [TECH] fin du support de ssh-rsa signé avec sha-1 dans RouterOs 7.4

2022-08-29 Par sujet Pierre Colombier via frnog

Bonsoir Vincent,

J'ai regardé (vite fait) le RFC4253 et justement il fait référence au rfc3447

https://datatracker.ietf.org/doc/html/rfc3447#section-8.2

Also, in the encoding
   method EMSA-PKCS1-v1_5, a hash function identifier is embedded in the
   encoding.  Because of this feature, an adversary trying to find a
   message with the same signature as a previously signed message must
   find collisions of the particular hash function being used; attacking
   a different hash function than the one selected by the signer is not
   useful to the adversary.

https://datatracker.ietf.org/doc/html/rfc2437#section-9.2.1

Je ne suis pas sur d'avoir bien tout compris mais il semble bien que le fameux algo de 
hash sha1 ou sha2-256 ou autre soit inclus dans le "rsa_signature_blob"


Bref, comme tout ce qui a l'air simple, en fait, c'est hyper compliqué


Quoi qu'il en soit, le présent fil de discussion est motivé par le problème 
suivant :

J'ai une clé rsa de longue date utilisée sur une foule d'équipements mikrotik, 
et ça marche très bien jusqu'a ROS v7.2.3

aug/30 01:23:26 ssh,debug agreed on:
diffie-hellman-group-exchange-sha256
rsa-sha2-256
aes128-ctr aes128-ctr
hmac-sha1 hmac-sha1
none none
aug/30 01:23:26 ssh,debug auth req: pierre ssh-connection publickey
aug/30 01:23:26 ssh,debug auth retry: 1
aug/30 01:23:26 ssh,debug pki algorithm: ssh-rsa
aug/30 01:23:26 ssh,info publickey accepted for user: pierre

Après update en v7.4, ça ne marche plus
aug/30 01:38:01 ssh,debug agreed on:
diffie-hellman-group-exchange-sha256,
rsa-sha2-256,
aes128-ctr, aes128-ctr,
hmac-sha1, hmac-sha1,
none, none
aug/30 01:38:02 ssh,debug auth req: pierre ssh-connection publickey
aug/30 01:38:02 ssh,debug auth retry: 1
aug/30 01:38:02 ssh,error signature differs for user: pierre

Après génération d'une nouvelle clé et sans changer aucune autre option tant 
sur le serveur que sur le client

aug/30 01:42:41 ssh,debug agreed on:
    diffie-hellman-group-exchange-sha256,
    rsa-sha2-256,
    aes128-ctr, aes128-ctr,
    hmac-sha1, hmac-sha1,
    none, none

aug/30 01:42:41 ssh,debug auth req: pierre ssh-connection publickey
aug/30 01:42:41 ssh,debug auth retry: 1
aug/30 01:42:41 ssh,debug pki algorithm: rsa-sha2-256
aug/30 01:42:41 ssh,info publickey accepted for user: pierre


Donc, si par exemple on a une clé de ce type là.
Si on a tout desactivé sauf ssh
et si on a laisse
/ip ssh set always-allow-password-login=no
qui est la valeur par défaut

et bien après upgrade en RoS 7.4, on est beuzeuh ! c'est bon pour un factory 
reset !



On 30/08/2022 00:02, Vincent Bernat wrote:

On 2022-08-29 23:13, Pierre Colombier via frnog wrote:

En d'autres termes, quand il y a bien longtemps, sur une debian 8 far 
far away, j'ai fait un


ssh-keygen -t rsa -b 4096

ou bien aujourd'hui sur une debian 11

ssh-keygen -t rsa-sha2-256 -b 4096


C'est exactement pareil que -t rsa ou -t ssh-rsa car une clef RSA, ce 
sont deux nombres. Il n'y a pas de hash. Le -t rsa-sha2-256 est 
utilisé quand on signe des clefs avec un certificat.


je crée toujours une clé rsa de 4096 bits, j'ai bien toujours un 
fichier id_rsa.pub qui a le même format et commence par "ssh-rsa", 
mais par contre, il y a bien une différence, car quand bien même le 
client ssh serait récent, la première a cessé d'être acceptée par les 
serveur ssh récents, alors que la seconde fonctionne bien.


donc, le "public key blob" quand bien même il ne change pas de 
format, embarque bien quelque chose qui est basé sur un hash sha1 ou 
sha256 (ou autre).


Refait la même chose avec -t ssh-rsa et cela fonctionnera aussi. Ce 
n'est pas pour ça que ta clef n'est plus acceptée. C'est soit qu'elle 
est trop petite, soit que ce n'est pas elle qui est dans le known hosts.
Ou alors, le "blob" contient juste la clé publique + une étiquette 
qui dit quel algo de hash on est sensé employer et dans ce cas 
j'aurais bien aimé modifier mon fichier .pub pour employer le nouvel 
algo tout en gardant la même clé. ça me rendrait la migration 
beaucoup plus simple.


Nope. Le format est dans la RFC 4253. Ce sont deux nombres encodés.
https://datatracker.ietf.org/doc/html/rfc4253#section-6.6


---
Liste de diffusion du FRnOG
http://www.frnog.org/

---
Liste de diffusion du FRnOG
http://www.frnog.org/