Slashdot Mirror
Comodo Hack May Reshape Browser Security
suraj.sun writes "Major browser makers are beginning to revisit how they handle Web authentication after last month's breach that allowed a hacker to impersonate sites including Google, Yahoo, and Skype. Currently, everyone from the Tunisian government to a wireless carrier in the United Arab Emirates that implanted spyware on customers' BlackBerry devices and scores of German colleges are trusted to issue digital certificates for the largest and most popular sites on the Internet."
With DNSSEC and DNS based SSL keys, only the single trust chain from the root to the domain can sign the keys.
Changes need to be made when an issue is found, in anything for that matter. Not doing so is about as useful as trying to solve the problem by sticking you fingers in your ears and yelling, "LA LA LA LA"
Instead of trusting information from certificate authorities, the browsers should have the public key for the major size burned in and security hashed inside the browser itself. That way it can trust it is downloading a real update of itself from its real home. If you have already downloaded a hacked browser, then you are dead anyway. So along with a browser you should get burned in security for the major vendors. Security that does not rely on anyone that can lie to you.
SSL is dependent on certificates, and the certificate process is deeply flawed. Microsoft in particular seems to be willing to recognize almost any CA, and yet I have trouble with well-recognized root certificates from Verisign working corrrectly with our software, using OpenSSL. Now we hear that most any CA can mint most any certificate.
Perhaps there needs to be a true 'root' CA, and at least some domains subscribed to prevent any other CA from delivering certs?
Gee, this would also be nice in DNS, where 'very well known' domains, such as Google, Microsoft, banks, etc could pay to be put on a 'do not change' list and get a more formalized process for management.
The reality is that we are well past the 'family business' mode the Internet and ICANN et al relied upon to keep things working.
Jon Postel must have shed a tear. There is still a need for collaboration, but it's time some of the Internet infrastructure grew up. Please fix this before the governments do. You won't like their solutions.
deleting the extra space after periods so i can stay relevant, yeah.
Hardcoding anything is a bad idea because it makes it impossible to revoke the certificate in the event it is compromised.
I RTFA, but I don't get why this is marked as Microsoft. There's the odd quote in there from them, but shouldn't this be marked as Security or Internet? Or am I missing something?
Wood Shavings!
- Godai
and I don't particularly like them when they make the 'geek' community look bad - because it's only the bad stuff that tends to make the news - but if a result of this hack is that people (the big companies, the governments, the FOSS people with the good ideas) finally get together and work on a safe, secure and sensible way of carrying out net authentication that DOESN'T rely on me handing over my security credentials to someone else to manage, then it is a good thing in my eyes.
I have a better idea, let's turn anything into a political discussion for no reason!
It was trusted enough when there were about 10 companies that could do the signing. After that, more and more CA's turned up, including governmental CA's. These CA's quickly found out that it is a serious pain in the butt to distribute and install the root certificate to/on the clients computing device. So they went to the major browser vendors and asked to be included.
There have already been interesting goof ups regarding security. Microsoft has had problems for certain, accepting end-entity certs as CA certs for instance, or having a bug overflow in their ASN.1 library (all certs are ASN.1 encoded). As the article said, revocation of certificates is almost never enabled by default. All in all, the default trust-store is becoming more and more problematic.
Personally, I've got the most trouble with the certs of certain governments, I would like to see those restricted to their own domains (e.g. .nl for Dutch CA's), or have them enabled/disabled depending on the location of the computer during install. Ask the user if he wants to trust other installed certificates.
If your DNS is compromised, there are any number of certificate authorities out there who will happilly issue you a domain control validated certificate.
Therefore, using DNSSEC to distribute DNS based SSL keys does not reduce security compared to the existing situation anyway. If your DNS is owned, a forged certificate can be issued either way even through CAs that do their job (which is basically just checking that you're actually in control of the DNS name in question).
Using DNSSEC to distribute DNS based SSL keys sounds like a great way to end the protection racket that is SSL certificates.
Does anyone believe the Monkeysphere project which aims to bring a Web Of Trust model to this problem is a potential –though long-winded– solution ?
With all the talk on the subject lately, I'm surprised not to see Monkeysphere mentioned more often...
No wit here.
"Impossible"? Hardly. He probably means "hardcoded" as in "embedded in the browser's files", not as "embedded in the code". The browser could still have a UI to manage those certificates. And even if there's no UI, it would be possible to revoke the certificate by upgrading the browser.
Agreed the treatment of self-signed certs was just stupid. What they should have done was just taken away the "Secure Page" notification in the URL bar, because the current behavior makes a page that submits credentials in clear seem more trustworthy than pages that use self-signed certs. The behavior should have been if the browser sees a submit of a password type then and there is no encryption then complain every time.
That is what I meant. I should have been more clear.
Instead of the binary nature (it's signed by a CA or it's not) of current certs, how about assigning points to a cert based on how many, and what types of CAs concur as to its authenticity. For example, a cert for amazon.com signed only by government agencies, or only by one CA, could be trusted less than one where amazon.com has proven its identity to, say, Thawte, Verisign, and Comodo. The expense to smaller businesses might be a problem, though.
It's easy to say that in hindsight. I raised this issue 12 years ago in a Slashdot thread about the release of IE 5. Judging by the responses and moderation I received, the general consensus at the time was that I was crazy kook for complaining about the proliferation of trusted CAs.
That would also completely break legitimate MITM proxies and such on corporate networks. At least today you can install you private CA certificate and then everything will just work; of course then its up to the people running the proxy to for the organization to decide who to trust.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
https://blog.torproject.org/blog/life-without-ca Of course, this may be asking too much of most people...
Palm trees and 8
Isn't this exactly what Extended Validation Certificates are supposed to resolve? Only certain validated certificate authorities are allowed to issue them.
Ask the user if he wants to trust other installed certificates.
There's no point in asking a user a security question they don't understand, especially if it has long-lasting subtle consequences. They'll just say "yes" or "no" at random. We saw that with screensaver trojans. We'll see it again here. Any widespread mechanism must not require lots of fiddling around by users; it's got to be as permissive as possible while still being reasonably safe.
"Little does he know, but there is no 'I' in 'Idiot'!"
This sounds an awful lot like the current state of affairs in popular desktop Linux distros -- you get your browser from the respositories, where the packages are signed using a key that belongs to the distro.
Palm trees and 8
That is not good enough, because that is basically what we have today and was proven so insecure in this last attack.
It is simply unacceptable that I have to wait days or even hours for a browser patch to come out when an top-level SSL cert is compromised. Such a compromise should be able to IMMEDIATELY trigger a revocation that takes effect globally.
This is the exact problem that CRLs were supposed to prevent. But they are not implemented very well at all, and nearly always disabled by default in web browsers due to this. The SSL registration system needs to be changed to make real-time validation of certificates mandatory somehow.
You can already create certificates using OpenSSL. And most new browsers (FF4, Chrome) don't pop up giant alarm screens anymore.
But CA certs are cheap enough, you can get on for $9/year. I even got min free with a .com domain.
That simply does not solve any problem; the main problem is with authentication.
Dilbert RSS feed
It is a political discussion when you ask who to trust and who not.
It's not a protection racket. The CAs aren't typically promising that a site is going to be on the up and up, all their promising is that the site is who it says it is. Meaning that they might very well be using your log in information for data mining and whatever illegal activities, but that there isn't a MITM or counterfeit site involved.
You can self sign, but the point of paying is that they're supposed to be doing at least some checking to make sure you are who you claim to be.
The irony is that browsers like Firefox & Chrome make a big song and dance of not using a patented video codec, and yet here is a security model which arguably has had a far more chilling effect on the internet.
Firefox et al, really should offer a way for sites to issue their own certs. Not a self signed cert, but a cert that implements a web of trust. The obvious way would be to allow an SSL cert to be signed by a PGP key. When the browser encounters such a cert it fetches the web of trust from a PGP key server and displays that to the user. If the user says they trust the site, their choice is stored in a list which is used for future reference. It could be seen as a kind of key which sits between self-signed and CA signed.
Only implementing encryption is largely worthless. An encrypted connection with an unknown endpoint is no different to an unencrypted one. The guy next to you in the coffee shop whose machine replied to your DNS request with his IP faster than the real DNS server will look (to your browser) just like the host that you were expecting to connect to. You'll end up with a secure connection to the attacker, but that's not really any better than an insecure connection to the attacker.
I am TheRaven on Soylent News
Unfortunately, letting people decide whom they do and do not trust is also a non-starter. Or it's a good, optional measure, but it cannot be a default step.
Unfortunately, this is the ONLY possible option in the end. Everything else is a stopgap attempt at "solving" the problem that people can't/won't/aren't aware of the need to do this effectively.
In reality verisign and thawte issued all certificates I care about. Why I'd need any others, I do not know, but still there are scores of CA's in my browsers.
You really think that they can't unknowingly issue fraudulent certs? What rock have you been living under?
Educate people. Give them the tools they need to use systems intelligently - make it as easy as humanly possible. But at some point, you need to take the training wheels off.
The rest of your comments are fairly political and out of this discussion's scope. (I mention this only b/c I hate when I make a detailed reply and the respondent picks and chooses the parts he wants to reply to --while ignoring those he has no answer for. I'm not ignoring the rest of your post, it's just not relevant to the discussion here. )
It all comes down to who watches the watchmen.
I don't even trust myself, so how am I going to trust a CA?
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Ask the user if he wants to trust other installed certificates.
There's no point in asking a user a security question they don't understand, especially if it has long-lasting subtle consequences. They'll just say "yes" or "no" at random. We saw that with screensaver trojans. We'll see it again here. Any widespread mechanism must not require lots of fiddling around by users; it's got to be as permissive as possible while still being reasonably safe.
The only way to code a technically perfect solution that obviates the need for a brain is to also code the technically perfect user. That said, asking the user that particular question is a bad plan as you said - it's meaningless to the user. Especially if they accidentally click "no" and then don't understand why nothing works.
Our current approach of trying to solve it technologically (via CAs, anti-malware when we're speaking more generally, and other tools) is in large part WHY most users are so unable to comprehend the problem. We give the users tools and say "with these tools you are Safe, so long as you always use these tools". Examples: firewall clients, antivirus software, and "if the icon is blue, then it's safe to use the site". Then we wonder why they don't believe it when they see something that says they're NOT safe.
I've run against that too often. "But I have antivirus, and it says I'm up to date." "My antivirus scanned that email, so the link it includes is OK."
There needs to be a massive effort to educate users on why this stuff is important, and the risks associated with ignoring it. It's a long process, and it requires making people AWARE of security -- and aware that installing the latest AV updates doesn't make them secure. (Of course, the AV vendors will continue to sell their false security, which is a serious hindrance.) THEN you can proceed with a solution that requires the user to use his brain and make a decision. But it's critical that they be trained out automatically clicking the "get me past this annoying screen so I can see my bunnies" button.
"Impossible"? Hardly. He probably means "hardcoded" as in "embedded in the browser's files", not as "embedded in the code". The browser could still have a UI to manage those certificates. And even if there's no UI, it would be possible to revoke the certificate by upgrading the browser.
You know that's ... um, no different that putting in the code, right? If you have to deploy a product to the user, putting it in the code is identical to putting it in a file that you distribute with the code.
OK, so we have the geeks looking for the padlock, checking the certificate fields out and so on and so forth.
Except most of the public isn't doing that. I ran across a pharmacy site that says in clear text that "256-bit encryption is use" but there is no padlock and the URL says http:. This is on a shopping cart page that is prompting for a credit card number! They have all the right Verisign seals that link to nice pages that say their site is secure. But there is no security. No SSL. Nothing.
Of course, there probably are CAs that will issue certificates to fake pharmaceutical distributors - you know, little blue sugar pills for $2 each - but it is much simpler to just bypass that whole thing and say your site is secure. They are raking in millions of dollars doing this so it is clear that most people aren't checking.
If sites are getting away with this, I'd say that is a much, much bigger problem that trying to secure SSL against folks.
It was trusted enough when there were about 10 companies that could do the signing. After that, more and more CA's turned up, including governmental CA's.
A really big failing is that CA's lack any sense of scope. A governmental CA is probably actually the best entity of verify a business within it's jurisdiction. But can't do so for anywhere else in the world. Thus you really don't want New York City trying to tell you anything about companies outside that city.
Nor does it make sense for commercial CA's to be dealing with anything more than X distance from where they actually have offices.
Since Comodo appear to have no offices in the Southern Hemisphere they probably arn't going to be much use about a business in Aukland. Yet I doubt most browsers would complain about a site with a Comodo issued certificate claiming to be from Air New Zealand.
That is something I want too.
Restrict a CA to a domain-list.
Possible have an option for: ask to add domain to list.
But it only works for technical users. No noob will understand this, so it isn't a real solution.
New things are always on the horizon
What I'd prefer to see are the following:
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
You mean like http://www.startssl.com/ already does this ? For free for the current CA-system.
New things are always on the horizon
This just isn't true.
An unencrypted connection can be attacked at any point in time. A encrypted but unauthenticated connection can only be attacked while it is being set up.
And it isn't even possible for an attacker to tell when it is transparent to attack the key exchange and when the browser actually has the certificate or a plugin to warn that the certificate has changed.
Encrypted connections prevent passive eavesdroppers and force attackers to use active attacks which are detectable if you care enough to want to detect them.
Tim.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
I agree at least with both. Because in neither proposition do you suggest trying to protect the user in any way or otherwise make them feel secure. And your part of the answer is not incompatible with my own.
You can increase your SSL security today by using Perspectives.
It tells you if others are seeing the same cert you're getting from a website. So it protects against MITM attacks.
This could be combined with DNSSEC, just list the hashes in DNS. That way both DNS and the key itself have to be compromised.
The right to protest the State is more sacred than the State.
I love how everyone in here talks about "Web of Trust", but this is making HUGE assumptions on the end user's part:
A) They know what they're looking at.
B) They know what they're looking for.
This is a big problem that nobody's recommendation here has seemed to have overcome. You all just assume that they can talk to the bank and know exactly what they're looking for. Like any of you validate your RDP certificates (Windows) or ssh public keys (*nix) when you connect for the first time, seriously? If you do that, you have way too much time on your hands.
The only solution to this that seems sensible is either two-factor authentication via a challenge system, something added to DNSSEC to extend on the authenticity, or as some mentioned in here to have the browser check with multiple CAs. But good luck making someone pay for 2+ signatures to their certificate.
That sounds like something a pinko commie would say. Why do you hate America?
Random Thoughts From A Diseased Mind (Not For Dummies)
I think the lowest-hanging fruit is to sandbox the various CA's to certain domains. The Tunisian gov't shouldn't be able to make certs for paypal.com. They should probably only be making certs for *.tn, so why not have the browsers enforce this? Have the browsers only trust Verisign and the big DNS registrars for .com certs... etc.
I realize that this is a really low-tech fix, and it doesn't go far enough to really solve the problem completely. I also realize that there's a lot of political hand-wringing to be done over which CA's get trusted for domain ".xyz", and there's going to be a lot of whining and bellyaching from the small players who get sandboxed to a small subset of domains. But the advantage is that it doesn't require that users or webmasters out there change their certs or implement DNSSEC or whatever. Basically, all of the browser developers could implement this in their next release... quite easily, too.
You are absolutely correct. It would not be hard to add a new record type.
A thought for you: http://www.isc.org/software/bind10
ISC are wanting suggestions for what is needed in BIND10, the essentially de-facto DNS server. You might want to put your thoughts together as a single white paper on integrated security and send it to them. You aren't getting much mileage on Slashdot, but you might well provoke some excellent thinking by the people who actually develop DNSSEC and the servers that use it.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
I largely agree with you there, this would indeed only benefit the people that know PKI (and there aren't that many of them, as I can attest after debugging an interface to a certificate authority service for a couple of days). People should, if possible, only see any feedback if something is really good (green highly trusted cert), or really wrong (spoofed or broken server certificate).
i cant quite grasp the idea, wikipedia isnt very clear, just lengthy and consently switching sides and only seem to get a vague idea across.
mind explaining the reasons behind it?
warning pointless sig