1

Although many SSL certificates have been boasting extravagant guarantees -- typically around $10k minimum to $250k per breach -- to ensure their certificates are valid, to this date, I've heard that there has never been a single payout due to the fact the certificates limit the warranty to just data transmitted en-route rather than post-transmission (which is very rare because hackers usually target storage databases to get more data in one shot).

Still, now that a vulnerability has been discovered in TLS 1.0 which allows the encryption to be broken for data stored in cookies (I got the news from this article: http://www.theregister.co.uk/2011/09/19/beast_exploits_paypal_ssl/) does that mean SSL Issuers are responsible for data stolen since the attack goes straight to the encrypted data while transmitted.

Also, is it possible for the CA's to force clients to obtain new certificates which use TLS 1.1 or another proven technology, in order to reduce the risk (or allow them to continue using 1.0 without the guarantee), or is that not feasible since I'm sure many SSL owners use shared hosting or outsource management so they have little voice in the process.

Andrei Botalov
  • 5,317
  • 10
  • 46
  • 73
theonlylos
  • 223
  • 1
  • 6
  • 1
    To pass any judgement on a warranty, you need to cite one as an example. Voting to close this until we get something that makes it other than subjective. – Jeff Ferland Sep 22 '11 at 19:24
  • Sorry for the lack of details. Just for simplicity, I'm providing the link for the Verisign EV certificate as it has a $1.5 million warranty, but also I picked that brand as I know it's the most ubiquitous when it comes to online security (although I'll say Comodo and GeoTrust also are brands I'd link to) http://www.verisign.com/ssl/buy-ssl-certificates/extended-validation-pro-ssl-certificates/index.html – theonlylos Sep 22 '11 at 21:40
  • Also just to clarify, as explained in the accepted answer, the new SSL attack is more of a man in the middle attack rather than the certificate being decrypted and broken, so it looks like most SSL issuers won't have to worry about payouts from the new attack. – theonlylos Sep 22 '11 at 21:48
  • 1
    Questions about whether or not they will have to pay out are offtopic, and speculation anyway. You could edit the question to just be that final paragraph, then it would be on-topic and we could re-open. – Rory Alsop Sep 22 '11 at 22:21
  • Okay, sorry about that I'll make that change right now. I think that I should've worded it first by saying "would it fall within the standard warranty of SSL certs" rather than asking will payouts be mandated since I based the question heavily on the fine print of those guarantees rather than whether it will be pursued – theonlylos Sep 23 '11 at 01:33

2 Answers2

2

There are two parts to SSL/TLS: ensuring the confidentiality and the integrity of the communication, and knowing who each participant is. Most of the issues related to SSL have to do with the second part, which is rather more complicated. You can read some explanations on this topic in the question when is it safe to click through an SSL warning message?

Consider what would happen if you took certificate authorities out of the picture. Certificate authorities provide a public-key infrastructure. Without them, servers would all have self-signed certificates, and each client would have to figure out whether the server is the one they intended to talk to somehow (for example, by having been given the server's public key over some trusted medium such as meeting with the server administrator in person).

The SSL flaw uncovered in the BEAST exploit concerns the first part of SSL, the one that is unrelated to the PKI. It concerns the way the cryptographic primitives are used to build a secure channel, not the way for the two ends of the channel to authenticate each other. Therefore certificate authorities are cannot be responsible for the flaw. It is not their fault if any keys are discovered through this attack (though as I understand it the attack allows the attacker to decrypt the content of one transmission, but not recover the server the server's private key anyway).

This doesn't mean that there isn't a CA somewhere that has contracted to pay a hefty sum if such a vulnerability in SSL was found. But it would not be paying for something that it was responsible for, it would be acting as an insurer. For that matter, there may well be professional insurers who end up reimbursing damages caused by this vulnerability — but I don't think any CA is in this market.

Community
  • 1
Gilles 'SO- stop being evil'
  • 51,415
  • 13
  • 121
  • 180
  • Ah I see. So this brand new flaw is just another man in the middle attack, so just like prior exploits, the CA's aren't on the hook because this attack isn't breaking the encryption but rather posing as the valid party and then being given access to the data? I had a feeling the new attack wasn't within the realm of the CA's but the way it was explained in many articles made it sound like SSL has been broken and that the certificates were useless. – theonlylos Sep 22 '11 at 21:44
  • 1
    @theonlylos It is indeed a MITM (though from what I understand it's more involved than that: it needs some code running on the client in order to be practical). The attack is breaking the encryption and are not a matter of posing as the valid party, that's why the CAs aren't involved. – Gilles 'SO- stop being evil' Sep 22 '11 at 22:02
  • I see, thanks very much again for that clarification. The fact extra code was used really is what threw me off because I'm used to hearing about MITM attacks which are simpler, so that point really now helps put this in perspective. – theonlylos Sep 23 '11 at 01:37
1

The BEAST attack has nothing to do with certificates or certificate authorities. It is a crypto break.

Also, a browser that negotiates TLS 1.0 or SSL 3.0 will still be vulnerable. Unless the site only supports TLS 1.1+, a downgrade attack is possible too. Also, the theoretical problem persists even in 1.1+ - it's just mitigated. See recent posts on the IETF TLS list for more on that last point.

Steve Dispensa
  • 3,441
  • 16
  • 20