EFF Asks Verizon Whether Etisalat Deserves CA Trust 135
Peter Eckersley writes "Today EFF published an open letter to Verizon, calling for investigation of a trusted SSL Certificate Authority. Etisalat is a majority state-owned telecom of the United Arab Emirates with operations throughout the Middle East. You may remember that last year Etisalat installed malware on its subscribers' BlackBerry phones, and was recently pivotal in the UAE's threat to disconnect BlackBerry devices altogether if Research In Motion did not provide a backdoor for BES servers' crypto. This company, which appears to be institutionally hostile to the existence and use of secure cryptosystems, is in possession of a master certificate for HTTPS, encrypted POP and IMAP, and other SSL-based security systems. Etisalat's CA certificate is not trusted directly by Mozilla and Microsoft, but was instead delegated as an Intermediate CA by Verizon. As a result, we are asking Verizon to investigate whether it is appropriate for Etisalat to continue holding this certificate, and to consider revoking it."
Well duh (Score:4, Interesting)
Again, well duh. Is there really any question that they can't be trusted with granting certs when they are so openly hostile to encryption of any kind?
Re: (Score:2, Insightful)
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 equ
Re: (Score:3, Insightful)
Re:Proves that certs are useless in the real world (Score:5, Interesting)
If say you go to https://www.yourbank.com/ at home and the cert is signed by Thawte.
Then one day you go to UAE and visit https://www.yourbank.com/ and the cert is signed by Etisalat whose cert is signed by Cybertrust whose cert is installed in your browser.
By default your browser won't warn you at all!
In fact for this scenario you would be safer if you actually deleted all the CA certs, and accepted certs on a site by site basis, because you would then get a warning since the cert has changed.
Currently I'm using the Certificate Patrol plugin and I hope it works properly and doesn't automatically "bless" some CAs as trustworthy, since as far as I'm concerned it's better to assume that they all aren't.
Re: (Score:2)
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 [microsoft.com], 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 [proper.com].
Re: (Score:2)
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.
Re: (Score:3, Informative)
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
Re: (Score:3, Insightful)
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
Re:Proves that certs are useless in the real world (Score:5, Insightful)
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: (Score:2)
You mean like RFC4398? :)
http://tools.ietf.org/html/rfc4398 [ietf.org]
There is unfortunately no browser support, which surprises me ...
Re: (Score:2)
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.
Re:Proves that certs are useless in the real world (Score:4, Informative)
Get with the program, man, that was released on Friday [ietf.org].
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.
Re: (Score:2)
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,
Re: (Score:2)
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.
Re: (Score:2)
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.
Revoke time (Score:4, Insightful)
Re: (Score:2)
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 (Score:4, Interesting)
From the article:
"We are writing to request that Verizon investigate the security and privacy implications of the SSL CA certificate (serial number 0x40003f1) that Cybertrust (now a division of Verizon) issued to Etisalat on the 19th of December, 2005, and evaluate whether this certificate should be revoked."
FWIW, CNNIC (state network information center of China) has it's cert signed by Entrust. So if you don't trust CNNIC, you shouldn't trust Entrust either
You can use the Certificate Patrol plugin to help keep track of CA/cert changes in sites you visit. After all if your bank website's cert was signed by Comodo today, but CNNIC when you go to China, I'd think you'd want a warning. Current browsers by default would NOT give you a warning in this scenario as long as the website's certificate chain is ultimately signed by one of the CA certs installed in your browser.
So go figure how much the browser bunch really care about your security.
Re:Revoke time (Score:5, Interesting)
If you use firefox: Edit > Preferences > Advanced > Encryption > View Certificates > Authorities
Personally, I've deleted all of the authorities and only add certificates as I need them.
This is because a CA can be compelled by the country they are in to sign a certificate for any domain.
For example: If your browser trusts the Etisalat CA then Etisalat can can create a SSL certificate for Google.com even though Google.com didn't ask for one.
If your DNS then points to a Etisalat server it can serve pages as Google.com (pretty green "I'm secure" bar and all).
You'd have to view the cert info to make sure Google's real CA signed the current cert...
Thawte, Verisign and Verison can be compelled by the US to create fake certs too, but in this case only the IP address would tip you off.
If my browser was sent a fake cert and fake DNS results I will be presented with an "Untrusted Certificate" screen.
Since this normally only happens when Google's cert is about to expire I would be alerted.
tl;dr: CA system is broke because any CA can make a cert for your domain without your consent.
Re: (Score:2)
In part, this problem might be solved by DNSSEC.
Re:Revoke time (Score:5, Insightful)
In part, this problem might be solved by DNSSEC.
Unfortunately not, because the decision makers of internet security protocols are all greedy pigs who want to charge you money for a service that you can do yourself for free.
From day 1, the HTTPS CA and DNS CA systems should have been one and the same.
That is, not tying the two systems together is a gaping security hole that means that even if you control a domain, someone else can issue certificates for that domain and the users can't tell.
DNS should have had a CA hierarchy built into it from the beginning, so that if you own 'google.com', you can issue a cert for it for free as easily as creating a record, and if anyone else tries to do the same, they won't get very far because they can't create a cert signed by *your* DNS domain key.
There's so much more money to be made however by taking the CA control out of the hands of the DNS domain admins and putting it in the hands of some corporation.
Re: (Score:2)
I agree 100% regarding SSL CAs should have been based on a DNS hierarchy.
But there is nothing to stop that from occurring, now that the root is signed, dot-gov, dot-edu, dot-org, dot-biz, dot-us, and may other ccTLDs are signed and available for the domain owners to add their DS keys into the zone to establish a chain of trust from the root all the way down. Dot-com and dot-net are soon to follow in the next year.
What is missing right now is extending that trust model all the way down to the stub-resolvers
critera (Score:1)
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 (Score:1, Interesting)
The NY Times story is being blocked by their proxy servers. Trying to keep costumers in the dark as usual.
Re: (Score:2, Funny)
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? (Score:3, Interesting)
It obviously will change when it expires but at least you could examine it ( a really smart client could tell you that just the dates have changed).
Then if a valid new cert was put in place between yourself and the actual site you'd see the change.
Re:Man in the Middle Worries and Avoidance? (Score:5, Interesting)
Re: (Score:1)
Re: (Score:2)
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: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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 t
Economies of scale from click and mortar (Score:2)
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
Re: (Score:2)
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?
Well part of the idea behind the web of trust is that you can derive trust from others who travel. So, for example, you might obtain my certificate, and it was already signed by 3 people whose fingerprints you verified; then you have some assurance that my key is authentic. Since there is a chance that people are conspiring against you, you might limit this to be 1- or 2-deep, so that you don't wind up with too long of a WoT chain. You can also have different levels of trustworthiness; perhaps you requ
"Authenticated by..." lock needs improvement (Score:5, Interesting)
Browsers need to clearly show WHO is authenticating and some measure of "reputation" of each authenticator in the chain.
Let's use https://www.google.com/ [google.com] as an example.
Its certificate is issued by "Thawte SGC CA" which in turn is issued by "Verizon, Inc."
If the "reputation" of Thawte and Verizon were both high, then the lock-symbol in my browser would be green. If either one were "medium" then it would be "orange." If either one had a bad "reputation" then it would be red. Of course if any link in the chain were revoked then there should be no lock-symbol at all and possibly some big nasty warning messages to boot.
Browsers also need to allow users to remember signatures alert users if they change, to identify poisoning attacks where FakeBank gets a valid, seemingly-reputable certificate for yourbank.com due to a clerical error or fraud AND uses it along with DNS poisoning or other means to fool your bank into visiting FakeBank.IP.Address and getting a "valid" certificate when it wants to go to yourbank.com.
Whether it's the browser vendor that determines who the reputation vendor is or whether it's the user will largely be a market decision, at least in most countries. In some countries of course the government will try to control reputation, labeling any certificate authority that doesn't follow its rules as "untrusted."
In the case of Etisalat, reputation vendors in the West may mark Verizon as "green" and Etisalat as "orange" or even "red." The UAE may try to force people in its country to use a reputation authority that marks Etisalat as "green" and COMODO CA Limited, the authority the EFF uses, as "red" in retaliation for bringing this up in the first place. Memo to the UAE if they try this: "Good luck with that."
WHO. (Score:2)
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" (Score:1)
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
Re: (Score:2)
Yes they do. Their CA is entitled "ComTrust".
Re: (Score:2)
Browsers need to clearly show WHO is authenticating and some measure of "reputation" of each authenticator in the chain.
Who guards the guards?
Who gets to say who is reputable - and - just as importantly - why should I believe them?
Scarey Future (Score:3)
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!...
The system is broken (Score:5, Insightful)
The following changes could be useful:
Re: (Score:2, Informative)
* 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
Re: (Score:2)
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
Heh (Score:1)
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... (Score:2, Interesting)
In another scenario, someone is using a shared certificate issued by a "trusted" supplier, but owing to the domain structure it could be cloned and used in a MiM attack. My browser doesn't care.
My conclusion fr
Re: (Score:2)
How do you revoke a self-signed cert?
Re: (Score:2)
Re: (Score:2)
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
No, I'm not (Score:2)
Incidentally, "Wow, where to start" is not an argument.
Re: (Score:2)
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.
answer (Score:2)
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.
Self-signed certificates and trust (Score:3, Informative)
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 wil
Revocation certificate? (Score:2)
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?
Re:I'm confused... (Score:5, Informative)
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: (Score:1)
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 (Score:2, Interesting)
Even if we can't get an "open" system, at least industry - pushed by web browser vendors - can get standards in place.
"Certificate good for authenticating web pages but not signing other certificates":
- very high proof of identity for banks and other "high stakes" places
- high proof of identity for e-commerce and other sites that deal with sensitive information
- medium proof of identity for most other web sites that want to be taken seriously
- "Liar's signed certificate" for individuals and others where ide
Re:Need levels of certification (Score:5, Insightful)
- "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 (Score:3, Informative)
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 (Score:4, Insightful)
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.
Re: (Score:3, Interesting)
I was just saying that the browser should simply not display the padlock at all. They shouldn't treat the connection as less secure than non-SSL
A big problem with this is the page by page model of the web.
Consider I make a page which is only served over https, said page contains links and form submissions to other pages on the site. Those pages may or may not be on the same hostname as the current page.
Consider a man in the middle that only intercepts some proportion of web requests or in the case of multip
Re: (Score:3, Insightful)
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: (Score:2)
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).
If by "significant", you mean US$5 (which is what Comodo charges) per year, sure.
Re: (Score:2)
Uh, citation? I don't see a $5/yr option. I do see a 90-day-free certificate (which sounds like a royal pain in the neck - mainly designed to get you to spend more I guess).
Re: (Score:2)
I suppose it was unfair to expect you to remember all of Comodo's 10,000 brand names.
http://www.positivessl.com/ [positivessl.com]
"From $5.00/ yr"
Just don't pick "Free upgrade to EV" unless you're a company, with a looooooooot of time on your hands to handle the documentation. I'll let you chew over exactly what's weird about that offer.
Re: (Score:3, Informative)
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 stre
Re:My browser "complains" about non-SSL (Score:4, Interesting)
Specifically, a self-signed cert should show a YELLOW url bar and a locked padlock, meaning the connection is well secured by encryption but the identity of the other party is in question.
Re: (Score:2)
> ...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 (Score:2)
Logically, the levels of
Re:It confuses technical and social requirements (Score:4, Insightful)
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: (Score:2)
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
Re: (Score:3, Insightful)
Self-signed connections are not more secure than HTTP unless you have independently verified the certificate.
Yes they are.
Spying on those connections vs. HTTP connections, requires more work, and hence are objectively 'more secure' by any measure of 'secure'. You have to MitM them to spy on them, whereas you don't for normal HTTP connections.
Also, you have to MitM in real time, where it can be detected. (And should be, as browsers should warn when certs change.) Whereas simply recording traffic is utte
Re: (Score:2)
"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."
What you are failing to explain is WHY this is more "wrong" than plain HTTP. MITM and every other attact against a self-signed site works equally well, if not better, for HTTP, correct? So to be consistent, the browser should pop up a "this site has no signed certificate" warning for *every* HTTP page!
Now I may be mistaken in thinking that a self-signed c
Re: (Score:2)
What I suggest is, now that DNSSEC has taken off, we invent some sort of TXT DNS record that contains the fingerprint of that domain's SSL key.
Even without DNSSEC, this would add a layer of security. With DNSSEC, I'm having trouble figuring out a workable attack against it.
I think it is fixable (Score:2)
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 fi
Re: (Score:3, Insightful)
The neat thing would be if HTTP could just transparently upgrade to SSL without displaying the secure connection icon.
Re: (Score:2)
It would just be nice if all connections were protected from passive sniffing by default. HTTPS is fine as it is (well its PKI is broken, which is why we have this article). However, doing opportunistic encryption for HTTP would be nice, it's just important that the secure connection icon ISN'T being shown, because the connection ISN'T secure.
Re: (Score:3, Insightful)
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'
Re: (Score:2)
Re:I'm confused... (Score:5, Interesting)
If I understand correctly, in this case, Verizon is delegating authority to Etisalat to grant certificates through a subCA. That means that if you trust Verizon, you trust Etisalat.
As an intermediate CA hostile to privacy, they can produce certs which browsers trust without prompting. This means that they can trivially evesdrop on all communications.
Is it possible for me to reject the Etisalat subCA cert without ever seeing it?
Can I trust Verizon anymore, knowing that they grant such certs?
Re: (Score:2)
Re:I'm confused... (Score:4, Insightful)
Erm, in what universe would Verizon find it slightly hard to make a fake cert?
Re: (Score:2)
Erm, in what universe would Verizon find it slightly hard to make a fake cert?
The one where they'd get sued six ways from Sunday if they used it and were caught?
Re: (Score:2)
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: (Score:1, Informative)
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 certific
Re:I'm confused... (Score:5, Informative)
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: (Score:3, Informative)
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
Re:I'm confused... (Score:4, Informative)
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... (Score:4, Insightful)
Re: (Score:2)
Re: (Score:2)
We do? We do? Who are you and why do you presume to speak for me?
Re:Letter to Verizon...? (Score:4, Insightful)
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: (Score:2)
Oh, not even that — it becomes a marketing term. At least words have meaning.
Re: (Score:2)
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
Manual removal is a pain (Score:2, Informative)
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: (Score:2)
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 (su
Re:Removal - Mozilla CA certificates (Score:5, Informative)
It shouldn't make you nervous at all (Score:1)
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.
Re: (Score:2)
In firefox, edit -> preferences -> advanced -> encryption and go from there.
Re: (Score:2)
Re: (Score:2)
GeoTrust is Verisign (now Symantec). GTE is Verizon