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."
Time to revoke Verizon certificates on my computers.
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.
If I understand correctly, in this case, Verizon is delegating authority to Etisalat to grant certificates through a subCA. That means that if you trust Verizon, you trust Etisalat.
As an intermediate CA hostile to privacy, they can produce certs which browsers trust without prompting. This means that they can trivially evesdrop on all communications.
Is it possible for me to reject the Etisalat subCA cert without ever seeing it?
Can I trust Verizon anymore, knowing that they grant such certs?
https://blog.torproject.org/blog/life-without-ca
Palm trees and 8
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.
- "self-signed" certificates, which we already have and which aren't worth much more than the bits that carry them unless you have some independent way to trust them.
I'll disagree with this. They're worth at least as much as the bits used to transport non-SSL traffic, which is about 90% of the traffic on the internet.
For some reason we have a model which treats encrypted and non-authenticated traffic as being less secure than unencrypted and non-authenticated traffic. This is completely backwards.
Sure, browsers shouldn't treat these the same as trusted SSL connections, but they shouldn't generate warnings for it that they wouldn't generate for non-SSL traffic. Worried about MITM? Well, if I wanted to MITM your connection I'd just open a non-SSL connection to your browser and an SSL connection to the bank, and your browser wouldn't complain one bit.
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.
The following changes could be useful:
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.
Most (all?) browsers are broken too.
If say you go to https://www.yourbank.com/ at home and the cert is signed by Thawte.
Then one day you go to UAE and visit https://www.yourbank.com/ and the cert is signed by Etisalat whose cert is signed by Cybertrust whose cert is installed in your browser.
By default your browser won't warn you at all!
In fact for this scenario you would be safer if you actually deleted all the CA certs, and accepted certs on a site by site basis, because you would then get a warning since the cert has changed.
Currently I'm using the Certificate Patrol plugin and I hope it works properly and doesn't automatically "bless" some CAs as trustworthy, since as far as I'm concerned it's better to assume that they all aren't.
Exactly.
Even in a WoT model, most people would not really use it. They'd use the hundred or so big list that came with the browser, consisting of major banks and whatnot. And the first time they went to amazon, the browser would popup a message and say 'According to 100,000 other users, this cert is legitimate. Trust Yes/No?' and they'd say yes.
The current system is so entirely broken it's a good thing we don't actually need need certs in the first place...99.999% of the time, we just need damn encryption. MitM is such an order of magnitude more complicated than sniffing it's crazy we've decided to care about it that much.
Now that we have DNSSEC actually up and running, I wish we'd invent some sort of 'Here is my SSL cert fingerprint' DNS record. Then people could just make their own cert (Which should be easier and not require them to also make a CA.) and stick the fingerprint in their DNS. (This would work without DNSSEC also, but with DNSSEC it's secure.)
If corporations are people, aren't stockholders guilty of slavery?