7
$\begingroup$

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.

Improve this question
$\endgroup$

1 Answer 1

Reset to default
2
$\begingroup$

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.

Improve this answer
$\endgroup$
4
  • $\begingroup$ You're right. I'm willing to accept the risk of compromise to my session, but not to my credentials. $\endgroup$
    – Catalin P
    Commented Sep 22, 2013 at 6:11
  • 1
    $\begingroup$ @CatalinPatulea, for SSH, compromise of your session is already devastating (because the attacker can insert a single command that places a backdoor into your account on the server), so leaving the session unprotected would be extremely dangerous. $\endgroup$
    – D.W.
    Commented Sep 22, 2013 at 6:12
  • 2
    $\begingroup$ @CatalinPatulea Before continuing, I think you should keep in mind that active attacks (such as man-in-the-middle) are possible most of the time when passive attacks are possible. In general it is therefore advisable to protect against both. You could be correct in only protecting your credentials, but I would be very very careful. $\endgroup$
    – Maarten Bodewes ♦
    Commented Sep 22, 2013 at 14:30
  • $\begingroup$ Thanks. For context, this is on a WPA2 wifi network. This is why I feel I can gain some trust from the network layer. $\endgroup$
    – Catalin P
    Commented Sep 22, 2013 at 18:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.