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

Comments

Implement DNSSEC and DNS based SSL keys

[Anonymous Coward]

With DNSSEC and DNS based SSL keys, only the single trust chain from the root to the domain can sign the keys.

Maybe the browsers should hardcode the major certs

[Marrow]

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.

Perhaps we need to validate the CAs?

[rickb928]

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.

Re:Perhaps we need to validate the CAs?

[inKubus]

What we need is a way for people to get the keys straight from each other without having intermediate signing authorities, as much as possible. Example, your bank most likely has a secure, brick and mortar branch in your town or near you. So, you could simply go to the branch office and they give you the cert and you install it on your browser, problem solved. The issue is that this is beyond most people's abilities. However, I posit that if you use something like a QR code or multiple QR codes to hold the cert, then people just shoot it with their phone and when they get back they plug their phone into their computer and it updates the certs.

Re:Perhaps we need to validate the CAs?

[CastrTroy]

That kind of exists anyway. When I go to buy something, I'll often just buy from Amazon because I have experience with them, and know they will get it shipped out on time, and that they have a good return policy, or any other number of factors. I usually don't buy from somebody who just happens to have the lowest price, because there are a whole lot of other things to consider. Maybe more of the smaller retailers would have to adopt something like PayPal so that I don't have to trust the site directly, and then I could just trust PayPal.

Little anecdote, My university professor who was quite knowledgable in the area of of SSL and other related matters said that SSL addresses the wrong problem. The problem generally isn't somebody sniffing your credit card number as it travels over the ether, but rather that you shouldn't have to give your actual credit card number to the retailer in the first place. That way, I don't have to worry about how secure the retailer's operation is. It should work kind of like OpenID, where I log into "VISA" for instance, and authorize a one time payment from my account to the retailer. The retailer doesn't get any of my credit card information, but instead gets a certificate with an authorization number signed by my credit card company that the payment was valid. Paypal pretty much solves this problem, but it is still a third party. The credit card companies should maintain this system on their own, so that no third party has access to this information.

Re:Maybe the browsers should hardcode the major ce

[brunes69]

Hardcoding anything is a bad idea because it makes it impossible to revoke the certificate in the event it is compromised.

Re:Give all the keys to the king !

[Anonymous Coward]

I have a better idea, let's turn anything into a political discussion for no reason!

Re:How could it have ever been trusted?

[owlstead]

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.

Re:Maybe the browsers should hardcode the major ce

[Anonymous Coward]

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

Re:One thing we could use in web browsers

[jgtg32a]

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.

How about a "degree of trust?"

[e9th]

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.

Re:Don't trust CAs at all

[icebraining]

I do the same. I haven't asked my bank to provide me with their fingerprint, but I did check it on multiple machine using multiple connections (laptop at home, phone at public wifi, desktop at university).

For most sites, the first access is irrelevant - I haven't registered, so I don't have anything to protect. I just care to ensure that subsequent accesses are made to the same machines, and not trusting CAs is actually better for that purpose.

Re:Good

[jd]

In the meantime, I'm using a plugin tha shows the AS of the network I'm connecting to. It certainly doesn't solve the problem, but for right now I can differentiate between a site in the US and a site in Iran that may be claiming to be the same machine. It's pretty weak, as AS numbers aren't enforceable, but unless someone sets up scam sites on different autonomous networks and ensures said networks match the US versions, it provides some basic protection. (Besides, 99.9% of the planet wouldn't know what an autonomous system number was and wouldn't care if they did, and any fake site will be set up for the greatest number of victims rather than the best camoflage.)

Re:Good

[jd]

Links to other software dealing with the Internet Routing Registry system (some are also given elsewhere):

IRR Toolset: http://www.isc.org/software/irrtoolset
IRRd: http://www.irrd.net/
Routing Registry Consistency Check (a web form, not the source code - pity): http://www.ripe.net/data-tools/projects/current/rrcc

If you want to use this system to construct your own WHOIS database, please see:

ftp://ftp.ripe.net/ripe/dbase/software/

(This is the WHOIS server used by RIPE.)