There have been numerous reports recently that a new Man-in-the-Middle attack has been developed which works on the previously secure SSL 3.0 and TLS 1.0. The details of exactly what can be done with this attack have yet to be fully explored, but the bigger point is: what do you do now?
Well… As I’ve declared many, many times before, you must assume that everything will be compromised at some point, so it should be planned for. Since it’s not likely that SSL 4.0 (or whatever spec will prevent this new attack) is going to be codified and deployable for some time, you have to have backup plans.
Realistically, there are two main things you can do as someone who uses SSL/TLS to secure data in transit. The first is you can do your part to be sure that there is no Man-in-the-Middle attack happening on your end of the connection. While ISP-level man-in-the-middle attacks aren’t impossible (or even really difficult if you have access to a big enough line and BGP), they’re certainly not common, so the “last mile” is what needs to be protected most. On the server end, there’s the issue of shared hosting. Even when running on a dedicated piece of hardware, you will still be sharing a switch with other servers. Any other rogue server on the same physical subnet is in a position to perform ARP poisoning or simple timing attacks on your data streams (metasploit.com had this issue a while back). Setting static ARP for the gateway is a good way to prevent that, but getting your servers in-house or in a reputable colo goes a long way as well. On the client end, static ARP entries may not be a reasonable method due to a more static environment, but physically and electronically auditing your network to see what’s attached is very doable. Keep a healthy dose of paranoia about you when doing so, and be sure to keep the wifi locked down.
The second line of defense against this new attack is mostly in monitoring your environment and attempting to detect issues before they get out of hand. The new SSL/TLS attack itself is supposedly very hard to detect at the end points using current methods, as the attack deals in the (re)negotiation portion of the conversation, which isn’t fully protected by the math that binds the certificates together. So, detection needs to occur elsewhere. Looking for abnormal protocol usage (in the wrapped protocols) or errors dealing with additional data would be a place to start. Monitoring the applications and data being accessed would also likely show some trace of a successful attack.
Unfortunately, there’s no single good defense which has been developed yet, so it’s best to diversify your efforts. Of course, you knew something like this would happen eventually, and all of these defenses (and many more) are already deployed, right? ;-)