Actually the article does not say that the SmartScreen client uses SSLv2; it just says that the server which SmartScreen contacts would be happy to accept incoming connections using the SSLv2 protocol. It would be surprising if SmartScreen indeed used SSLv2: most plausibly, Microsoft reused their own existing code for a SSL client, and that code does SSLv3+ by default. Using SSLv2 would imply extra effort for no gain.
Also, most of what is said about security of SSLv2 (in this article or elsewhere) is covered with a heavy layer of FUD. SSLv2 has issues, sufficient to warrant not using it (especially since SSLv3 and TLS are available), but not as dire than what is usually suggested. See for example this page; it is claimed that:
- Message integrity compromised. The SSLv2 message authentication uses the MD5 function, and is insecure.
- Man-in-the-middle attack. There is no protection of the handshake in SSLv2, which permits a man-in-the-middle attack.
- Truncation attack. SSLv2 relies on TCP FIN to close the session, so the attacker can forge a TCP FIN, and the peer cannot tell if it was a legitimate end of data or not.
- Weak message integrity for export ciphers. The cryptographic keys in SSLv2 are used for both message authentication and encryption, so if weak encryption schemes are negotiated (say 40-bit keys) the message authentication code uses the same weak key, which isn’t necessary.
The first point is downright FUD. It is a knee-jerk reaction: "MD5 ? BAD BAD BAD !". It is unsubstantiated. I am not saying that MD5 is rock solid; but I claim that the integrity check in SSLv2 is not that easy to defeat.
The second point is, at best, confusing and misleading. The "man-in-the-middle attacks" which are alluded to are the following: in SSL (v2, v3+...), both client and server may support several cipher suites; the client sends the list of suites it supports, and the server chooses one. With SSLv2, an attacker who is in position of doing a MitM can alter the list sent by the client, to force the client and server to use a specific cipher suite (within the set of suites that both supports, of course). The alteration is not detected later on (whereas, in SSLv3+, it would be detected at the end of the handshake). Then, the reasoning goes, SSLv2 is weak because the attacker can force client and server to use a "weak cipher suite" (e.g. one with 40-bit keys). But can it ? In fact, the attacker can force the use of a cipher suite that both client and server were already ready to accept -- and THAT is the weakness. What the attack breaks is the optimistic upgrading to stronger cipher suites when available; but the real weakness is when client and servers accept to use 40-bit keys.
The fourth point is more of the same: it says that if a key is weak and used for two usages, then breaking the key allows attacking the two usages. But the true weakness here is using a weak key.
Only the third point is really true: an attacker can force a connection close, and the machines cannot know whether the closure was intended by the peer. This is a serious problem with HTTP/1.0 without Content-Length attribute but not with other protocols, including HTTP as it is used nowadays.
Summary: SSLv2 is "broken", but not as much as is rumoured. No, a SSLv2 connection cannot be instantly decrypted by an attacker. And I personally deem it highly improbable that the SmartScreen client uses SSLv2; it would make too little sense.
(None of the above says anything about privacy issues with SmartScreen.)