Hi,
This is just a quick note to state that the recently reported SSL/TLS
MITM attack[1] *does not* affect SSH. Like SSL/TLS, SSH supports
key and parameter renegotiation, but it is not vulnerable because a
session identifier is carried over from the first key exchange into all
subsequent key exchanges.
Technical details:
In SSL, key exchanges and subsequent renegotiations are completely
independent. This allows an attack as follows: a MITM intercepts a
connection from a real client. It then connects to the target server
itself and negotiates a SSL/TLS connection. The MITM may then inject
some data of its choice (say, the start of a HTTP request) before it
initiates a regenotiation with the server and proxies the real client's
negotiation to the server. The real client thinks it is negotiating for
the first time, but the real server thinks the client is renegotiating.
Once the negotiation is complete, thereal client and server continue the
connection (proxied via the MITM) oblivious to the fact that the MITM
has injected data.
In SSH, the first key exchange generates a "session identifier" in
addition to a key. This session identifier is used in the derivation of
all future cipher and MAC keys (RFC4253 section 7.2). If an attacker
tried the proxy and renegotiate SSL attack on SSH, the real client's
session ID would not match that generated by the server, causing the
derived keys to be different. The connection would terminate with a MAC
error as soon as the first data was exchanged.
(http://djm.net.au/2009/11/6/ssh-is-not-vulnerable-to-the-ssl-tls-mitm-attack)
-d
[1] http://extendedsubset.com/?p=8
