7

As far as I know, SSH2 first does a key exchange based on the server host key and brings up transport authentication and encryption derived from this kex. The real authentication (password or public key) is done over this secure transport.

If you set the cipher to 'none', you wouldn't want to allow password authentication because then the password would be sent in plaintext. But what about public key authentication?

I believe pubkey auth works by the server sending a nonce to the client, the client signing it with its private key, and the server verifying the signature. How is the overall system weakened if this exchange happens in the clear?

I can think of at least:

  • known-plaintext (passively capture (nonce, $D_k(nonce)$) and try to derive k)
  • chosen-ciphertext (intercept and replace the nonce, capture $D_k(chosen)$)

Is RSA (specifically, the way it's used by the raw SSH public key authentication) vulnerable to either of these?

Edit: my original formulation was incorrect: RSA signs by decryption, not encryption. Which points to an attack on textbook RSA: How does a chosen plaintext attack on RSA work? but NOT on the RSA used in practice in SSH and SSL. PKCS#1 padding protects against this attack.

Community
  • 1
Catalin P
  • 73
  • 6

1 Answers1

2

It is critical to combine both the key exchange and the secure channel, otherwise someone can mount a man-in-the-middle attack.

The way we prevent a man-in-the-middle attack is to do a key exchange, to exchange a session key that both endpoints know but no one else (including the man-in-the-middle) can know, and then authenticate both endpoints. You seem to suggest that we remove the encryption, remove the secure channel, don't bother negotiating a session key. If we did that, then the protocol would become vulnerable to man-in-the-middle attacks (active attacks), because nothing binds the signature/authentication phase to the rest of the stuff sent over the SSH channel.

D.W.
  • 36,982
  • 13
  • 107
  • 196