EFF reports on the security of SSL:
The most interesting entry in that table is the “CA compromise” one, because those are incidents that could affect any or every secure web or email server on the Internet. In at least 248 cases, a CA chose to indicate that it had been compromised as a reason for revoking a cert. Such statements have been issued by 15 distinct CA organizations.
Peter • October 27, 2011 7:37 AM
I’m amused to note that my browser doesn’t know the CA of the EFF certificate (assuming that it’s the genuine cert that I’m seeing), and also to note that the chain for the cert alternates between “AddTrust External CA Root” and “UTN – DataCorp SGC” 7.5 times. I haven’t checked in detail, but it seems to be taking self-signing to extremes.
jmdesp • October 27, 2011 7:47 AM
@peter : Noticed that one a few days ago also. That’s mostly a NSS problem, because the server presents an intermediate cert that is signed by a trusted cert, but NSS picks another intermediate cert instead and then enters a loop.
So it seems NSS doesn’t correctly choose the shortest path, and doesn’t correctly identify it has entered a loop and should break out of it.
Hugo • October 27, 2011 7:49 AM
Convergence.io is not the solution. It requires knowledge which most of the internet users do not have.
No matter how solid the design of your security solution is, if users don’t use it the way they should, your solution is worthless. Therefor, in my opinion, a security solution should be easy and simple and should only require a minimum amount of interaction.
david • October 27, 2011 7:59 AM
@Hugo All convergence.io needs is to be adopted by the three major web browsers. Sounds good compared to getting hundreds of thousands of admins around the globe to agree on and implement some SSL replacement which won’t be as good… like DNSSEC.
Paul • October 27, 2011 8:18 AM
convergence.io ++
arschmeno • October 27, 2011 8:26 AM
how ironical: my browser warned me of the comodo cert used by the eff for their “support bloggers rights” button on this page 🙂
bobh • October 27, 2011 8:31 AM
@Hugo
“… if users don’t use it the way they should, your solution is worthless.”
HIPAA mandates password strength and quarterly update. Doctors can’t be bothered. Staff logs in for them. Hardly HIPAA’s intent but reality.
Kudos for your comment.
Hugo • October 27, 2011 8:48 AM
“All convergence.io needs is to be adopted by the three major web browsers.”
Browser support is not the only thing. It also requires uses to keep their browser up to date. Now, take a look at this: http://www.netmagazine.com/node/1465
And how is a list of CA’s really different from a list of notaries?
Natanael L • October 27, 2011 9:20 AM
@Hugo: At least, with notaries there can be dissenting opinion.
Hugo • October 27, 2011 10:18 AM
Convergence doesn’t change anything according to how to deal with security. The fact that Diginotar was hacked doesn’t mean that all CA’s are insecure.
Imagine that the whole world moves from CA to Convergence. We have a lot of notaries to chose from. This goes well for several years. But what if then several Notaries get hacked? Does that mean that all notaries are them insecure? Does that mean that Convergence is a bad system?
Don’t get me wrong. I like the idea of Convergence. I like the idea of not having to buy a certificate. And the impact of a hacked notary is less than the impact of a hacked CA. But no matter if you are a CA or a notary, you have to have your systems well protected. If trust is your business, you have to take security very very seriously. That’s where Diginotar failed. It’s an organisation that failed in security, not an entire system.
And there is one thing that Convergence is not covering: SSL client authentication.
Balau • October 27, 2011 10:20 AM
@Hugo
And how is a list of CA’s really different from a list of notaries?
Three things come to mind:
I agree with you on the importance/problem of keeping the browser updated. OEMs can package the OS so that browser silent updates are enabled by default, and that’s a start but it’s not enough.
Up to now, from an user’s point of view, the problem with convergence.io is the latency of the first access to an https-enabled site. Other than that, it’s pretty seamless.
Hugo • October 27, 2011 10:55 AM
Another interesting thing: with the CA solution, hacking a DNS was not sufficient to redirect users to malicious website without their knowing. This is not the case with the Convergence solution. This puts more pressure on DNS server security.
Hugo • October 27, 2011 12:27 PM
One more thing: for performance reasons, we’ll need a lot of notaries. It’s not unthinkable that certain countries will use this as an excuse to have national notaries which residents are forced to use. Think about this some more and image what the Chinese people will think about Convergence…
Johnston • October 27, 2011 1:16 PM
It’s telling that the DNSSEC advocates now mainly push the technology for reasons other than what it was intended, like replacement of the CA model. And even then, we’re talking about using a baseball bat as a flyswatter that will end up doing more harm than good.
convergence.io is elegant.
There are other alternatives as well: the Firefox addon Cert Patrol, and the web browser xxxterm has the ability to save certs and check for changes to detect MitM attacks.
I doubt we’ll see something like convergence.io merged directly into mainstream browsers; I’d be shocked if vendors didn’t receive handsome payments for the addition of various CAs, and convergence.io would eliminate this racket.
Gary • October 27, 2011 1:31 PM
Balau nails it — it’s not about whether any particular notary is trustworthy, it’s about whether there’s any disagreement between notaries. So if you can just ensure there’s no collusion between notaries, you can ensure the integrity of a certificate. This leads to interesting scenarios like using one notary from the NSA, and another from, say a Chinese government notary.
Also, since all the notaries need to do is download the cert (not actually perform any cryptographic operations on it), the performance requirements should be fairly low.
Crl • October 27, 2011 1:57 PM
According EFF, those “CA Compromise” CRL entries as of June were published by 10 distinct CAs.
So, from this data, we can observe that at least 5 CAs have experienced or discovered compromise incidents in the past four months.
What are the names of these 5 additional CAs?
Clive Rrobinson • October 27, 2011 2:20 PM
First of there are one heck of a lot more problems with SSL than just the issue of CA’s.
That said I can see a problem with convergance.io that may well be exploitable.
It is derived from the Perspectives Project out of CMU but there appears to be a difference in that Convergence.io uses a local cache rather than talk to one or two notaries each time.
As we know the likes of Zeus/SpyEye are quite sophisticated and will get into your machine and thus this local cache is almost definatly going to become a target. And if a user can change the selected notaries then I’m fairly sure malware can as well on any platform (it only needs the users privileges).
I’ve been meaning to take a long hard look at both the Perspectives Project and Convergance.io to look at how I would obviate them, but I’ve had other issues to contend with recently. However I’m reasonably certain they both have exploitable weaknesses just on looking at the 20,000ft descriptions.
Gary • October 27, 2011 2:32 PM
@Clive: If you can’t trust the integrity of the endpoint you’re using, any conceivable network security design that uses that endpoint is moot. You could suppress SSL warnings, add your own root cert to the browser cache, turn SSL off entirely but show the user that it was turned on, etc.
Clive Robinson • October 27, 2011 10:16 PM
@ Gary,
“If you can’t trust the integrity of the endpoint you’re using, any conceivable network security design that uses that endpoint is moot.”
And thereby hangs the description of the real problem SSL/TSL/IPsec and the various proposed improvments such as Convergance.io are not solving. And as I indicated recent improvments to Zeus/SpyEye have got around out of band authentication in various ways.
At the heart of the issue is that on current commodity OS designs you can not trust the integrity, thus the security as an end point due to the inherant OS design.
However there are a couple of ways around this issue, improve the integrity of the existing end point “and or” move the end point into a high integrity environment.
As Nick P and others have pointed out on a number of occassions there are OS designs out there where the integrity is vastly improved.
And if you have a look back through this blog you will see numerous comment by myself, Nick P and several others that show we have been giving serious thoughts about moving the “end point” into a trusted token / dongle / device for some time with regards to authenticating transactions in the likes of banking and other financial systems.
So the problem is far from insurmountable and something that realy needs to be addressed properly.
And this is the secondary problem the likes of Microsoft and various entertainment IP rights holders don’t want to solve the integrity problem they want to use it as an excuse to re-brand the old discredited “trusted platform” as UEFI or “secure boot”.
They are using the old Herman Goring trick of redefining the meaning of words which Geroge Orwell highlighted in various of his works including 1984. Basically their definition of “trust” means the end user is “untrusted” and thus should be made “impotent” by locking them out of the trust chain and as part of the process forcing “vendor lock in” via the hardware manufacturers…
Thomas • October 28, 2011 1:31 AM
@Clive
“So the problem is far from insurmountable …
… the likes of Microsoft and various entertainment IP rights holders don’t want to solve the integrity problem …”
Looks to me like the technical problem is far from insurmountable, but throw in vendor politics and it’s a different kettle of fish.
Clive Robinson • October 28, 2011 5:11 AM
@ Thomas,
“… but throw in vendor politics and it’s a different kettle of fish.”
Sadly yes, many of our security woes can be laid at the foot of that door.
The thing is the IP holding industries don’t want end users to have any control or for that matter rights, because from their old business model it’s anti-profit.
What they want is all the rights for themselves, even those they are not entitled to by law such as setting up a “rigged market” which breaches not only anti-competition legislation but also legislation to do with monopolies.
Microsoft has been found guilty of such behaviour a number of times, and have been heavily fined, yet they still pursue the same old business model, all be it with a different shrink wrap look.
As consumers we are the sacrificial lambs we either get with their program or stay out in the cold.
And unfortunatly in the US it’s not just the politico’s letting them do this the judiciary are as well. Just recently the US SC turned down an appeal about the “first sale doctrine”, which limits an IP holders control of the “impression” or physical media on which their IP is sold. In the past you were allowed to buy something like a book and sell it second hand without let or hinderance. Well that all stops now the EULA is king, you buy a strictly non transferable licence with whatever restrictions the IP holder wants to apply nomater how ridiculous. So you choice is effectivly either accept and play along and pay huge sums for nothing, or breach the EULA and get prosecuted. The other two options are don’t use an alternative product or don’t play at all.
The Joy for MS & Co with “secure boot” is it effectivly removes the “use an alternative product” option…
Thomas • October 28, 2011 6:59 AM
@clive
“they still pursue the same old business model,”
Yeah, I just read something about Win8 and IE10 bundling…
“As consumers we are the sacrificial lambs we either get with their program or stay out in the cold.”
That’s OK, Penguins like the cold
“… or breach the EULA and get prosecuted.”
Or choose a EULA that you can live with, like the GPL.
“The Joy for MS & Co with “secure boot” is it effectivly removes the “use an alternative product” option… ”
Maybe once its perfected.
Until then it’s just a speed-bump, like the secure boot path of the playstation, Xbox and every other console out there that’s been subverted.
Nick P • October 28, 2011 8:21 PM
@ Thomas
“Maybe once its perfected.
Until then it’s just a speed-bump, like the secure boot path of the playstation, Xbox and every other console out there that’s been subverted.”
It might not be so easy. Certain sections of the INFOSEC research community, and me, have been moving toward combined hardware-software security architectures. These typically involve some truly read-only boot part, signed code & cryptography protecting RAM & external storage. All of this, including processor, would be contained on one chip.
It’s doubtful the average person could subvert that properly, even with instructions. The more I think about the idea, though, the easier it is to do a DRM-style device with it. It would be hard to modify, the modifications might be detectable, & the DMCA could be used against anyone cracking it. It’s why this kind of security is a double-edged sword: it imposes control on information flow, which can be used for or against us.
Well, the combined ROM & flash boot is already in Chromebooks. There’s already software to restrict was business computers can do. Intel’s vPro and various ARM SOC’s are of similar complexity to what I mentioned above. The odds that some company will successfully pull the scheme off are increasing every day.
Crl • October 29, 2011 2:05 AM
[Update 10/27/2011: there was an error in our manual de-duplication of CA organizations. Rather than 15 total compromised organizations and 5 since June, the CRLs indicate 14 total and 4 since June]
https://www.eff.org/deeplinks/2011/10/how-secure-https-today
Subscribe to comments on this entry
Sidebar photo of Bruce Schneier by Joe MacInnis.
Toby Speight • October 27, 2011 7:33 AM
I’ve never really understood the SSL model that requires only a single chain of trust. Accepting only certificates that are signed by, say, at least two CAs (more like PGP’s model) would at least give affected parties a window of time to recover from a compromise. An adversary who could take out multiple CAs at once could exist, but it would certainly increase the difficulty. And as for web browsers that unquestioningly trust hundreds of CAs as sole authority for a certificate, well that beggars belief entirely.