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.
It looks about as secure as a screen door.
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.
Free certificates for HTTPS that only implement encryption (not authentication) and don't pop up a giant alarm screen.
I have a better idea, let's turn anything into a political discussion for no reason!
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.
I'm down with that. Now let's talk about my proposal for an anarcho-syndicalist commune. For instance, you should the temporary executive be selected, and how should we ratify his decisions?
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.
That is what I meant. I should have been more clear.
secret mystery of god providing aimlessly? seems as though our rulers get them by default, then, arm the (soon to be) armless/lifeless? yikes. whois in charge of all this madness?
oppressed pop. worldwide receiving arms shipments
many of the newer subscription issues include the even newer miraclemorph prosthetic devices, so that the advanced weapons may be operated by the armless of every discipline, race, motive etc... being fair to all is truly disarming.
censored? chariots? honestly?
Due to excessive bad posting from this IP or Subnet, anonymous comment posting has temporarily been disabled. You can still login to post. However, if bad posting continues from your IP or Subnet that privilege could be revoked as well. If it's you, consider this a chance to sit in the timeout corner or login and improve your posting. If it's someone else, this is a chance to hunt them down. If you think this is unfair, please email moderation@slashdot.org with your MD5'd IPID and SubnetID, which are "blah blah blah
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.
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.
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
DNS Bindings for SSL certificates
Here's how it would work:
Every SSL certificate has a unique SHA1 ID and issuing CA
I suggest we have signed DNS records like this:
web.example.com. 86400 IN A 192.0.0.1
_https._tcp.www.example.com 86400 IN SRV 10 10 443 web.example.com.
_https._tcp.example.com 86400 IN SRV 10 10 443 web.example.com.
_https._tcp.example.com. 604800 IN TXT "v=tls3 subject="/CN=example.com/O=Example Organization/OU=Example OU" issuer="/C=US/ST=xxxxxxx/L=xxxxxxxxx/O=ca.example.com/serialNumber=xxxxxxxxx" ocsp=http://ocsp.ca.example.com/xxxxxx ciphers=aes256, sha1=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX"
_https._tcp.example.com. 604800 IN TXT "v=ssl_cross_domain_inclusion +https://subdomain.example.com/* +http://images.example.com/* -all"
_https._tcp.www.example.com. 604800 IN TXT "v=tls3 subject="/CN=example.com/O=Example Organization/OU=Example OU" issuer="/C=US/ST=xxxxxxx/L=xxxxxxxxx/O=ca.example.com/serialNumber=xxxxxxxxx" ocsp=http://ocsp.ca.example.com/xxxxxx ciphers=aes256, sha1=XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX"
_https._tcp.www.example.com. 604800 IN TXT "v=ssl_cross_domain_inclusion +https://s
And in addition to having certs signed by a CA, the browser should verify the DNS records. There should also be an attribute on the CA or the certificate indicating that use of the cert will fail if the DNS record is not present.
Also, as long as DNSSEC is used, "self-signed certificates" are no longer bad. So long as the proper DNS records are in place
While I agree that it is bad in principle to give up the redundancy of having a domain trust chain and a SSL-CA trust chain, in reality this merge has long been completed, and not with DNSSEC but plain DNS! You can already get SSL certificates for any domain where you can receive mail to a list of a few "special" local parts. In conclusion, SSL already doesn't protect against an attacker who controls a domain. All the SSL-CAs add on top is another bill. They have of course realized that their lax identity checking has made them superfluous, so now they offer extended validation certificates, where they actually check who is asking for a certificate - i.e. what they should have been doing all along. There's still room for that: You can add signatures of CAs to the DNS-supplied keys and verify them against a CA based trust chain in addition to the DNSSEC based trust chain. Plain SSL certificates, which just certify that someone in control of the domain had the key signed by a CA, can be replaced by plain DNSSEC based SSL keys without losing any security.
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.
So then what happens when a major site gets compromised? Every end user has to manually install a new cert? How does a user know when the proper time to do this is? How do you stop a malicious piece of code from simulating that proper time and convincing unknowing users to install bad certs? Particularly after the first time a major cert gets compromised and every person on the planet learns "Ok, when a site stops working, I just click that button to put a new certificate thingy in". Relying on end users to make judgements about certificates on their own is about the only thing that would be worse than the current situation of allowing dozens of CAs to do it. If it requires a browser update, then it's 100% the same as the current situation, although at least in the current situation we have a legit mechanism for real time revocation, unfortunately it's not really used.
there's something wrong about calling a proxy designed
to be a MITM as "legit". if we make compromises for
"legit" MITM proxies, how do we prevent the bad guys
from using the same feature?
It is a political discussion when you ask who to trust and who not.
Hey dumbass, he gave you the answer in his statement.
Don't install the CAs.
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.
I really do not understand why the major browser and OS distributions still have Comodo listed as trusted root.
Problem is not that they have been hacked: problem is that their Italian subsidiary (which is NOT a partner, is themselves) had username/password gtadmin/globaltrust for an administrative access to the certificate signing interface, that tehse credentials were hard-coded in a DLL, that this DLL was parked on a windows PC open like a clamshell on a grill.
When we use SSL we trust the distributors to insert only root certificates handled by people with a minimal (decent?) level of technical skill with some responsibility in security matters: these folks proved to not being able to secure even the PIN of their ATM card. WHY should we trust them anymore ?
WHY, beginning in example with Firefox, the Comodo roots haven't been removed yet ? Yes this would mean having Comodo close down: that's called natural selection (and might be a lesson to other root autorities to go back and study at least the basics of 17799 at least...).
The above are not random claims: http://pastebin.com/74KXCaEZ
You can check on several sources that the claims done by the guy posting that information are correct (he showed the private keys corresponding to the hacked certificates as signed by Comodo).
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.
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. )
While I admire your intent to get rid of the middle men, my banks are the last people I would trust to inject an application of any sort into my computer.
I do like the idea of QR codes (or just easily OCRd digits) on a bank statement or new-account paperwork, which could be scanned with the software of my choice rather than theirs. On the other hand, with the way they outsource so much activity now, I also need to remember not to trust any of the official communication paths too much either. Defense in depth unfortunately requires suspicion in depth.
"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.
Nice site you have there. It would be a shame if its SSL certificate expired, throwing up huge certificate warnings in the face of your potential customers, leading them to belive that your site is less secure than a regular HTTP unencrypted site.
How is that not a protection racket? :-) I see paying for a commercial cert as little more than paying to get the web browser on the other end to shut up. Security doesn't enter into it.
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.
MS and Intel want to hardcode certs on chips in all computers, making them require a "license" to go online, which isn't very fair, is it.
The whole problem is that Comodo allow "resellers" to sign certificates under their root key (without using an intermediate certificate).
This means that browser manufacturers who declare Comodo as a CA that is to be trusted, in fact assign trust to a completey unmonitored authority.
(because it does allow others, who are not well monitored, access to its trusted root key)
Of course instantssl.it should be immediately removed from the trusted CA list, but it cannot be done because it is not on it.
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 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 really think that they can't unknowingly issue fraudulent certs? What rock have you been living under?
Of course, but 2 issuers of fraudulent certs is better than 200.
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've used Perspectives (produced by a security research group at CMU) but I have a few beefs about the way the FF extension is maintained. They don't seem to be taking it seriously enough for something touching on security and privacy.
If you pull up FF's add-ons list and search on "certificate" or "ssl" Perspectives doesn't even come up. That's very minor in itself, but it's like nobody is home.
Much more serious is the lack of a change log for updates. I never update *any* extension without looking at the change log, and you want me to hand my privacy to this thing?
When I go to install it, FF says "author not verified". For a security add-on -- are you kidding me?
But the worst thing of all is that I'm not sure I can trust the notary concept for certain kinds of possible attacks. To give an example, AOL webmail doesn't use https to protect its full session, but AOL's webmail beta does. When their old certificate expired and they switched to a new one, Perspectives rightly pointed out a problem with it (like mismatched assignment information, webmail.aol.com instead of beta.aol.com or something like that). After a few days Perspectives stopped pointing out the error -- not because it was fixed or because I had made an exception, but apparently because enough other users had decided to trust it and so the notaries blindly passed that trust on.
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
Well,
point is that a) instantssl.it *IS* Comodo, it's Comodo Italia, a subsidiary of Comodo; and b) that even if it was not still the compromised certificates were signed using Comodo's root certificate.
whois instantssl.it:
Registrant
Name: Michael Whittam
Organization: Comodo CA Ltd.
ContactID: NICE4900