Slashdot Mirror
EFF Asks Verizon Whether Etisalat Deserves CA Trust
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."
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.
Browsers need to clearly show WHO is authenticating and some measure of "reputation" of each authenticator in the chain.
Let's use https://www.google.com/ as an example.
Its certificate is issued by "Thawte SGC CA" which in turn is issued by "Verizon, Inc."
If the "reputation" of Thawte and Verizon were both high, then the lock-symbol in my browser would be green. If either one were "medium" then it would be "orange." If either one had a bad "reputation" then it would be red. Of course if any link in the chain were revoked then there should be no lock-symbol at all and possibly some big nasty warning messages to boot.
Browsers also need to allow users to remember signatures alert users if they change, to identify poisoning attacks where FakeBank gets a valid, seemingly-reputable certificate for yourbank.com due to a clerical error or fraud AND uses it along with DNS poisoning or other means to fool your bank into visiting FakeBank.IP.Address and getting a "valid" certificate when it wants to go to yourbank.com.
Whether it's the browser vendor that determines who the reputation vendor is or whether it's the user will largely be a market decision, at least in most countries. In some countries of course the government will try to control reputation, labeling any certificate authority that doesn't follow its rules as "untrusted."
In the case of Etisalat, reputation vendors in the West may mark Verizon as "green" and Etisalat as "orange" or even "red." The UAE may try to force people in its country to use a reputation authority that marks Etisalat as "green" and COMODO CA Limited, the authority the EFF uses, as "red" in retaliation for bringing this up in the first place. Memo to the UAE if they try this: "Good luck with that."
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
The Verizon certificates are included in Mozilla under GTE Cybertrust. In Debian, dpkg-reconfigure ca-certificates, select ask, and select the certificates you don't trust.
If you use firefox: Edit > Preferences > Advanced > Encryption > View Certificates > Authorities
Personally, I've deleted all of the authorities and only add certificates as I need them.
This is because a CA can be compelled by the country they are in to sign a certificate for any domain.
For example: If your browser trusts the Etisalat CA then Etisalat can can create a SSL certificate for Google.com even though Google.com didn't ask for one.
If your DNS then points to a Etisalat server it can serve pages as Google.com (pretty green "I'm secure" bar and all).
You'd have to view the cert info to make sure Google's real CA signed the current cert...
Thawte, Verisign and Verison can be compelled by the US to create fake certs too, but in this case only the IP address would tip you off.
If my browser was sent a fake cert and fake DNS results I will be presented with an "Untrusted Certificate" screen.
Since this normally only happens when Google's cert is about to expire I would be alerted.
tl;dr: CA system is broke because any CA can make a cert for your domain without your consent.
In part, this problem might be solved by DNSSEC.
Unfortunately not, because the decision makers of internet security protocols are all greedy pigs who want to charge you money for a service that you can do yourself for free.
From day 1, the HTTPS CA and DNS CA systems should have been one and the same.
That is, not tying the two systems together is a gaping security hole that means that even if you control a domain, someone else can issue certificates for that domain and the users can't tell.
DNS should have had a CA hierarchy built into it from the beginning, so that if you own 'google.com', you can issue a cert for it for free as easily as creating a record, and if anyone else tries to do the same, they won't get very far because they can't create a cert signed by *your* DNS domain key.
There's so much more money to be made however by taking the CA control out of the hands of the DNS domain admins and putting it in the hands of some corporation.