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.