1) What is an SSL attack?
The “SSL attacks” we've seen mentioned recently are actually attacks on the SSL certificate scheme, against the specific certificate authority (i.e., stealing the certificate), or in the form of a man-in-the-middle (MITM) attack against the user (which is the ultimate goal). Or you could say that they refer to all these aspects combined.
SSL is a cryptographic protocol used for secure transactions on the internet. Very simply put, it's the underlying technology that's being used when you see https:// in the address bar rather than https:// – for example when logging in to your online banking system (HTTP stands for Hyper Text Transfer Protocol, and HTTPS stands for HTTP Secure). These secure sites should have a valid digital certificate (or an SSL certificate) issued by a certificate authority (CA): This certificate is intended to prove that the entity (e.g., a bank) is really who or what it says it is, not an attacker just posing as the entity.
The problems arise when an attacker is able to steal such a certificate, which gives him a veneer of credibility when executing a man-in-the-middle attack (intercepting communication between you and the bank, running a (digitally signed) phishing site, and so on.
2) What does this mean for the end-user?
Well, the user should be cautious (as always), but there's no cause for panic. The implication for him is that if someone can impersonate the server with which they're communicating, something that looks like a trusted communication channel is not, in fact, trustworthy. But in order to do that, the attacker has to get inside the communication channel between the user and the server (e.g., bank). Simply put, the SSL attack enables the attacker to say: “Hey, I'm your bank.” But he first needs to find a way to ensure that the victim will be connecting to his server instead of the real bank server. If he can do that, then the transaction has already been compromised, with or without the SSL “vulnerability.”
3) What can the end-user do to protect themself?
The end-user should at least check whether that lock icon is displayed in the web browser (bearing in mind that tricks for counterfeiting that icon are almost as old as phishing). One should ensure that their connection is https:// over port 443, not https:// over port 80. If one is using a modern browser (and it's not a good idea to continue using older, less well-supported and unpatched browsers), they should see everything as green in the address bar and watch out and check for extended information about the connection. And most importantly, they shouldn't proceed with the connection (as too many users do) if something looks fishy. Obviously, the regular advice still applies – use multilayered protection, keep anti-virus and operating system software updated and patched, and (most of all) use common sense.
4) What is a trustworthy connection?
- You have an up-to-date, fully patched browser that implements HTTPS correctly populated with trustworthy certification authorities installed and correctly configured so that it will know when certificates are revoked and CAs no longer considered trustworthy.
- The website to which you're connected offers a valid, up-to-date signed certificate.
- The site matches the certificate and its holder's name.
If you aren't sure this all applies, or that the transaction is routed through a “safe” series of hops, or that the protocol itself is robust enough to withstand attacks on the encryption, you can't consider your connection trustworthy.
5) Is it time to ditch the CA system?
Perhaps that time is approaching. The problems aren't so much with the technicalities of SSL, though, as with the difficulties of implementing a system that assumes trust in the provider without a realistic mechanism for determining where you can safely invest that trust.
According to the Electronic Frontier Foundation, there are effectively more than 650 CAs trusted by the main browsers. If you take a look at here and see who and where those CAs are, the question is this: How many of them do you know, let alone trust?
There is no global authority that can be trusted to authenticate that mixture of state-owned, commercial and indeterminate authorities. Who, to coin a phrase, should authenticate the authenticators? Can you trust market forces, vested interests and political expediency to keep you safe where the system assumes that you will trust the provider even though there is no overarching mechanism to ensure that trust invested in CAs is justified.
6) Do we have an alternative?
Apart from not trusting any website, you mean? :) Well, there's DNSSEC, though in such a case, you're just investing trust in the same registrars who are (intentionally or not) providing the bad guys with malicious domains along with the legitimate domains that their victims use, and in ICANN and the same authorities that already administer top level domains.
The Moxie Marlinspike Convergence protocol model of “trust notaries” using consensus from multiple notaries to authenticate is an interesting idea and it will be interesting to see how much traction it gets. However, it's not a solution that spares the user the need to think for themself, and it has to compete with an entrenched commercial model.
7) Are the DigiNotar attacks really more significant than Stuxnet?
In some senses. While a Stuxnet-type attack might, in principle, cause a major physical disaster (note that I'm not saying that's likely, and certainly not with the Stuxnet code that we've actually seen), it does seem to have been a highly targeted attack which has been hyped to blazes (pun not entirely unintentional).
DigiNotar is significant in itself because of the range of affected targets, but even more so as a symptom of a more generalized attack against an infrastructure we've been conditioned into regarding as secure, and clearly isn't. Will anyone who reads the news ever trust those little padlock icons again, when there are so many virtual bolt cutters around?
Róbert Lipovský contributed to this article.