×

Announcing: Slashdot Deals - Explore geek apps, games, gadgets and more. (what is this?)

Thank you!

We are sorry to see you leave - Beta is different and we value the time you took to try it out. Before you decide to go, please take a look at some value-adds for Beta and learn more about it. Thank you for reading Slashdot, and for making the site better!

EFF Asks Verizon Whether Etisalat Deserves CA Trust

timothy posted more than 4 years ago | from the suuuuuure-they-do dept.

The Internet 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."

Sorry! There are no comments related to the filter you selected.

Well duh (3, Interesting)

Pharmboy (216950) | more than 4 years ago | (#33250088)

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?

Proves that certs are useless in the real world. (-1, Troll)

Anonymous Coward | more than 4 years ago | (#33250308)

Certificates are mainly an academic concept. They originally came out of academia, rather than industry, although they did eventually gain some industrial usage. HTTPS is, of course, one of the major ones.

So it's no surprise that, as a concept, they don't work so well in the real world, where money, power and influence are the driving factors, rather than theory.

Re:Proves that certs are useless in the real world (2, Insightful)

betterunixthanunix (980855) | more than 4 years ago | (#33250482)

Certificates work just fine in the "real world;" it is the CA system that is the broken.

Re:Proves that certs are useless in the real world (4, Interesting)

TheLink (130905) | more than 4 years ago | (#33251510)

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.

Re:Proves that certs are useless in the real world (2, Informative)

petermgreen (876956) | more than 4 years ago | (#33250918)

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.

Re:Proves that certs are useless in the real world (2, Insightful)

sjames (1099) | more than 4 years ago | (#33251420)

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:Proves that certs are useless in the real world (4, Insightful)

DavidTC (10147) | more than 4 years ago | (#33251700)

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:Proves that certs are useless in the real world (1)

Pinky's Brain (1158667) | more than 4 years ago | (#33252158)

You mean like RFC4398? :)

http://tools.ietf.org/html/rfc4398 [ietf.org]

There is unfortunately no browser support, which surprises me ...

Re: pharmboys (0)

Anonymous Coward | more than 4 years ago | (#33250356)

I just hafta ask, as a complete tangent: were you really raised on pills? GlaxoSmithKline must be so proud.

Re:Well duh (2, Insightful)

mysidia (191772) | more than 4 years ago | (#33250934)

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.

Revoke time (4, Insightful)

ewanm89 (1052822) | more than 4 years ago | (#33250096)

Time to revoke Verizon certificates on my computers.

Re:Revoke time (1)

Xugumad (39311) | more than 4 years ago | (#33250796)

I've been trying to find these certificates to remove them. They don't appear to be anywhere on Ubuntu (probably for the best)... is that just me, or are they hiding under a strange name?

Re:Revoke time (3, Interesting)

TheLink (130905) | more than 4 years ago | (#33250914)

Verizon owns Cybertrust whose CA cert is installed in Mozilla Firefox.

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 (5, Interesting)

VortexCortex (1117377) | more than 4 years ago | (#33250916)

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:Revoke time (0)

Anonymous Coward | more than 4 years ago | (#33250804)

Many of the modern companies and nations are too large and wield too much power. I simply don't use any service provided by Verizon and the like, certs or otherwise.

I'm confused... (0)

Manip (656104) | more than 4 years ago | (#33250144)

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.

Re:I'm confused... (5, Informative)

Anonymous Coward | more than 4 years ago | (#33250172)

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.

Re:I'm confused... (1)

gedw99 (1597337) | more than 4 years ago | (#33250214)

exactly, these trust are based on a chain of trust.

Also, Getting a certificate for SSL is too easy. Its just a stupid Dun and Bradstreet reference and you get one.
you are paying the equivalent of mafia fees.

Itsa pity an open systesm for certificate trust chains cant be developed. But i am not an expert in that

Need levels of certification (2, Interesting)

davidwr (791652) | more than 4 years ago | (#33250296)

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.

Re:Need levels of certification (4, Insightful)

Rich0 (548339) | more than 4 years ago | (#33250336)

- "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.

My browser "complains" about non-SSL (3, Informative)

davidwr (791652) | more than 4 years ago | (#33250378)

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.

Re:My browser "complains" about non-SSL (3, Insightful)

Rich0 (548339) | more than 4 years ago | (#33250562)

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.

In the old days, telephone (0, Offtopic)

davidwr (791652) | more than 4 years ago | (#33250792)

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.

Re:My browser "complains" about non-SSL (2, Interesting)

petermgreen (876956) | more than 4 years ago | (#33250994)

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:My browser "complains" about non-SSL (2, Insightful)

Rich0 (548339) | more than 4 years ago | (#33251266)

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:My browser "complains" about non-SSL (2, Informative)

mlts (1038732) | more than 4 years ago | (#33251472)

I agree with you that maybe a site should pop up a warning before sending info. However, a site with no SSL is just as vulnerable as a site with a self signed key. (This is in contrast to a key that is invalid where it might be hanky-panky in play as opposed to just a SS cert.)

Another use for a SS cert is to ward off two basic types of attack: The guy sniffing a WAP, who likely won't be able to actively intercept the connection. And the Phorm ad-generators whose job it is to insert ads into ongoing streams of traffic. Because those handle so much traffic, it would take a large machine to do the calculations to commit to creating and tearing down SSL tunnels to MITM traffic to sites.

So, even though it doesn't give a solid chain of trust, self signed certs do provide a form of security.

Re:My browser "complains" about non-SSL (3, Interesting)

sjames (1099) | more than 4 years ago | (#33251514)

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.

Re:My browser "complains" about non-SSL (1)

John Hasler (414242) | more than 4 years ago | (#33250888)

> ...I can be sitting in the UAE...

If you are in the UAE then the UAE can do with you as it wills. What matters is what they might do to people outside the UAE

It confuses technical and social requirements (1)

Kupfernigk (1190345) | more than 4 years ago | (#33251152)

The problem is that the browser designers are making the assumption that you only use encryption because you are engaging in activities which entail financial risk. They assume that viewing plain old HTTP pages means that you aren't doing this. This assumption is fast going obsolete; we (as a company) use HTTPS for everything that requires a login, because the cost of encryption is so small and it is so easy just to write if(isSecure()) in our servlets. Others are going the same way.

Logically, the levels of security should be:

  • No private data - HTTP
  • No personal data or login details - HTTPS + self-signed
  • No login details - HTTPS with trusted cert but no authentication from the site to the user
  • Secure - HTTPS, signed cert, authentication from site to user.

However, this would involve educating users, which everybody hates doing.

Re:It confuses technical and social requirements (3, Insightful)

DavidTC (10147) | more than 4 years ago | (#33251834)

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:It confuses technical and social requirements (1)

AusIV (950840) | more than 4 years ago | (#33252096)

The idea of having DANGER WILL ROBINSON DANGER alerts on connections on that are more secure than normal HTTP was idiotic

I agree with you on the need for a new protocol, but given currently available protocols I think the DANGER WILL ROBINSON DANGER is necessary. Self-signed connections are not more secure than HTTP unless you have independently verified the certificate. A man-in-the-middle can decrypt messages from the server, reencrypt them with his own certificate, and pass them along to the client. When the client sends information back, the man-in-the-middle can decrypt them (because they were encrypted with his certificate), reencrypt them with the server's certificate, and forward them along to the server. The encryption provides no tangible security, because it can readily be undone by anyone in the middle of the connection. This isn't some theoretical attack, there are readily available open-source tools that any script kiddie can use to do this, and if an organization wanted to do this on a large scale, they could do so with equipment that costs only a few thousand dollars.

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.

Given that users won't be aware that something is wrong without putting a huge warning in front of them, consider this: If an attacker wanted to man-in-the middle a CA signed HTTPS connection, it works exactly the same way a man-in-the-middle attack against a self-signed certificate works. He decrypts data sent from the server and relays it to the client with his own self-signed cert. If the browser doesn't panic the user a bit, the user is going to give their credentials to the man-in-the middle.

Re:Need levels of certification (2, Insightful)

mlts (1038732) | more than 4 years ago | (#33251440)

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:I'm confused... (1)

mjwalshe (1680392) | more than 4 years ago | (#33251272)

well there a foriegn PTT - this is as about as much use as the grandstanding that american seantor demanding that Tomy Blair and Jack Straw appear before his comittee was going in for.

Re:I'm confused... (0)

Anonymous Coward | more than 4 years ago | (#33251608)

"The question is this: should Etisalat be allowed to verify who other people are?"

Given their past history, hell no.

Given it's through Verizon, no.

Given that a lot of UAE investments have been known for some time to be heavily Iranian backed, to the point they can be seen and called a front for Iranian money, no. (I read _Monocle_. This isn't a slam against Iran or putting front money into seemingly legitimate western wannabe style economic markets, that's rather a common play.)

Combine previous with what Iran did in their prior elections, hell no.

Re:I'm confused... (0)

Anonymous Coward | more than 4 years ago | (#33251622)

AC' to AC. You've got the risk only half right.

The big risk isn't that Etelisat could generate a fake CA... the big risk is that I have no evidence Etalisat is competent. They probably hired a consultant from out west to help set this up. Possibly even someone lurking here. Or maybe just some NSA goon.

Given the nature of it, I'm assuming that the master key would be kept either on a very carefully logged and audited computer (which has to have backups made--where are those backups stored and secured? Who has access? When? How often are backups made...how are they verified? Is there any opportunity to swap a backup in transit?), or on removable media in a safe that has a guard in front of the room without network access...and another piece of removable media to bring out the signed keys.

Either way--the airgap isn't perfect.

Etalisat generating a fake CA is bad. But they'd get caught. Their consultant walking out with a copy and selling it to me on the grey market for a few million... that's *terrifying*. Of course, they could probably get some better rent seeking but just agreeing to sign things for me. That way it's not Etalisat's fault--they just "got hacked."

The only people that would notice are people that already look for premptive changes.

It's *LONG* past time for some BSD type projects (linux is in no way security conscious enough) to pre-emptively scrape the entire public internet (from multiple, well concealed locations) and monitor for HTTPS/SSL/TLS/SSH-type servers, archive their keys/certificates, and publish a list of them at a central place to identify the inevitable spoofing that is no doubt already going on.

It'd be easy enough to monitor and check domains against the "list of public" record, see if the certificate you got *matched* and also if any of the locations that pulled the cert down (need at least one in every country) got a different cert.

This is a *basic* byzantine agreement problem. And it's been academically solved.

Re:I'm confused... (4, Interesting)

Dr. Evil (3501) | more than 4 years ago | (#33250174)

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?

Re:I'm confused... (1)

Richard_at_work (517087) | more than 4 years ago | (#33250292)

And you have no issues with Verizon having this ability also, while operating a significant proportion of the Internet connectivity in the US?

Re:I'm confused... (0)

Anonymous Coward | more than 4 years ago | (#33250626)

And you have no issues with Verizon having this ability also, while operating a significant proportion of the Internet connectivity in the US?

There is quite a big difference. Verizon could disrupt my communications, but without a fake CA certificate, they won't be able to eavesdrop on my encrypted online banking.

Re:I'm confused... (3, Insightful)

DavidTC (10147) | more than 4 years ago | (#33251846)

Erm, in what universe would Verizon find it slightly hard to make a fake cert?

Re:I'm confused... (1)

Peter Eckersley (66542) | more than 4 years ago | (#33251284)

Is it possible for me to reject the Etisalat subCA cert without ever seeing it?

With Chrome/IE/Safari on OS X and Windows only, there is a way to block the Etisalat subordinate CA certs. First you have to fetch a copy (see for instance this site [slashdot.org] ). Note that the Etisalat cert is also labelled "Comtrust". Then export the cert. Then on Windows, reimport them into "untrustuted certificates" store. On OS X, import the cert using the Keychain Application into "My Certificates", and disable it.

Re:I'm confused... (1, Informative)

Anonymous Coward | more than 4 years ago | (#33250176)

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?

Re:I'm confused... (4, Informative)

Jahava (946858) | more than 4 years ago | (#33250342)

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.

Re:I'm confused... (3, Informative)

mysidia (191772) | more than 4 years ago | (#33251252)

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 [pastebin.com]

Based on the certificate presented by https://www.eim.ae/ [www.eim.ae] :

*.eim.ae

Issued to: CN=*.eim.ae, O=Etisalat, OU=SOM // Serial=0E:12
Issued by: CN=Comtrust Server Certification Authority, O=Etisalat, OU=Etisalat eBusiness Services, Not valid before 5/6/09, not valid after 5/6/11
SHA1

Comtrust Server Certification Authority

Issued by: CN=Comtrust Root Certification Authority, OU=Etisalat eBusiness Services, O=Etisalat, C=AE
Issued to: CN=Comtrust Server Certification Authority, O=Etisalat, OU=Etisalat eBusiness Services, C = AE
Not valid before 10/5/06 6:24:51 GMT
Not valid after 12/19/15 23:59:00 GMT
CRL not-critical URI: http://comtrust.etisalat.ae/rootca.crl [etisalat.ae]

Comtrust Root Certification Authority

Issued by: CN=GTE CyberTrust Global Root, OU = "GTE CyberTrust Solutions, Inc.", O = GTE Corporation, C=US
Issued to: CN=Comtrust Root Certification Authority, OU=Etisalat eBusiness Services, O=Etisalat, C=AE
Not valid before 12/19/05 18:13:00 GMT
Not valid after 12/19/15 23:59:00 GMT
CRL not-critical URI: http://www.public-trust.com/cgi-bin/CRL/2018/cdp.crl [public-trust.com]

Re:I'm confused... (3, Informative)

TheRaven64 (641858) | more than 4 years ago | (#33250178)

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/ [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.

Re:I'm confused... (0)

Anonymous Coward | more than 4 years ago | (#33250196)

Etisalat performs man-in-the-middle attacks on SSL connections and in doing so uses its (Verizon approved) root CA certificate to then generate SSL certificates on the fly to be able to eavesdrop surreptitiously on any SSL connection originating from the UAE.

If that is fine by you, then by all means write them a letter of support and/or move to the UAE.

Re:I'm confused... (0)

Anonymous Coward | more than 4 years ago | (#33250470)

Etisalat performs man-in-the-middle attacks on SSL connections and in doing so uses its (Verizon approved) root CA certificate to then generate SSL certificates on the fly to be able to eavesdrop surreptitiously on any SSL connection originating from the UAE.

If that is fine by you, then by all means write them a letter of support and/or move to the UAE.

While I don't necessarily think Etisalat should be an intermediate CA, this is pure FUD. There is no evidence whatsoever that Etisalat has performed MITM attacks, only that they could.

Re:I'm confused... (1)

mysidia (191772) | more than 4 years ago | (#33250672)

If that's the case, we need all the other CAs to add Etisalat's certificate to their CRL. Anyone who downloads the CRLs will then not trust Etisalat's certificate.

Perhaps they should add Verizon's certificate to the CRL as well; though, things could get messy....

Re:I'm confused... (1)

Achromatic1978 (916097) | more than 4 years ago | (#33251808)

If that's the case, we need all the other CAs to add Etisalat's certificate to their CRL.

We do? We do? Who are you and why do you presume to speak for me?

Re:I'm confused... (3, Insightful)

betterunixthanunix (980855) | more than 4 years ago | (#33250202)

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?

Re:I'm confused... (1)

mysidia (191772) | more than 4 years ago | (#33250700)

Maybe they would... what we need is proof that they would do it.

We need an independent mechanism in browsers to verify SSL certificates and automatically report anything suspicious.

What would be ideal would be a Firefox plugin to 'cache' known trusted SSL certificates of websites, and upload them to a central repository viewed by other users of the plugin.

If you go to a website, and the certificate is in the repository (and not expired), and the cert you see is different from the one you saw last time, or the certificate in the repository, then you get a warning.

The assumption behind this is: if a site is popular, the legitimate certificate gets in there first.

And the repository signs the certificate based on the date it was in there, and publishes a new public key every day, destroying yesterday's private key, so the date a certificate was imported can be proved.

Re:I'm confused... (1)

AnyoneEB (574727) | more than 4 years ago | (#33251360)

You seem to have described almost exactly the functionality of Perspectives [cmu.edu] , which has been discussed on Slashdot, although not recently.

Re:I'm confused... (0)

Anonymous Coward | more than 4 years ago | (#33250206)

Just like a Libertarian--noble sounding, providing the basis for a perfect world, and utterly impractical all at the same time. Others have explained why this is a serious security issue. Perhaps people who read this forum know how to "take your business to a root authority which you do trust". Are all end users supposed to be crypto experts now? It is entirely appropriate for Verizon or anybody else who grants certificate-signing authority to anyone to check that they behave in a proper manner. Subverting the chain of trust for government or corporate espionage doesn't really count as "proper" in most peoples' books. Frankly I'm not entirely sure that Verizon or any other large corporation should be trusted with that authority either, but that's another debate.

Re:I'm confused... (1)

jon3k (691256) | more than 4 years ago | (#33251146)

It's based on a chain of trust, not just identity. Just because I can validate Bob the Hacker doesn't mean I should start letting him sign certs and make him a trusted CA. Microsft and Mozilla can't fix this because the trust is delegated by Verizon. So either they remove Verizon's certificates or they can't stop it.

Re:I'm confused... (0)

Anonymous Coward | more than 4 years ago | (#33251462)

Your confused because you don't understand the implications. Etisalat has an intermediate certificate signed by verizons root. This means they can generate a cert for ANY DOMAIN and it will look completely valid on practically all browsers on the planet. Users see the padlock icon and unless they examine the cert chain and scruitinize every entry in the trust chain (Guaranteed noone will do this) they can usurp at will.

This is why its critically important all roots and intermediates under them be totally trust-worthy. The system is only as good as its weakest partner. If it were me I would be calling to investigate verizon with major browser vendors to see if their certs should not also be revoked.

In the bigger picture the entire global trust system in terms of secure web sites and the new dnssec is a fools errand. The trust anchor is just too large and there is too much negative incentive in its operation to have any real confidence in the system which makes the entire exercise worthless. Coupled with increasing government focus on the role of the Internet in the world do we even know which countries could legally force a CA to secretly give them an intermediate? Would be it easier to ask in which countries that would be illegal?

What we need are crypto bindings between user credentials and the underlying network session. Most secure sites require you to 'login'.. now if knowledge of these credentials are used as the basis for mutual trust between systems you instantly don't need to pay for SSL certs anymore or be subject to the mercy of others for the security of YOUR system. What we really need is something like SRP bindings for TLS in all browsers. Unfortunatly PKI is a revenue source for most browser projects so politically it won't happen unless we make it happen (fork firefox) even if technically its a sound idea.

Letter to Verizon...? (-1, Redundant)

Manip (656104) | more than 4 years ago | (#33250152)

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.

Re:Letter to Verizon...? (3, Insightful)

drinkypoo (153816) | more than 4 years ago | (#33250204)

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:Letter to Verizon...? (1)

Crash Culligan (227354) | more than 4 years ago | (#33250340)

drinkypoo: Otherwise "trust" is just a word.

Oh, not even that — it becomes a marketing term. At least words have meaning.

Re:Letter to Verizon...? (1)

mlts (1038732) | more than 4 years ago | (#33251634)

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.

Re:Letter to Verizon...? (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#33250226)

You not too smart are ya?

Removal (0)

Anonymous Coward | more than 4 years ago | (#33250160)

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.

Manual removal is a pain (2, Informative)

davidwr (791652) | more than 4 years ago | (#33250332)

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.

Re:Manual removal is a pain (1)

inKubus (199753) | more than 4 years ago | (#33251498)

Netscape gave us this flawed system and it was rushed out before anyone could think about it. So everyone started feeling safe about ecommerce. To me, what makes me feel safe is the fact that I have limited liability for credit card transactions, not SSL.

If you want real privacy, you need a secure key exchange. That means out-of-band (such as in person), you exchange public keys.

If it were easy to do (and it will be as I'll describe), you could have an easier way to input public keys into the browser (such as a QR code) using your android phone. So when you open your account at the bank, you scan their QR code for their key and they scan yours. Then your phone when you set it up exchanges keys with your browser. No EXTERNAL trust needed. You can be as safe as you want.

Obviously the current web of trust works well for casual transactions, but anything important like banking, taxes, healthcare, credit-related, or identity-related should use safe keys. There is no reason to not do it, it's been a false sense of security that has kept this from happening.

So the personal CA is needed, and that means a micro web of trust between your devices and easy ways to share your public key(s). I think the QR code can do this.

Here's a project [google.com] to do that. If a single QR code does not hold a key of sufficient length, you can always have a serial array of two or three or four codes that you scan in order. Of course it'll only work if we can capitalize on it in a free and open way. That means open standards. Get on it people, down with the government controlled, leaky as a sieve web of trust!!

Re:Removal - Mozilla CA certificates (5, Informative)

dismentor (592590) | more than 4 years ago | (#33250370)

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.

critera (1)

Threni (635302) | more than 4 years ago | (#33250184)

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.)

Blocked (1, Interesting)

Anonymous Coward | more than 4 years ago | (#33250216)

The NY Times story is being blocked by their proxy servers. Trying to keep costumers in the dark as usual.

Re:Blocked (1, Funny)

fbjon (692006) | more than 4 years ago | (#33250652)

Trying to keep costumers in the dark as usual.

Yes, how will the wardrobe purveyors follow this news thread now??

Man in the Middle Worries and Avoidance? (3, Interesting)

simpz (978228) | more than 4 years ago | (#33250222)

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.

Re:Man in the Middle Worries and Avoidance? (4, Interesting)

betterunixthanunix (980855) | more than 4 years ago | (#33250232)

Re:Man in the Middle Worries and Avoidance? (1)

simpz (978228) | more than 4 years ago | (#33250374)

Looks good. I wonder if it can be hybridized so that I can at least get some reassurance from the CA about any new SSL sites I visit (if they feel they are valid) before I accept them.

Re:Man in the Middle Worries and Avoidance? (1)

tepples (727027) | more than 4 years ago | (#33250680)

From "Life without a CA":

How do you validate the certificate? It depends on the other end. For sites I worry about, like my bank or favorite shopping stores, I call support and ask for the SSL fingerprint and serial number. Sometimes the support person even knows what I'm talking about. I suspect they just open their browser, click on the lock icon and read me the information.

But if the business isn't yet a household name, how would you even see the telephone support number without accepting the certificate? And what do you do about businesses whose telephone hours "conveniently" coincide with the hours when you're supposed to be at work or, especially in the case of overseas businesses, with your ordinary bedtime?

Re:Man in the Middle Worries and Avoidance? (1)

betterunixthanunix (980855) | more than 4 years ago | (#33250904)

Well, perhaps people need to reevaluated the risks involved with giving credit card numbers to small, unknown businesses that they cannot find any information about except online.

Re:Man in the Middle Worries and Avoidance? (1)

tepples (727027) | more than 4 years ago | (#33251062)

Without a TLS certificate from a well-known CA, how do you recommend that a new small business take money from customers? My employer used to use PayPal, but PayPal cut him off after some Indonesians started using a bunch of stolen credit cards on the web site. It appears PayPal has cut off a bunch of other companies too [paypalwarning.com] .

And how do you recommend that someone securely authenticate to a non-commercial site, such as a blog, forum, or wiki, without a CA and without sending his account's username and password in cleartext over the Internet?

Re:Man in the Middle Worries and Avoidance? (1)

betterunixthanunix (980855) | more than 4 years ago | (#33251398)

For a small business, there is always the option of making sales the old-fashioned way: in person. Perhaps that would be a good place to verify a fingerprint. It would also help people avoid scams, since the scammers would have to meet their victims in person.

As for blogs, forums, and wikis...well, if MITM attacks are a serious concern, then perhaps people should take the time to find the fingerprints for the keys. Maybe even build a web of trust model.

Look, I am not a fool, and I don't actually think that the majority of people would be willing to take the time to verify key fingerprints and maintain their key rings. The way things should be done is simply not the way things are actually done.

Economies of scale from click and mortar (1)

tepples (727027) | more than 4 years ago | (#33252138)

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"?

Re:Man in the Middle Worries and Avoidance? (0)

Anonymous Coward | more than 4 years ago | (#33250392)

the Certificate Patrol [mozilla.org] add-on for Firefox/Thunderbird does exactly that.

"Authenticated by..." lock needs improvement (5, Interesting)

davidwr (791652) | more than 4 years ago | (#33250256)

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."

WHO. (1)

leuk_he (194174) | more than 4 years ago | (#33250360)

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 [e4me.ae] 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 browser needs to put it "in my face" (1)

davidwr (791652) | more than 4 years ago | (#33250458)

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.

Re:"Authenticated by..." lock needs improvement (0)

Anonymous Coward | more than 4 years ago | (#33250596)

Its certificate is issued by "Thawte SGC CA" which in turn is issued by "Verizon, Inc."
No, it's issued by VeriSign, Inc.

Rather important distinction.

How do I un-trust ALL Verizon certificates? (0)

Anonymous Coward | more than 4 years ago | (#33250290)

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?

Re:How do I un-trust ALL Verizon certificates? (1)

colinrichardday (768814) | more than 4 years ago | (#33251108)

In firefox, edit -> preferences -> advanced -> encryption and go from there.

Scarey Future (2)

Bob9113 (14996) | more than 4 years ago | (#33250344)

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!...

...Oh -- it's just about a CA.

The system is broken (4, Insightful)

TuballoyThunder (534063) | more than 4 years ago | (#33250346)

There are so many trusted certificate signing authorities that I believe the trust system is untrustworthy. I counted over 40 certificate authorities in Mozilla and I did not make it past the letter "I' in the list of trusted CA's. Throw in the intermediate CA's and the problem gets worse. Lets assume that all CA's are trustworthy. Furthermore, assume that there is a 1 in a million chance for any individual CA in any given year to make a mistake. A system of 100 CA's would have a 1 in 10,000 chance of making a mistake. Many of the CA are regionally focused and it makes no sense why a user should trust all CA's equally.

The following changes could be useful:

  • selectively prune the trust hierarchy
  • flag certificates that change (there are addons)
  • specify the maximum path length you are willing to trust
  • Be able to assign a trust weight to a CA

Re:The system is broken (2, Informative)

davidwr (791652) | more than 4 years ago | (#33250416)

* selectively prune the trust hierarchy

- Not practical without creating an artificial scarcity problem. You want enough trusters to meet market demand and prevent artificially high pricing.

* flag certificates that change (there are addons)

- Very good idea.

* specify the maximum path length you are willing to trust

- I'm not sure this is explicitly needed with trust weight assignments. You can assign a weight of "x-1" for each level you drop, and give 1st- and any-other-level certs whatever weight you want - "2" for signers you trust to delegate but don't trust their assignees to delegate, "infinity" for authorities you trust won't ever make a mistake and whose delegates and sub-delegates etc. you trust never to make a mistake, and in between for most others.

* Be able to assign a trust weight to a CA

- This is essential. This should be doable by both individuals, independent "reputation authorities" that individuals tell their browsers to query, and for the 99% of people who will default to doing nothing, a reputation authority picked by the browser vendor.

Re:The system is broken (0)

Anonymous Coward | more than 4 years ago | (#33250798)

DNSSEC is going to be an improvement. With DNSSEC, there is only one CA path for signing the records of a domain. Suppose you have a .nl domain (Netherlands). Then the root authority can only legitimately delegate the signing authority for the nl TLD to the nl-registry (by signing the key records of the nl-TLD) and no other registry can sign nl domains without this delegation. In the SSL certificate system on the other hand, any CA can sign certificates for any domain. An Arab Emirates based CA can sign a certificate for www.google.com. We'll be much better off when browsers can accept SSL keys through DNSSEC.

Re:The system is broken (1)

dkf (304284) | more than 4 years ago | (#33250936)

DNSSEC is going to be an improvement.

Only in as far as identities related to internet hosts. X.509 certificates are used for other things, such as authenticating users to servers and to each other (which is also used in things like code signing). Those certificates don't (have to) have the host name in anyway, so DNSSEC is irrelevant to their security, and any bad (or compromised) CA could impersonate anyone.

The biggest protection against this sort of problem is that user certificates are less likely to have as wide a set of trust roots. (For example, if you're dealing with signed drivers for Windows, it makes a heck of a lot of sense to have Microsoft holding the only trust root, whatever you think of their business policies.) If Verison's CA isn't one of the trust roots, Etisalat can't impersonate anyway. And one way of dealing with this is to have businesses (that need it at all) sign customer certificates at the start of a business relationship; after all, that's when they'd want to establish the identity of the customer anyway.

(And FWIW, I suspect that DNSSEC isn't going to be as great as some people think it will be. An incremental improvement, not a revolution.)

Heh (0)

X.25 (255792) | more than 4 years ago | (#33250466)

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 :)

Being serious for a moment... (1, Interesting)

Kupfernigk (1190345) | more than 4 years ago | (#33250528)

I have a hard time with this. I am operating a web site which provides information to identified users. I have a self-signed certificate which correctly identifies itself as belonging to my site. What is wrong with this? I want you to identify yourself to me, securely, before I will tell you anything.

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:Being serious for a moment... (1)

Dr. Evil (3501) | more than 4 years ago | (#33250734)

How do you revoke a self-signed cert?

Re:Being serious for a moment... (1)

jon3k (691256) | more than 4 years ago | (#33251220)

Wow, where to start. The point of a trusted CA is you have a 3rd party who can give you the thumbs up or thumbs down on a resource. You seem to work from the assumption that you intrinsically trust the site you're trying to reach. The point of a CA is to verify that you are indeed talking to who you think you're talking to, and to encrypt that communication. If I'm on the Internet and I click a link to xyz-company-ive-never-visited.com and I get an unsigned SSL certificate warning you're saying I should trust that MORE than if I accessed the same site and got a signed SSL certificate from a trusted root CA?

Re:Being serious for a moment... (1)

Dr. Evil (3501) | more than 4 years ago | (#33251654)

Aside from the problem of revoking a self-signed cert, I agree with this self-signed philosophy.

The trick is that you need to find a way to bootstrap the trust. That will probably be an out-of-band communication, e.g., a letter, phonecall, visit to an office or something. But once you've established that trust, then you are not depending on multiple third parties, some politically hostile, to ensure that your communications are secure.

For out of band communication, putting a fingerprint of a signature on a business card could be one method. If you trust that the branch you visited was real, and the person you met was real, you could trust that signature, which could be used to verify the certificate presented by the website.

No, I'm not (1)

Kupfernigk (1190345) | more than 4 years ago | (#33251738)

I'm saying that nowadays with hosting services sharing certificates among multiple subdomains, you should not trust a signed SSL certificate that is not for that exact domain any more than you should trust a self-signed certificate. It should be important that the certificate be for the exact domain being accessed, but currently it isn't, for commercial rather than security reasons.

Incidentally, "Wow, where to start" is not an argument.

Self-signed certificates and trust (3, Informative)

davidwr (791652) | more than 4 years ago | (#33250624)

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.

Re:Heh (0)

Anonymous Coward | more than 4 years ago | (#33251096)

Apparently you don't either.

This Explains A Lot... (0)

Anonymous Coward | more than 4 years ago | (#33250494)

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.

It shouldn't make you nervous at all (1)

davidwr (791652) | more than 4 years ago | (#33250660)

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.

Time for Escrow Accounts (0)

Anonymous Coward | more than 4 years ago | (#33250848)

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.

Revoke It! (0)

Anonymous Coward | more than 4 years ago | (#33250852)

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.

Intermediary CA is a service (1)

mysidia (191772) | more than 4 years ago | (#33250890)

Verizon/GeoTrust [wikipedia.org] 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.

Re:Intermediary CA is a service (1)

jon3k (691256) | more than 4 years ago | (#33251242)

I agree with you except I feel it's Verizon that put ITSELF in an uncomfortable position. Verizon is pimping out the trust in their name for a price. Simple as that.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?