Re: security of SSH1 and SSH2 protocols

yawnmoth <terra1024@xxxxxxxxx> wrote:
1. what about what SSH1 does is insecure?

The big security problems with SSH-1 are not in the key exchange
mechanism; they're elsewhere, such as the lack of a proper MAC in
the binary packet protocol and the sending of exact packet lengths
in cleartext.

There are minor issues with the SSH-1 key exchange mechanism, such
as the fact that key exchanges aren't completely independent (if an
attacker is able to factor the keys for one key exchange, they will
also be able to decrypt any other session started within the same
server-key lifetime), but it's not _too_ bad. RFC 4432 proposes an
SSH-1-like (i.e. RSA-based) key exchange method as an optional
component of SSH-2, since it has the practical advantage of doing
most of the computational work on the server (as opposed to Diffie-
Hellman which distributes the key exchange work equally between
parties) and hence is suitable for slow client machines such as
mobile devices.

I'd say the biggest advantage of SSH-2's approach is the
_decoupling_ of the server authentication step from the key exchange
step, meaning that one can be replaced without having to redesign
the other. If a fatal flaw were to be found in RSA, SSH-1 would be
completely hosed, but SSH-2 would just switch to a different host
key algorithm and the confidentiality of even previously recorded
sessions would be unimpaired. (The RFC 4432 method does not break
this decoupling, so it's still better than SSH-1's approach.)

2. is signature verification necessary in SSH2 if public key
authentication is used? you use signature verification to verify that
the server is the real one as only the real one would be able to sign
the signature of the message such that the cached public key could
decrypt. if you use public key authentication, however, presumably,
only the server you're talking to will have your private key. someone
spoofing the server, presumably, wouldn't have your private key,
themselves, and as such, they couldn't decrypt what you were sending

Not correct. Authentication in SSH-2 (both from server to client and
vice versa) is done by sending signatures, which don't affect the
encryption of the session. Somebody spoofing the server (in the
absence of host key verification) would have no trouble decrypting
your data, since all they'd need for that would be the
Diffie-Hellman exchange. They'd just receive a signature as part of
the encrypted data stream, and could simply pretend to have accepted
it and continue the session (assuming they could credibly invent
some subsequent server responses that looked like what you were

The public-key authentication in SSH-2 is a signature on some data
including the session key, which means that somebody doing a MITM
attack between you and the server could not reuse the signature you
sent to them to actually gain access to your account on the server.
In _that_ sense, public-key authentication reduces the need for
server authentication: with PK auth, you need not worry that logging
in to an unauthenticated server will let a MITM attacker in to the
real one, which is a worry you would have with password auth.
However, you do still have to worry that any data you type into the
subsequent session might be recorded in clear by the attacker, so if
you planned to type anything confidential _into_ your session (e.g.
passwords to log in to systems beyond that, or actual private
correspondence etc) you should still make sure to have checked the
host key first.
Simon Tatham What do we want? ROT13!
<anakin@xxxxxxxxx> When do we want it? ABJ!