The security blogosphere is agog over some recently published vulnerability information describing attacks against the venerable secure sockets layer (SSL) protocol -- you know, the one that almost the entire Internet relies on for securing transactions as they transit the Net. But how does this impact you? Let's try to separate the wheat from the chaff.
Let's start by looking at the vulnerability itself. It is a "man-in-the-middle" (MitM) attack in which an attacker can use an SSL feature called "negotiation" to inject bad stuff into an SSL session. Right, so that's not good news. But the sky isn't exactly falling yet, so we can all remain calm for now. Let's put things into perspective here.
Yes, by all accounts, there seems to be a serious weakness in SSL. As of right now, however, that weakness is known to a relatively small collection of folks who are working to come up with some solutions to the problem. That said, the technical details of the problem have been published, and there's little doubt that attacks will begin to surface over time.
However, in order to use an MitM attack to actually effect damage isn't entirely trivial. The attacker either needs to be on the same local network as the client, or in the network path between the client and the server. By far, the most likely of these scenarios, at least in the near term, is to attack systems on a local network. We have a little bit of leverage there.
For starters, we should be using secure VPNs to connect to trustworthy networks when we're using non-trustworthy ones -- like hotel and coffee shop Wi-Fi hot spots. VPNs are pretty ubiquitous now, even for small businesses.
And I did say that there's a community of people working on solutions to this problem. It would surprise me if we don't start seeing patches to SSL stacks in the near future. At least for the server side of this equation, these solutions should be available in pretty short order. The real challenge will be getting those patches deployed on our production systems, but then we should all have a handle on patch and configuration management, right?
So no, the sky isn't falling. There's a big defect lurking on the horizon, and we all will need to pay attention to it, but at present, we've seen no attacks or even proof-of-concept code released in the wild.
But there are bigger issues at stake here, folks. Let's take a closer look and see what we can learn from them.
By any account, SSL is a vital part of our security infrastructure these days. Anyone doing threat modeling or designing security reviews will no doubt point out that SSL is a security dependency that all other components build on top of. When we build our systems on top of other components, we need to understand those dependencies and how they can impact our own systems. A great starting point that has worked for me is to look at a system's design and identify its highest-value components (from an attacker's perspective).
High-value targets often include components like infrastructure dependencies, authenticators, input validators, output encoders, access control mechanisms and important business logic. We should then be directing the lion's share of our security testing on those high-value targets.
Now, an infrastructure dependency (like SSL) is an interesting situation, since in most cases, we're working with third-party SSL implementations that we cannot (easily) change. We should still be doing rigorous security testing -- fuzzing comes to mind -- of third-party code, particularly when our own applications' security depends on that code to work correctly.
But SSL is truly infrastructure, right? Who is in charge here, and what testing has been done on that infrastructure code and design? Would rigorous testing have uncovered this particular flaw early on? Maybe, maybe not. (And I wouldn't counsel betting on "maybe.")
So where does that leave us with SSL? Well, as with selecting something like a standard encryption algorithm -- SSL is a protocol, not an algorithm per se -- selection needs to be careful and deliberate, and it should be revisited periodically. That selection process should include rigorous external, independent review and testing. After all, mistakes made here are multiplied across all the software that gets built on top of these components.
I'm not trying to slight those that developed SSL, but I do think this defect puts a spotlight on the importance of due care in selecting and implementing code that so much is going to ride on.
No doubt, when SSL was first designed, no one could have possibly predicted just how important it would become. That misjudgment is clearly no longer a viable excuse, however. The time is right to look back a bit and review our assumptions and fix that which is broken. I'm betting this latest vulnerability in SSL isn't the last.