In an effort to reduce man in the middle attacks, when will it be (or was it) an industry accepted practice to reject SSL 2.0 connections on the client and server side?
Is configuring this on a proxy sufficent to protect a set of hosts behind it? (Update: See the answer to this question here or scroll down)
Regarding the last part of your question: no, a proxy cannot normally protect a bunch of client stations from SSLv2 woes. In SSL/TLS, things go mostly like this:
ClientHello message in which it states the maximum protocol version number it accepts (TLS 1.0 is thus announced as "SSL 3.1").ServerHello message which specifies the protocol version which will be actually used.Finished messages are sent (one by the client, one by the server) which contain some data which is a hash computed over the previously exchanged messages. The server (resp. client), upon receiving the Finished message from the client (resp. server), recomputes the expected hash; on mismatch, it closes the connection.Now let's see what happens when there is a proxy. An HTTP proxy is supposed to handle HTTP requests and responses. SSL is not a request-response protocol; it expects and provides a bidirectional tunnel. So something special has been designed in HTTP (specified in RFC 2817, section 5): the client sends a CONNECT order to the proxy, instructing it to forward all subsequent data bytes in both directions.
Thus, even in the presence of a HTTP proxy, the crypto still occurs between the client and the server. The proxy will see the handshake messages, but (that's the important point) it cannot modify them, because that would mess up the hash computations for the Finished messages: the client and server would not have seen the same exact handshake messages, they would compute distinct hashes, and there would be mismatches with the Finished messages. In particular, if the client sends a ClientHello which states that it supports SSLv2 (i.e. a ClientHello which uses the SSLv2 format, while still writing in it "I support up to 3.1"), the proxy cannot change it.
Note: in the SSLv2 protocol, the handshake does not have Finished messages. So an attacker who could intercept both directions (the proxy is in an ideal position for that) could hijack a ClientHello in SSLv2 format and change the "maximum supported version" from 3.1 to 2.0. This can force SSLv2-aware clients and servers to use SSLv2, even if they both support SSLv3+. This is called "version rollback attack". The TLS 1.0 specification includes a workaround which blocks that attack (section E.2).
Above I wrote "normally". There is a funky thing that the proxy can do in some cases. Namely, the proxy "attacks" the connection, in a true man-in-the-middle-way. This requires that the proxy produces on the spot a fake server certificate, with an embedded ad hoc CA; the corresponding root certificate must have been installed in the client (i.e. don't worry, your ISP proxy cannot force that on you).
Such hijacking proxys exist; this trickery is used to apply aggressive filtering techniques on the exchanged content (it is also somewhat frowned upon, because it relies on slightly breaking the foundations of SSL security). An hijacking proxy can theoretically perform a SSLv2 with the client, and a SSLv3+ with the intended server, in effect "protecting several clients from SSLv2".
In practice, software which knows SSLv2 but not SSLv3 is quite rare; in the case of Web browsers, this brings us back to the mid-nineties. So you can, generally speaking, totally ban SSLv2 from all your configurations, and things will work well.
Regarding industry accepted practices:
(from http://www.rapid7.com/vulndb/lookup/sslv2-and-up-enabled)
"SSLv2 has been deprecated and is no longer recommended. Note that neither SSLv2 nor SSLv3 meet the U.S. FIPS 140-2 standard, which governs cryptographic modules for use in federal information systems. Only the newer TLS (Transport Layer Security) protocol meets FIPS 140-2 requirements. In addition, the presence of an SSLv2-only service on a host is deemed a failure by the PCI (Payment Card Industry) Data Security Standard. Note that this vulnerability will be reported when the remote server supports SSLv2 regardless of whether TLS or SSLv3 are also supported."
Backwards compatibility is one of those things we should demand to go away. Every CISO/CSO at every company should tell product vendors to die in a fire if they support SSL 2.0, WEP, etc.
Probably. That is what the Ubuntu distribution started to do 2 years ago, and is finishing up now. See some of the issues: https://wiki.ubuntu.com/MigrateOffSSL2 and see the recent discussion on the mailing list: https://lists.ubuntu.com/archives/ubuntu-devel/2010-July/031010.html
SSL 2.0 has security shortcomings. I would definitely recommend rejecting all SSL 2.0 connections. Citation: http://www.cs.berkeley.edu/~daw/papers/ssl3.0.ps (Section 2)
I think it is down to us (the security profession) to make this happen, for example:
If we carry out an IT audit, we need to make sure the audit committee see a RED when SSL v2 exists
If we are working with web developers we need to make it plain their software will not be accepted unless it uses at least SSL v3, or ideally TLS
If we are managing projects we need to fail any provider who tries to sell us software which uses SSL v2
WE are the ones who need to tech the buyers/developers/project managers/CEOs that it will hurt them if SSL v2 is used - but we need to do it in business language. The PCI DSS is very useful in this respect as it can force card services providers to improve, and we can hopefully use them as an example to persuade other organisations.
