So, if a server is accepting sslv2 at all, then all connection (including TLS connections) to the same server are practically compromised. That is, assuming both sslv2 and TLS use the same key. Therefore, having allowed sslv2 in the past would only jeopardize clients foolish enough to use it, but now it endangers every single client. Is that right?
Two very important things come form that:
Everyone who had sslv2 enabled at any point in the past must get a new SSL certificate right away. Right?
Windows XP has TLS disabled by default, which in practice means unavailable. So we must cut them off. Therefore Windows XP is dead-dead, starting today. Right?
> Everyone who had sslv2 enabled at any point in the past must get a new SSL certificate right away. Right?
No, unlike Heartbleed, the key isn't leaked directly. Revocation and generating a new key isn't necessary - just patch your stuff and disable SSLv2.
> Windows XP has TLS disabled by default, which in practice means unavailable. So we must cut them off. Therefore Windows XP is dead-dead, starting today. Right?
I kept v2 running because we couldn't bring ourselves to prevent connections from clients of our clients, it's not our place to tell them what to do, especially if it only harms them and no one else. This time it harms everyone, including high-privilege users, so it's a lot easier to justify.
So, if a server is accepting sslv2 at all, then all connection (including TLS connections) to the same server are practically compromised. That is, assuming both sslv2 and TLS use the same key. Therefore, having allowed sslv2 in the past would only jeopardize clients foolish enough to use it, but now it endangers every single client. Is that right?
Two very important things come form that:
Everyone who had sslv2 enabled at any point in the past must get a new SSL certificate right away. Right?
Windows XP has TLS disabled by default, which in practice means unavailable. So we must cut them off. Therefore Windows XP is dead-dead, starting today. Right?