EFF to Verizon: Etisalat Certificate Authority Threatens Web Security(eff.org)
eff.org
EFF to Verizon: Etisalat Certificate Authority Threatens Web Security
https://www.eff.org/deeplinks/2010/08/open-letter-verizon
5 comments
The thing this highlights is the way that CA certificates are all-or-nothing. You can't say "This is a CA, but they should only be trusted for certificates where the CN matches this pattern".
Separate CAs were always a bogus idea. They should have just issued certificates in parallel with domain names - so if I registered "google.com", I also got a certificate from the domain registrar which allowed me to sign certificates for "<anything>.google.com".
Separate CAs were always a bogus idea. They should have just issued certificates in parallel with domain names - so if I registered "google.com", I also got a certificate from the domain registrar which allowed me to sign certificates for "<anything>.google.com".
I've pretty much always felt that there should be no central authority. I don't know much about the actual protocols in use, but it's my understanding that they're single-signer.
What I would prefer is a multiple-signer system. Each resource can have a list of signatures indicating entities that trust the resource. Each entity can have a list of other entities they trust. Then to verify a resource, you search the web of trust until you hit max_separation while looking for a path from you (source) to the resource (sink).
So to sign my payment processor, I'd self-sign and have visa sign. I'd get a personal signature from the .com authority. You trust visa if you're interested in payment, and you trust the .com authority if you're interested in identity. There would be no difference between authentication and authorization by default, but that would be easy to patch in via specialized authorities.
If some entity turns out to be overly trusting, it would be trivial to replace, since all trust is directed. Just add a new, trustworthy, intermediary. The downside is that much more computation would be required to find the links, but I'm confident that would remain manageable because of the human element; we wouldn't include more trustworthy entities than bureaucracy allows.
There are holes in this scheme, sure. It might even be a subset of the current technology. But I'm fairly certain it'd be a superset of the current practise.
What I would prefer is a multiple-signer system. Each resource can have a list of signatures indicating entities that trust the resource. Each entity can have a list of other entities they trust. Then to verify a resource, you search the web of trust until you hit max_separation while looking for a path from you (source) to the resource (sink).
So to sign my payment processor, I'd self-sign and have visa sign. I'd get a personal signature from the .com authority. You trust visa if you're interested in payment, and you trust the .com authority if you're interested in identity. There would be no difference between authentication and authorization by default, but that would be easy to patch in via specialized authorities.
If some entity turns out to be overly trusting, it would be trivial to replace, since all trust is directed. Just add a new, trustworthy, intermediary. The downside is that much more computation would be required to find the links, but I'm confident that would remain manageable because of the human element; we wouldn't include more trustworthy entities than bureaucracy allows.
There are holes in this scheme, sure. It might even be a subset of the current technology. But I'm fairly certain it'd be a superset of the current practise.
... and if the owner of somerandomdomain.net lets his domain expire, you're faced with the choice of (a) put his SSL key (along with a couple thousand others) on the global CRL, which then grows to monstruous proportions or (b) let the old somerandomdomain owner play man-in-the-middle games with the new somerandomdomain customers?
Also, would that mean that VeriSign (.com registrar) would be your only option for a .com SSL certificate?
(I'm not saying it's a bad idea to limit CA authority to a certain top-level or second-level domain, it's just that I see certain problems with doing it wholesale and in parallel).
Also, would that mean that VeriSign (.com registrar) would be your only option for a .com SSL certificate?
(I'm not saying it's a bad idea to limit CA authority to a certain top-level or second-level domain, it's just that I see certain problems with doing it wholesale and in parallel).
It would only have to go onto the CRL until it expired. The CRL would become large, but it would still be a couple of orders of magnitude smaller than the global DNS itself, and we manage to deal with that OK.
The idea would be that the certificate comes with the domain name, as the whole ball of wax. Verisign aren't the only _registrar_ though - GoDaddy, MelbourneIT etc. are all registrars - VeriSign's claim to fame is that they manage the .com _registry_.
The idea would be that the certificate comes with the domain name, as the whole ball of wax. Verisign aren't the only _registrar_ though - GoDaddy, MelbourneIT etc. are all registrars - VeriSign's claim to fame is that they manage the .com _registry_.
Oddly enough, GTE Cybertrust doesn't actually seem to be the same Cybertrust that Verizon Business bought in 2007 (as information on "GTE Cybertrust" predates the incorporation of "Cybertrust" by a good ten years).
It looks like GTE Cybertrust was part of GTE Internetworking, which would have been absorbed into the Bell Atlantic-GTE merger which created Verizon.
That seems odd.
It looks like GTE Cybertrust was part of GTE Internetworking, which would have been absorbed into the Bell Atlantic-GTE merger which created Verizon.
That seems odd.
You don't have to delete certificate, you can mark it as "Never Trust".
On OS X, it is possible to disable just Etisalat's Comtrust certificate. Click the lock icon to view that certificate, drag the large certificate icon to your desktop, then drag it into Keychain Access (i.e. into your login keychain). At that point, you can set the trust settings on that certificate to Never Trust.
Neat! I'm surprised and happy this works; I presumed the Apple SSL framework would only check the trust setting on the root.
Unfortunately, you can't (as far as I can tell) do this with Firefox; import the Comtrust certificate and turn off "use to validate websites", restart Safari, and it'll still accept the Etisalat site.
What does work is to take the CER file, pop it open in a hex editor, whack 1 byte of it, and import that; the result is a mismatched certificate error on sites signed by Etisalat/Comtrust.
Unfortunately, you can't (as far as I can tell) do this with Firefox; import the Comtrust certificate and turn off "use to validate websites", restart Safari, and it'll still accept the Etisalat site.
What does work is to take the CER file, pop it open in a hex editor, whack 1 byte of it, and import that; the result is a mismatched certificate error on sites signed by Etisalat/Comtrust.
...go to http://j.mp/a11K0t [Etisalat site]
> This site requires Internet Explorer !
If you were looking for more reasons to dislike these guys I guess...
> This site requires Internet Explorer !
If you were looking for more reasons to dislike these guys I guess...
In OS X Opera, you can go to Preferences -> Advanced -> Security -> Manage Certificates -> Authorities. Select the GTE CyberTrust one and either Delete it, or disable it from the "View..." screen.
How would revoking a CA's certificate work? In particular:
* The certificates that they already issued would keep working, right? Their customers would just need to find another CA when they need to renew their certificates? I'm pretty sure that that's correct, because they're not talking about having browsers remove a CA from the trusted list. (They couldn't really. The one on the trusted list is Cybertrust, not Etisalat.)
* In that case, how do they even revoke the certificate? If they keep a copy of the certificate, wouldn't it still be able to generate valid certificates? Or is it somehow setup such that Cybertrust can easily revoke the certificate? I can't really think of a great way to do that given how I think the certificates work in general. I guess it could require a temporary key, say for the month. But I don't see how that would stop them from signing things with the temporary key that they have for August and just saying that the date it was issued is sometime in August 2010.
* Even if I'm wrong about that, if I'm right that certificates that they've issued would keep working, couldn't they generate a bunch of wildcard certificates for google.com, facebook.com, etc. right now and keep those in case they want to use them for spying?
* The certificates that they already issued would keep working, right? Their customers would just need to find another CA when they need to renew their certificates? I'm pretty sure that that's correct, because they're not talking about having browsers remove a CA from the trusted list. (They couldn't really. The one on the trusted list is Cybertrust, not Etisalat.)
* In that case, how do they even revoke the certificate? If they keep a copy of the certificate, wouldn't it still be able to generate valid certificates? Or is it somehow setup such that Cybertrust can easily revoke the certificate? I can't really think of a great way to do that given how I think the certificates work in general. I guess it could require a temporary key, say for the month. But I don't see how that would stop them from signing things with the temporary key that they have for August and just saying that the date it was issued is sometime in August 2010.
* Even if I'm wrong about that, if I'm right that certificates that they've issued would keep working, couldn't they generate a bunch of wildcard certificates for google.com, facebook.com, etc. right now and keep those in case they want to use them for spying?
There are protocols (like OCSP) for doing online/realtime revokation, so that Verizon can announce that the Comtrust cert is invalid. They're kind of a mess, and they're often off by default.
Mozilla should just shitcan the GTE root cert (Apple probably won't, because of the iPhone relationship, but Mozilla would be enough).
Mozilla should just shitcan the GTE root cert (Apple probably won't, because of the iPhone relationship, but Mozilla would be enough).
I believe to revoke a certificate Verizon/CyberTrust would have to issue a revocation cert and then send that to the browser vendors. The browsers would be patched with the new revocation cert, and would reject any certificate chain that included the (now revoked) Etilsalat cert. Even if Etilsalat generates wildcard certs right now, they will be signed using Etilsalat as the issuer, and so will contain the revoked cert in the certificate chain.
Interesting. I'm going to be traveling to the UAE soon. If I assume that Etilsalat has in fact issued itself HTTPS certs for secure sites that I visit, and is doing some sort of MITM attack, is there any way for me to detect and/or prevent it?
Yes, mostly; you can always click the "lock" icon in your browser. You shouldn't see an Etisalat/Comtrust certificate anywhere for the sites you normally use. This is probably not bulletproof, but, probably, neither are Etisalat's snooping tools.
Not to go all cypherpunk, but you can pretty easily create an encrypted SOCKS proxy tunnel using an OpenSSH client. So if you have an SSH server in a country you trust, you can tunnel your browser traffic through there for connections you are nervous about.
first link from google:
http://embraceubuntu.com/2006/12/08/ssh-tunnel-socks-proxy-f...
EDIT: clarity
first link from google:
http://embraceubuntu.com/2006/12/08/ssh-tunnel-socks-proxy-f...
EDIT: clarity
I'm glad EFF is starting this project, because I read one of the paragraphs in the article slightly differently, see:
[any authority] could use [their] key to issue itself valid HTTPS certificates for verizon.com, eff.org, google.com, microsoft.com, or indeed any other website. [any authority] could use those certificates to conduct virtually undetectable surveillance and attacks against those sites. [any authoritiy's] keys could also possibly be used to obtain access to some corporate VPNs.
[EDIT] Are there any monitoring tools I can install to question the validity or motive of a certificate? It sounds absolutely silly even saying it, since I can't even keep up with other web browsing security measures: white-listing off-domain cookies my banks insist on issuing, deleting flash cookies, running no-script, etc...
[any authority] could use [their] key to issue itself valid HTTPS certificates for verizon.com, eff.org, google.com, microsoft.com, or indeed any other website. [any authority] could use those certificates to conduct virtually undetectable surveillance and attacks against those sites. [any authoritiy's] keys could also possibly be used to obtain access to some corporate VPNs.
[EDIT] Are there any monitoring tools I can install to question the validity or motive of a certificate? It sounds absolutely silly even saying it, since I can't even keep up with other web browsing security measures: white-listing off-domain cookies my banks insist on issuing, deleting flash cookies, running no-script, etc...
There's a Firefox plugin called Certificate Patrol that remembers the certificate for a site and tells you if there's a suspicious change on a subsequent visit (eg certificate being replaced long before the old one expired).
Did GTE CyberTrust issue certificates for money? If its customers' secure web sites stop working because browsers revoke the GTE CyberTrust certificate, can those customers sue Verizon for malfeasance?
Long story short: Verizon bought GTE CyberTrust. GTE CyberTrust signed a CA=TRUE for Etisalat, the UAE's biggest telco. Even if you didn't know the rest, you wouldn't be happy, but: Etisalat has already MITM'd and backdoored a zillion Blackberries. Now they can turn off your encryption, too.
You can't easily disable Etisalat's "Comtrust" certificate (you can see it for yourself; go to http://j.mp/a11K0t and click the lock icon in your browser; note that the GTE CyberTrust root is also an MD5 cert --- classy), but you can disable the root CyberTrust cert easily:
* For OS X Safari, pull up Keychain Access, click "Certificates", search for "Cybertrust", and baleet.
* For Firefox, go to Security -> Certificates, browse to CyberTrust, and click delete.
This will probably break a bunch of other random sites validation. Oh well.
The really disturbing thing about this, and the part that's unique to the EFF/iSEC SSL observatory ("you know it's great research when I talk up my competitors"), is the prevalence of CA=TRUE certificates signed by root CAs. There's no easy way to find out how many of these exist! It's the closest thing there is to a fundamental flaw in the SSL/TLS certificate model.