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.
The problem is the Etisalat is not trustworthy -- they may sign certificates for MITM attacks, for example. Personally, I think the CA system is broken, and would not trust any of the widely known CAs; any one of them might be signing fake certificates for a certain major world government. If Hushmail is willing to compromise its users' security, then why wouldn't a CA be willing to do the same?
Palm trees and 8
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
- "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 following changes could be useful:
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.
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?
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.
If corporations are people, aren't stockholders guilty of slavery?
Erm, in what universe would Verizon find it slightly hard to make a fake cert?
If corporations are people, aren't stockholders guilty of slavery?