[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Fwd: SSL vulnerability and SSH]
[Thread Prev] | [Thread Next]
- Subject: [Fwd: SSL vulnerability and SSH]
- From: Aris Adamantiadis <aris@xxxxxxxxxxxx>
- Reply-to: libssh@xxxxxxxxxx
- Date: Sat, 07 Nov 2009 15:26:22 +0100
- To: libssh project mailing list <libssh@xxxxxxxxxx>
Hi,This was posted on the OpenSSH mailing list but is relevant as well to libssh. In two words: The SSH protocol is not vulnerable to the vulnerability recently found in TLS because the key reexchange works in a totaly different (and sound) manner.
Good week-end, Aris
--- Begin Message ---
- Subject: SSL vulnerability and SSH
- From: Damien Miller <djm@xxxxxxxxxxx>
- Date: Fri, 6 Nov 2009 12:09:00 +1100 (EST)
- To: openssh-unix-dev@xxxxxxxxxxx
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 _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
--- End Message ---
Archive administrator: postmaster@lists.cynapses.org