EFF Asks Verizon Whether Etisalat Deserves CA Trust 135
Peter Eckersley writes "Today EFF published an open letter to Verizon, calling for investigation of a trusted SSL Certificate Authority. Etisalat is a majority state-owned telecom of the United Arab Emirates with operations throughout the Middle East. You may remember that last year Etisalat installed malware on its subscribers' BlackBerry phones, and was recently pivotal in the UAE's threat to disconnect BlackBerry devices altogether if Research In Motion did not provide a backdoor for BES servers' crypto. This company, which appears to be institutionally hostile to the existence and use of secure cryptosystems, is in possession of a master certificate for HTTPS, encrypted POP and IMAP, and other SSL-based security systems. Etisalat's CA certificate is not trusted directly by Mozilla and Microsoft, but was instead delegated as an Intermediate CA by Verizon. As a result, we are asking Verizon to investigate whether it is appropriate for Etisalat to continue holding this certificate, and to consider revoking it."
Re:I'm confused... (Score:5, Informative)
It's not a question of whether Verizon should identify who Etisalat is. The question is this: should Etisalat be allowed to verify who other people are?
The risk here is that Etisalat could, for example, generate an SSL certificate for www.google.com, or www.amazon.com, and then put up a site pretending to be Amazon or Google, and your web browser would show all of the nice pretty icons and colors indicating that the site was legitimate and had a proper SSL certificate.
This is because Verizon has identified Etisalat as an intermediary CA, which allows Etisalat to generate SSL certificates for other domains that your browser will then trust.
Re:I'm confused... (Score:1, Informative)
The problem isn't that Etisalat isn't who they claim to be. The problem is that their CA certificate was delegated as an intermediate CA by Verisign.
With an intermediate CA, they could issue certificates to anyone they want to, for any domain. This would allow them to snoop on (and interfere with) any SSL communications between absolutely anyway.
Neither Microsoft, nor Mozilla "trust" Eltisalat. They don't have Eltisalat's CA certificate installed. They. All major browsers include Verisign's root CA certificates. Since Verisign trusts Eltisalat, that means any software that trusts Verisign also trusts Eltisalat.
Eltisalat is basically owned by the government of the United Arab Emirates. This same government have, as the article (and summary) mentions, tried to snoop on users of Blackberries before, and have threatened RIM to have a back-door installed. Should these people be trusted with the ability to issue any SSL certificates, for any domain they want to?
Re:I'm confused... (Score:4, Informative)
The problem is that Etisalat has a signing certificate which, in turn, is signed by Verizon. Evil, Inc. can get a certificate for a domain, say yourbank.com, and get Etisalat to sign it. When your browser goes to https://yourbank.com/ [yourbank.com] the owner of this certificate can do a man-in-the-middle attack and substitute their certificate for yours. Your browser will look at the certificate and see that it's signed by Etisalat. It will then fetch Etisalat's signing certificate and see that it's signed by Verizon. It trusts Verizon, so it will show you a happy 'this page is secure' icon. You happily give your online banking credentials to a random person, they take your money, and your bank says it's your fault because you provided the criminals with your online banking details.
It's not up to Etisalat to police the Internet, but it is up to them to police the certificates that they sign. Signing Etisalat's signing certificate means that they are saying publicly that they are willing to stake their reputation on the fact that any certificate signed by Etisalat can be trusted. The EFF is calling them out on this.
Manual removal is a pain (Score:2, Informative)
In a "perfect" world this should work:
Step 1: Remove Verizon's cert from your web browser.
Step 2: When prompted to trust ABC's untrusted certificate, open it in a different web browser that still trusts Verizon.
Step 3: If it is trusted, make a decision on your own if you trust it or not.
Step 4: If you do, add it.
Repeat steps 2-4 as needed.
I say this not having tried it. It may or may not work in the real world.
Even if it does work, it's a pain.
Re:I'm confused... (Score:5, Informative)
The problem isn't that Etisalat isn't who they claim to be. The problem is that their CA certificate was delegated as an intermediate CA by Verisign.
With an intermediate CA, they could issue certificates to anyone they want to, for any domain. This would allow them to snoop on (and interfere with) any SSL communications between absolutely anyway.
Neither Microsoft, nor Mozilla "trust" Eltisalat. They don't have Eltisalat's CA certificate installed. They. All major browsers include Verisign's root CA certificates. Since Verisign trusts Eltisalat, that means any software that trusts Verisign also trusts Eltisalat.
Eltisalat is basically owned by the government of the United Arab Emirates. This same government have, as the article (and summary) mentions, tried to snoop on users of Blackberries before, and have threatened RIM to have a back-door installed. Should these people be trusted with the ability to issue any SSL certificates, for any domain they want to?
The article references Verizon, not Verisign. Not trying to be pedantic here - just figured it was a worthwhile correction.
Re:Removal - Mozilla CA certificates (Score:5, Informative)
My browser "complains" about non-SSL (Score:3, Informative)
Of course, the complaint is subtle - it comes in the form of a missing lock icon or a lock icon that's flagged to indicate a mix of encrypted and non-encrypted content.
The problem with corrupt signing authorities is that I can be sitting in the UAE and their telco could be doing a MIM attack and I see the lock icon and think my connection is secure end-to-end when it's not.
Re:The system is broken (Score:2, Informative)
* selectively prune the trust hierarchy
- Not practical without creating an artificial scarcity problem. You want enough trusters to meet market demand and prevent artificially high pricing.
* flag certificates that change (there are addons)
- Very good idea.
* specify the maximum path length you are willing to trust
- I'm not sure this is explicitly needed with trust weight assignments. You can assign a weight of "x-1" for each level you drop, and give 1st- and any-other-level certs whatever weight you want - "2" for signers you trust to delegate but don't trust their assignees to delegate, "infinity" for authorities you trust won't ever make a mistake and whose delegates and sub-delegates etc. you trust never to make a mistake, and in between for most others.
* Be able to assign a trust weight to a CA
- This is essential. This should be doable by both individuals, independent "reputation authorities" that individuals tell their browsers to query, and for the 99% of people who will default to doing nothing, a reputation authority picked by the browser vendor.
Self-signed certificates and trust (Score:3, Informative)
A self-signed certificate isn't as trustworthy as you think. In particular, it's vulnerable to a man-in-the-middle attack on any computer for which it has not been previously installed.
Scenario:
AcmeHardware.com is getting some local buzz for its new online store. They use self-signed keys but most of their customers don't do any manual checking to authenticate the key.
I'm a rogue operator for localisp and I know it will be featured in the paper tomorrow along with its web site and I know the newspaper will be kind enough to tell readers not to worry about the self-signed key.
I hijack the DNS for my clients and set up a man-in-the-middle attack. I present a fake key and sniff out personal information.
Now substitute "many web sites" for this store and "foreign government" for rogue employee of an ISP and you can see why this is an issue for the EFF. The difference is with self-signed keys there is no central place to solve the problem, as any employer, ISP, DNS provider, etc. can do the sniffing.
Oh, just for the paranoid - if I as a rogue ISP encouraged my customers to install my own signing-key in their key-list, then I could do this to any business not just those using unsigned keys. However, that is harder to do and harder to get away with over the long haul. It might work for spear-fishing attacks though.
In the next few years, authenticated DNS should make such attacks against either signed or unsigned certificates technically much harder, they will require either getting around the DNS authentication or faking out IPv4 or IPv6 addresses.
Re:Proves that certs are useless in the real world (Score:3, Informative)
Certificates implemented sensiblly work just as they were designed.
The trouble is the CA model only works when the CAs are trustworthy. For some reason browsers are allowing ever growing lists of CAs of various degrees of trustworthyness and the system as implemented in web browsers is only as secure as the least trustworthy CA in the list. Intermediate signing certificates are a good idea in theory but open up a huge can of worms of thier own by allowing CAs to add other CAs to the list without those other CAs having to prove themselves to the browser vendors.
Re:I'm confused... (Score:3, Informative)
Verizon Business. Actually the root certificate signing them is "GTE CyberTrust"
/CN=GTE CyberTrust Global Root, OU = "GTE CyberTrust Solutions, Inc.", O = GTE Corporation, C=US/
For the benefit of anyone who would like to see full details, I have pastebin'd the entire certificate chain of a HTTPS session Etisalat cert chain [pastebin.com]
Based on the certificate presented by https://www.eim.ae/ [www.eim.ae]:
*.eim.ae
Comtrust Server Certification Authority
Comtrust Root Certification Authority
Re:My browser "complains" about non-SSL (Score:3, Informative)
I agree with you that maybe a site should pop up a warning before sending info. However, a site with no SSL is just as vulnerable as a site with a self signed key. (This is in contrast to a key that is invalid where it might be hanky-panky in play as opposed to just a SS cert.)
Another use for a SS cert is to ward off two basic types of attack: The guy sniffing a WAP, who likely won't be able to actively intercept the connection. And the Phorm ad-generators whose job it is to insert ads into ongoing streams of traffic. Because those handle so much traffic, it would take a large machine to do the calculations to commit to creating and tearing down SSL tunnels to MITM traffic to sites.
So, even though it doesn't give a solid chain of trust, self signed certs do provide a form of security.
Re:Proves that certs are useless in the real world (Score:4, Informative)
Get with the program, man, that was released on Friday [ietf.org].
I kid - the only way I found it was to search on the gp's suggestion, find an article on wikipedia about a different record type, linked to a wikipedia page on dns record types, found an SSH type (SSHFP) that was sort of like what you suggested, and then from there reasoned that the right type should be called 'TLSFP', and voila, Google RFC out on Friday. Freakin' intarwebs.
They thought of a few features I missed in the few minutes between clicks above, it looks pretty sold.
It's good they're fixing the TLS MITM problem.