4 ms·
Actually, you cannot perform keystroke timing attacks on the password sent during SSH user authentication. This is because SSH transmits the password in its ent
by Skrillor 3y ago
Actually, you cannot perform keystroke timing attacks on the password sent during SSH user authentication. This is because SSH transmits the password in its entirety, not the individual keystrokes as it does during a shell session.
The possible downgrade is usually limited to downgrading SHA2 to SHA1 when using RSA keys for user authentication. We are currently not aware of any attacks that benefit from this.
- mkj 3y agoI don't think dropping the server-sig-algs packet gives any additional downgrade capability? If a server is going to accept a rsa sha1 signature it will accept it regardless of whether the client receives the server-sig-algs or not. Performing a rsa sha1 signature doesn't cause any exposure for a client (that I know of?). server-sig-algs was only added for compatibility, so new clients wouldn't get kicked off old servers that don't accept rsa-sha2 pubkey auth packets. https://www.rfc-editor.org/rfc/rfc8308#page-7 https://www.rfc-editor.org/rfc/rfc8308#page-7
- djmdjm 3y ago> The possible downgrade is usually limited to downgrading SHA2 to SHA1 when using RSA keys for user authentication AFAIK this downgrade is not possible for OpenSSH, as it refuses RSA/SHA1 signatures by default at both the client and server. Moreover, deleting the EXT_INFO message would only remove the _advertisement_ that these messages are accepted and would change the fact of whether they are. It might be possible to use this attack to trick an old client to making a RSA/SHA1 signature where it might mormally have made an RSA/SHA2 one, but I can't see any security impact from this as the signed data is still bound to the connection instance and it wouldn't change whether the peer would accept it anyway.