6 Answers
6

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:

The client sends a ClientHello message in which it states the maximum protocol version number it accepts (TLS 1.0 is thus announced as "SSL 3.1").

The server responds with a ServerHello message which specifies the protocol version which will be actually used.

Client and server exchange a few other messages, with some hefty cryptography in it, resulting into a "shared secret" which is then used as key to encrypt and decrypt data.

At the end of the handshake, just before sending and receiving the actual application data, two 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.

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

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.