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
out.

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
expecting).

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!
.



Relevant Pages

  • Re: Session Fixation Vulnerability in Web-based Applications
    ... session, without modifying the way servers generate session ID's is as ... Think of the http server generated sessions as "UI Sessions" and as ... no impact on authentication. ... "authentication key" for this domain (usually in the form of a new ...
    (NT-Bugtraq)
  • Re: Help! (Repeat Post) Possible to bypass security for Windows Media files?
    ... Authentication and Authorization might not be right for me. ... You can see that the session is ... If the URL were to "expire" while someone were watching the video ... web server to discover the real URL to the stream. ...
    (microsoft.public.windowsmedia.server)
  • RE: Load balancing with NTLM or Basic authentication.
    ... Microsoft SQL Server Support Professional ... So it is able to maintain the SSL session with the client. ... >So our last piece of the puzzle was the issue of authentication. ...
    (microsoft.public.inetserver.iis.security)
  • Re: Authentication session with urllib2
    ... I control the server, and it was easy for me to make a url that ... password and authenticates the session. ... The server keeps a session correctly when I test with a browser. ... requests where the session information remembers the authentication. ...
    (comp.lang.python)
  • Re: Container based authentication / authorization
    ... If it is tied into the session, ... It's customary to track state informating using the JSESSIONID as you ... Don't depend upon the JSESSIONID of the application server as the ... of users computer used during authentication. ...
    (comp.lang.java.programmer)