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."
Again, well duh. Is there really any question that they can't be trusted with granting certs when they are so openly hostile to encryption of any kind?
Tequila: It's not just for breakfast anymore!
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?
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/ 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.
I am TheRaven on Soylent News
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.'"
A dodgy trusted SSL authority could trivialise man in the middle attacks (especially with state backing). Can any SSL client apps (Thunderbird/Evolution/Firefox etc) be told to remember an SSL cert for a site and be told to report if it changes? Like how SSH does with it's keys.
It obviously will change when it expires but at least you could examine it ( a really smart client could tell you that just the dates have changed).
Then if a valid new cert was put in place between yourself and the actual site you'd see the change.
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.
Even if we can't get an "open" system, at least industry - pushed by web browser vendors - can get standards in place.
"Certificate good for authenticating web pages but not signing other certificates":
- very high proof of identity for banks and other "high stakes" places
- high proof of identity for e-commerce and other sites that deal with sensitive information
- medium proof of identity for most other web sites that want to be taken seriously
- "Liar's signed certificate" for individuals and others where identity isn't important, only knowing that the identity is the same as it was yesterday is.
- "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.
"Certificate good for signing other certificates":
- same requirements as above, with a pledge, backed by something you don't want to lose, that you will not falsely label the "trust level" of any certificate you sign, AND that you will not assign a trust level lower than your trust level at the time of signing. Should you make a mistake, you will revoke the erroneously-signed certificate immediately.
So, if I wanted to be a "very high trust" signer I better be very careful to label everything I sign with an appropriate reputation. If I wanted a "Liar's signer certificate" for playing around with, I could get one, but all I could do with it would be to sign "Liar's certificates."
There would also need to be a "reputation revocation list" - one that didn't revoke a certificate but downgraded the reputation of it. This way if a signing authority "went rogue" it could be downgraded to "liar" status. Web browsers would display a "lock" icon corresponding to the lowest reputation of any signer in the chain, meaning if a signing authority "went rogue" all of its previously-signed certificates would be downgraded in one fell swoop.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
Looking blearily through pre-coffee eyes at my computer screen, I briefly thought I had awoken ten years in the future.
"Today EFF published an open letter to Verizon, calling for investigation...
HOLY CRAP! I must have been asleep for years! The whole Google/Verizon/FCC thing must have tipped us over. We must have slid into open fascism while I was asleep, if even the EFF has stopped suggesting that the government perform investigations and has started bowing and scraping before Verizon.
You maniacs! You blew it up! Damn you. God damn you all to hell!...
Stop-Prism.org: Opt Out of Surveillance
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.
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Certificates work just fine in the "real world;" it is the CA system that is the broken.
Palm trees and 8
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.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
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.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
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
Based on the certificate presented by https://www.eim.ae/:
*.eim.ae
Comtrust Server Certification Authority
Comtrust Root Certification Authority
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.
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?
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?
The neat thing would be if HTTP could just transparently upgrade to SSL without displaying the secure connection icon.
Finally! A year of moderation! Ready for 2019?
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.
If corporations are people, aren't stockholders guilty of slavery?
Get with the program, man, that was released on Friday.
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.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)