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."
Well duh (Score:4, Interesting)
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?
Re:I'm confused... (Score:5, Interesting)
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?
Blocked (Score:1, Interesting)
The NY Times story is being blocked by their proxy servers. Trying to keep costumers in the dark as usual.
Man in the Middle Worries and Avoidance? (Score:3, Interesting)
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.
Re:Man in the Middle Worries and Avoidance? (Score:5, Interesting)
"Authenticated by..." lock needs improvement (Score:5, Interesting)
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/ [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."
Need levels of certification (Score:2, Interesting)
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.
Being serious for a moment... (Score:2, Interesting)
In another scenario, someone is using a shared certificate issued by a "trusted" supplier, but owing to the domain structure it could be cloned and used in a MiM attack. My browser doesn't care.
My conclusion from all this is that, in fact, even the browser vendors have it backwards. They want us to trust, more or less blindly, anything corporate. They want us to distrust anything that is not corporate. In effect, they want us to buy the message "I'm a banker, trust me", rather than "read this contract carefully before signing". In the scheme of things, being issued by a "trusted" CA should rank _below_ being exactly site-specific, not above. That it does not do so seems more for the convenience of corporates than for Internet security in general.
Now someone please explain why I'm wrong.
Re:Revoke time (Score:4, Interesting)
From the article:
"We are writing to request that Verizon investigate the security and privacy implications of the SSL CA certificate (serial number 0x40003f1) that Cybertrust (now a division of Verizon) issued to Etisalat on the 19th of December, 2005, and evaluate whether this certificate should be revoked."
FWIW, CNNIC (state network information center of China) has it's cert signed by Entrust. So if you don't trust CNNIC, you shouldn't trust Entrust either
You can use the Certificate Patrol plugin to help keep track of CA/cert changes in sites you visit. After all if your bank website's cert was signed by Comodo today, but CNNIC when you go to China, I'd think you'd want a warning. Current browsers by default would NOT give you a warning in this scenario as long as the website's certificate chain is ultimately signed by one of the CA certs installed in your browser.
So go figure how much the browser bunch really care about your security.
Re:Revoke time (Score:5, Interesting)
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.
Re:My browser "complains" about non-SSL (Score:3, Interesting)
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
A big problem with this is the page by page model of the web.
Consider I make a page which is only served over https, said page contains links and form submissions to other pages on the site. Those pages may or may not be on the same hostname as the current page.
Consider a man in the middle that only intercepts some proportion of web requests or in the case of multiple hostnames only intercepts some proportion of them. With your "just don't display the padlock" option by the time I'm warned that I don't have a secure connection it's too late. By the time I see a page without a padlock on whatever data was in the request I just made has been submitted to the man in the middle.
A site that is not encrypted at all can't process a request for a https url so this problem doesn't apply there.
Re:Proves that certs are useless in the real world (Score:5, Interesting)
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.
Re:My browser "complains" about non-SSL (Score:4, Interesting)
Specifically, a self-signed cert should show a YELLOW url bar and a locked padlock, meaning the connection is well secured by encryption but the identity of the other party is in question.