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.
I'm totally confused by this request from the EFF. Authorities exist to assure identity, a root authorities job is to assure identities of the people it hands out certificates to, is the EFF suggesting that Etisalat isn't who they claim to be? It isn't up to Verizon to police the internet, it is up to Verizon to check that Etisalat is who they claim to be, and then grant them a certificate, or in this case grant them the ability to generate their own child certificates. If people distrust Etisalat generated key sets then take your business to a root authority which you do trust. You also have the option of revoking their certificates on your machine or in your browser. A better person to send this letter to would be for example MIcrosoft, Red Hat, Mozilla, and anyone else trusting Etisalat RA.
It would be awesome if the names or identifying-info was given about these dodgy SSL Cert CAs so we can go and remove them manually, hard to do when there is so little information.
Just state the criteria. (I considered putting funds into ethical stock once, but the restrictions seemed dumb, both in terms of what they considered ethical (not in my opinion) and vice versa. In the end I chose them myself.)
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.'"
The NY Times story is being blocked by their proxy servers. Trying to keep costumers in the dark as usual.
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.
Can someone please post how to un-trust Verizon in Firefox and IE? I don't want anything they claim certified because of this. Also, is there a way to get Mozilla to un-trust Verizon on their master list so we all don't have to tweak our software?
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.
Oh, not even that — it becomes a marketing term. At least words have meaning.
You cannot truly appreciate Dilbert until you read it in the original Klingon.
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:
I just hafta ask, as a complete tangent: were you really raised on pills? GlaxoSmithKline must be so proud.
Maybe that is best word. CA only certify WHO somebody is. They do not certify what they are doing is correct.
By the way, you can alrady look at the certificate and see the chain of trust.
Looking for details the first secure link of https://www.e4me.ae/e4me/etisalat/newregistration?SID=1&&language=en etisat does not use their own CA. funny?
Revoke that certificate manully? once a certificate is revoked you no longer can look at it due to the interface works. Not really a bug, untill you encounter it.
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.
By the way, you can alrady look at the certificate and see the chain of trust.
Yes, I know. The browser needs to be able to interpret this and display an "layman-use" symbol that indicates trust.
Most browser's current "layman-use trust symbols" are either "signed," "not signed," "partially signed," "signature revoked," or similar. There is no
actual
indication of the trustworthiness of the signature, even though the industry trains people to "look for the lock" and equate that lock with trustworthiness.
Whether this is a user-education issue, where the industry has been telling people the lock means "trust me, I'm who I say I am" when it only means "a chain of possibly untrustworthy people will attest that this web site is who it says it is," or a technical problem depends on how you look at it. Either solution - re-educating the public or fixing the technology so the public sees what it expects - will work.
Of course, the first solution will drive the banks and e-commerce web sites nuts and therefore won't happen - if people KNOW can't trust the lock, they'll stop doing commerce online.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
I have had a hard time explaining to people why self-signed certificates are much more secure than "trusted" certificates issues by likes of Verisign, Thawte, etc.
They still don't understand it :)
Certificates work just fine in the "real world;" it is the CA system that is the broken.
Palm trees and 8
I work at Verizon, and I use Firefox a lot.
I noticed that FF doesn't trust a lot of the certificates, either they've expired or they aren't from a trusted authority. Doesn't bother me when Im trying to log into a tool that isn't accessible to the outside world? But trying to log into your timesheet to get paid makes me nervous.
As for any "investigations"?
Eeeehhh...no comment. I may be posting ac, but I'm not stupid, either.
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.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
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.
Just print out the key, check with HR to make sure it's right, and check it each time.
OK, it shouldn't be that hard :).
Seriously, check with HR to make sure the key is legit, then install it and forget about it.
Very seriously, any business the size of Verizon should have a key or keys for its internal web sites that's trusted by its employees' computers.
--
I tried to email this to you but anonymouscoward@verizon.com bounced.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
In the old days, before electronic phones, you could buy a "tap indicator" and know that your phone connection to your local bank was secure against all but the most determined adversary besides the phone company.
Even without such a tap-indicator, you knew that there were a limited number of points where someone other than the phone company could tap without attracting attention - basically, your home or neighborhood to the point where the cables went underground, or the bank and points between it and when the phone cable went underground.
Even before IP-telephony, it took someone with expensive equipment or with the knowledge to break into the telephone switch to tap your conversation without the telco's knowledge.
Now I don't trust my phone any more than I trust my web browser.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Looks like it is time for pre-paid "trust" escrow accounts that are 20% of the company networth if they default on the "trust" part of the deal. Basically, no government would qualify.
Since when did "Trust" mean "To deceive, discriminate against, or commit hostile action towards"? WTF. Revoke that cert! Seriously?!?!?!? Why in the fuck wasn't it already revoked?
Foreign or domestic, any misguided user/organization abusing their privilege, should have that privilege taken away. End of story.
Verizon/GeoTrust has been known to offer these certificates of this nature as a paid service. That is, signing your CA in exchange for money. If you are a business and you want a "CA", you can probably buy this service. This is not something you gotta be particularly trusted to do.
Based on my understanding about it: this is not about trust so much... if you have enough money and you are able to make a deal, abide by the terms, and meet whatever qualifications they had set, you get the CA you want.
Verizon can't cancel a contract just because someone else doesn't like it or has an opinion that the person they sold the service to might not be that trustworthy.
So the EFF puts Verizon in what I would call an 'uncomfortable' situation.
You need proof that Etisalat has conducted a MITM attack, or that Verizon didn't intend to sign them in the first place.
Then a revokation might be able to be done, without Verizon getting sued.
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
Logically, the levels of security should be:
However, this would involve educating users, which everybody hates doing.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
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.
Trust means a lot of things. If a CA engages in writing deliberately fake certificates so one nation can hijack or commit online trespass by intercepting data that they otherwise should not have, the CA is not trustworthy, and should be expunged from browsers.
This applies to all CAs. If Verisign handed out fake certs so people can intercept bank traffic, their certs should be yanked out of Web browsers. A CA's core job is to assure that to the best of their ability that someone they say is foo.com is in reality foo.com, and not blackhat.com. It doesn't matter what the reason a CA wouldn't not do this. If they hand over intermediate keys to an eavesdropper, they have fundamentally failed in their duty.
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?
Incidentally, "Wow, where to start" is not an argument.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
For a small business, there is always the option of making sales the old-fashioned way: in person.
The business was a click-and-mortar retailer. Click brought in several times more revenue (and earnings) than mortar ever did because our order filling system was so much more efficient than competitors'. If we dealt only with customers living within 30 miles or 50 km of our warehouse and retail store, we likely wouldn't be able to pay rent, utilities, and other overhead. Another comparison: imagine if a publisher of mass-market software decided to sell copies of its software only on disc, and then only to residents of greater Green Bay.
Maybe even build a web of trust model.
I've read about OpenPGP's web of trust, but how can this work without frequent air travel to get a key signed by people living in different parts of the world?
The way things should be done is simply not the way things are actually done.
Do you mean this in the sense of "practice will never match theory" or in the sense that "practice can and should change soon"?
You mean like RFC4398? :)
http://tools.ietf.org/html/rfc4398
There is unfortunately no browser support, which surprises me ...
And the first time that your newly installed browser points to a plain old HTTP page it should say something like "This is an unsecured page. Anything you read on it, and any forms you fill in, can be read by almost anybody. Most pages on the Internet are like this. You should not use them unless you are happy for the whole world to know what you are doing.", followed by an option "In future,replace this warning with an xxx symbol in the lower left corner of this window".
Yes, I know it won't happen.
From scarped cliff or quarried stone she cries "A thousand types are gone, I care for nothing, no not one."
You really don't get a warning for a changed certificate ?
Strange, the SSL library itself does provide a warning in this case, and (I believe) requires the code (the browser) to confirm that it really wants to use this encryption.
The problem cert chains solve is to establish an initial base of trust. It is not (and should not) be used afterwards.
Not giving a root CA to the holder of a tld seems ... well ... to defeat the purpose really.
To fully break the chain of trust, etisalat (and thus the UAE) would have to be removed entirely from all internet infrastructure. They don't deserve trust, as they don't respect many international treaties. They, for instance, don't respect human rights (they "violate islam", apparently, as to why that's a problem ... Also they've signed treaties (e.g. the "three no's of cairo" that directly violate these treaties and are, frankly, racist). They certainly deserve to be thrown out of the UN, but they're part of the largest voting block in the UN (which ironically, is against human rights, and even against the idea of the UN itself). So good luck getting this done.
Is there a way I can get a revocation certificate for Etisalat now, and install it now, and not have to wait for Verizon to do something about it?
Etisalat is not in IE, Firefox, Opera, etc., but just devices managed by Verizon. But your point is still valid. CNNIC is in them all, and IMHO is not to be trusted.
What's worse, unless you disable automatic Root Certificate Authorities, Windows XP SP2 and other versions automatically add them back in when there are updates, even though you deleted them. With Vista, you cannot even delete some Root CAs.
Some criticisms here.
My bad, as others pointed out in other threads here. Verizon owns GTE, which is a root CA in these browsers. GTE has issued the Intermediate CA to Etisalat.
About the best thing you could do is use a VPN when in any places controlled by Etisalat and proxy your connection through that.
As a user, how do I tell that the self-signed cert that I received for your site came from you and not from a MITM between you and I? It is a trivial task to set up a rogue "free wifi!" AP that proxies all connections.
1. Never use "free Wifi" without a VPN connection. This is a good general rule.
2. Sites using self-signed certs should publish their cert's fingerprint 'out of band'. This means you can view the fingerprint on some (preferably separate) web site, or a telephone conversation, or on some printed correspondence. Then access the https: site and when the cert dialog appears, tell it to view it so you can see the fingerprint and compare it with the out-of-band version.
Heh, that is mostly what I meant, although I don't quite see the point of storing entire certs. I guess that's for offline-encryption, encrypting email and whatnot. IIRC that's what X.509 is for.
When you can exchange certs in real time over the connection, like with SSL, you just need to make sure the cert fingerprint is right, so that's all you need OoB.
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)
Get with the program, man, that was released on Friday.
Holy crap, they're IN MY BRAIN. IN MY BRAIN. AAAAAAAAAAAAAAHHHHHHHHHHH.
Either that, or I am somehow subconsciously receiving all draft RFCs directly into my brain.
No, seriously, I've thought this since I started hearing about DNSSEC. 'Hey, wait, if we have a way to verify that a DNS response is from the proper owners, then why not simply use that to transmit a fingerprint of a cert, to 'sign' it that way?'
Good to see others have pointed that out, and maybe someone will do something about it.
If corporations are people, aren't stockholders guilty of slavery?
No, seriously, I've thought this since I started hearing about DNSSEC. 'Hey, wait, if we have a way to verify that a DNS response is from the proper owners, then why not simply use that to transmit a fingerprint of a cert, to 'sign' it that way?'
Right, and many of the arguments for the CA hierarchy and that shakedown go away. Not all, I'll admit, but most.
So, great resistance ought to be expected. Kudos to the guys at Google.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
What would be really nice is if, at the same time, we'd stop doing the domain check.
After all, that's solely to make sure the signed cert is using the right domain, there's no point in doing it if we were informed that domain is using that cert to start with.
And, without the domain check, we can just use the same cert on multiple domains, and thus not worry about having an IP address for each one.
Probably could just use a * cert without any changes at all beyond the DNS-verify thing.
If corporations are people, aren't stockholders guilty of slavery?