

EFF to Verizon: Etisalat Certificate Authority Threatens Web Security - gojomo
https://www.eff.org/deeplinks/2010/08/open-letter-verizon

======
tptacek
Way to go, EFF!

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.

~~~
caf
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".

~~~
sqrt17
... 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).

~~~
caf
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_.

------
jackowayed
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?

~~~
tptacek
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).

------
staktrace
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?

~~~
tptacek
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.

------
euroclydon
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...

~~~
caf
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).

------
kragen
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?

