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."
Revoke time (Score:4, Insightful)
Re:I'm confused... (Score:4, Insightful)
Re:Letter to Verizon...? (Score:4, Insightful)
You are totally wrong about the issue of root authorities, the very point is that the users CAN trust them, if they are not trustworthy, they should have their certificate revoked and they should not be trusted by anyone's browser by default. The cert was issued for the purpose of issuing trustworthy certs and if they're using it for other purposes, REVOKE THAT MOTHERFUCKER. Otherwise "trust" is just a word.
Re:Need levels of certification (Score:5, Insightful)
- "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 system is broken (Score:5, Insightful)
The following changes could be useful:
Re:Proves that certs are useless in the real world (Score:3, Insightful)
Re:My browser "complains" about non-SSL (Score:4, Insightful)
Most browsers do not complain "subtly" when you use a self-signed certificate. They complain rather loudly.
I was just saying that the browser should simply not display the padlock at all. They shouldn't treat the connection as less secure than non-SSL, because it isn't less secure than SSL.
Obviously I agree that corrupt CAs is a big problem. I'd consider revoking them all except that there don't appear to be any extensions for chrome that allow for an alternative trust model/etc. Also, the people in my family most likely to leak sensitive info aren't going to be able to handle something like that anyway.
Re:Well duh (Score:2, Insightful)
If you think Etisalat is untrustworthy... keep in mind you too can have your very own privately branded CA through GeoTrust [geotrust.com], Global Trust's Root Signing service, or QuoVadis / RSA's Root Signing Service.
You just have to meet their minimum financial net-worth and insurance requirements, policy requirements, and "compliance" guidelines.
The limiting factor is the cost of these services. If you are willing to pay enough, you can have your own CA.
The fact of the matter is, trust is not part of the equation.
X.509 CA / SSL Certificate cryptography practices are very broken.
Re:My browser "complains" about non-SSL (Score:3, Insightful)
I see what you're getting at, but there have to be better solutions.
The current model discourages SSL adoption, because it adds a significant cost ($70/CN/yr or so). For an e-commerce site it isn't a big deal, but for myblog.com, it is.
I think the real problem is trust management. I don't trust Verisign, so how do I talk to my bank? The fact that everybody else trusts Verisign means that nobody treats this like an unsolved problem...
Re:Proves that certs are useless in the real world (Score:3, Insightful)
The problem with the implementation of certificates is that they inevitably lead to this state of affairs. They unwisely separate the consequences from the decision. Some CA I've never heard of makes the decision of who to trust, but they're not the ones who suffer if the trust is violated.
Meanwhile, the "web of trust" isn't very hard to understand and could have been implemented easily. It's based on a few simple questions. "Do you believe that this key belongs to that entity?" "Do you trust that entity to introduce new entities to you?" (a few paragraphs on trust of sincerity vs. trust of judgment) and finally, if entity trusts someone to introduce new entities, do you also trust them?
But that couldn't be because there's no money in it for anyone. Of course, a reason like that won't fly, so instead the excuse is that big companies are much better at verifying these things and too many individuals aren't equipped to make good decisions. (How very patronizing). However, we can see that apparently Verizon CAN NOT be trusted to make good decisions about trust (I'm shocked, I tell you!).
Interestingly, if the software was coded to use the web of trust model, it COULD default to the current system of CAs unless the user wanted to override a few things like trusting Etisalat at all or trusting Verizon to introduce trust. Alas, the opposite isn't true.
Re:Need levels of certification (Score:3, Insightful)
I'd disagree about self signed certificates. Yes, they can be MITM-ed, but they do provide some form of security to keep the traffic encrypted. At the minimum, it keeps Phorm-like ad-spewers out.
I would like to see Web browsers not go ape over a self-signed cert (as opposed to certs that don't match). Instead mark the connection as insecure, but with some basic anti-snooping provision, so people understand the connection isn't secure completely, but Joe Script Kiddie with his wireless packet sniffer can't snag someone's password to a website that uses self-signed certs.
This way, average users don't see a lock icon and assume the connection is secure, but more knowledgeable users know that SSL is in use, even though MITM attacks are doable.
Re:Proves that certs are useless in the real world (Score:5, Insightful)
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.)
Re:It confuses technical and social requirements (Score:4, Insightful)
It doesn't involve educating users, it just involves not putting giant-ass popup warnings in their face and panicking them.
I've constantly said that user-signed SSL connections shouldn't get a lock at all. That's it. Pretend they are unencrypted to the end user. If browsers want to be clever, they can invent some other signal like a a doorknob or something.
Then web servers can just transparently use them.
Of course, there's no way this will happen now. But it's what should have happened. The idea of having DANGER WILL ROBINSON DANGER alerts on connections on that are more secure than normal HTTP was idiotic, but probably unfixable, unless we invent some new protocol.
I suggest some sort of STARTSSL-like concept, where either the browser can say 'This request is encrypted' or the server can say 'Here is an encrypted reply'. (Neither of which require the other.) Hopefully even over a keep-alive connection, switching back and forth as needed, although that might have security implications. Part of HTTP 2.0 or something.
I'm not sure how you'd identify requests you want the browser to send encrypted to the server...perhaps the browser should just send all POSTs encrypted by default and with links, you could use a rel='encrypted' attribute. Or perhaps POSTs should have a 'turn on' or, better, a 'turn off', encryption attribute.
The server, of course, should just encrypt whatever the hell it wants, after the browser sends an 'Accept-Encryption' attribute, or perhaps that should be part of Accept-Encoding.
And, of course, as I said elsewhere, you stick the fingerprint of this cert in a DNSSEC-secured DNS TXT record.
Re:I'm confused... (Score:4, Insightful)
Erm, in what universe would Verizon find it slightly hard to make a fake cert?
Re:It confuses technical and social requirements (Score:3, Insightful)
The neat thing would be if HTTP could just transparently upgrade to SSL without displaying the secure connection icon.
Re:Revoke time (Score:5, Insightful)
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.
Re:It confuses technical and social requirements (Score:3, Insightful)
Self-signed connections are not more secure than HTTP unless you have independently verified the certificate.
Yes they are.
Spying on those connections vs. HTTP connections, requires more work, and hence are objectively 'more secure' by any measure of 'secure'. You have to MitM them to spy on them, whereas you don't for normal HTTP connections.
Also, you have to MitM in real time, where it can be detected. (And should be, as browsers should warn when certs change.) Whereas simply recording traffic is utterly undetectable.
What you're asserting is that they're not perfectly secure. Which, really, no general purpose computer ever is. Unsigned certs are certainly more secure than unencrypted.
What's more, if browsers treated self-signed certificates the same way it treated HTTP connections, 90% of users would never realize something was wrong. Until about 2 generations ago, most browsers popped up simple dialog boxes that users clicked through on autopilot before sending sensitive information to phishers. If they ignored dialog boxes, there's no way that simply not showing the lock is going to bring a problem to the user's attention.
Then SSL encryption is already totally, utterly broken. If you can do a MitM attack, and users 'don't care about the lock icon', all you do is make sure that no links go to the SSL portion of the site. Just edit the stream in real time to change https to http, and optionally have some sort of simply logic to remember what URLs you did that do, so your proxy can retrieve SSL pages for those URLs. (As some web sites will complain if you access some parts not via https.)
Yes, maybe 2% of the users have bookmarked the SSL site to start with, or type in https: to get there, but if 'they don't care about the lock icon', that seems unlikely for them to have done.