Google: SSL alternative won't be added to Chrome Still smarting from a counterfeit secure sockets layer certificate that threatened at least 300,000 of its users in Iran, Google has no plans to fortify its Chrome browser with an experimental technology that bypasses the current system for validating websites. In a blog post published Wednesday, Google security researcher Adam …
The proposal is intended to address the particular problem of securing SSL from man-in-the-middle attacks where the attacker has obtained a trusted certificate. For this limited but important purpose, it is an alternative to the conventional Public Key Infrastructure of hierarchical trust via certificates. The approach seems similar to the Perspectives add-on for Firefox which has been available for a year or more.
This post has been deleted by its author
It is best to look each up on the addons.mozilla.org site; I use both. Certificate Patrol monitors and controls certificate changes, and announces changes that look funny. Getting a user to accept a certificate for the attacker is how MITM attacks penetrate SSL security.
Perspectives monitors IP address values across time and location. A range of different notaries each testify as to the IP they see for the SSL URL, which means an MITM attack must somehow intercept all connections for the URL, not just that going to the targeted user. Also, the IP values seem to be kept for about a month; to not be detected, the MITM attack must be first accepted, then kept in place for a long time. All of this raises the security bar in general, and probably exceeds what can be delivered in the usual coffee-shop MITM SSL attack.
If you enable DNSSEC, and a miscreant hijacks your data stream (dns, https, icmp, etc...) and is good enough to set up a fake dns and website, don't you think they'd be able to forge DNSSEC records as well? The only way I see to defeat this attack is to cache everything, which gives you problems every time an object expires, and compare current to cache every time.
if an attacker so 0wns your network that they control DNS and can MITM all traffic, you're basically screwed. but this doesn't mean you need to cache everything - just the root certs. and those should be updated via your OS's standard update mechanism (after all, you have to trust them just as much as you have to trust your kernel, tcp stack, etc)
this is really the way it should always have been - separating ssl from domain mechanisms was just a historic oddity.
the big change here is that the current nasty, parasitic SSL-cert industry goes away. lots of them won't be happy. no customers will regret this though.
Even just securely promulgating which CA is allowed to sign for your domain, or host, would be a very good idea.
One of the good ideas in Globus' security infrastructure was to put limits on what X509 certificate subjects a CA could sign for. This was fine for grid computing, because all the big labs had their own CAs in any case, so they signed certs for their own machines and users. Bit more of a drag for grid computing in Australia, where there were very few trusted CAs; and the big kicker was, the signing authority was part of the certificate for each CA that was included in the trusted CA bundle with a Globus installation.
No commercial CA will ever agree to such a measure, because they want to sell certificates to anyone, anywhere. Instead, this should be done by the people who *buy* SSL certificates, now that DNSSEC could allow this signing authority to be devolved back to the people who control a domain. Sure, include a trusted list of CAs in browsers, but then have a DNSSEC secured DNS record that states who is allowed to be the CA for a given domain or host. Then, your exposure to certificate fraud is only to whoever you choose to get your SSL certs from, not to the crappiest CA that managed to pass auditing and end up in your browser's trusted CA list.
Frankly, this default "we're so special that we deserve to be trusted to issue certs for every web site in the world" assertion from all the CAs is offensive. Google just sidesteps the whole issue by implementing a signing authority style policy for all their own sites within Chrome. Any rogue cert from a non-blessed CA for a Google web site will be detected straight away by Chrome.
This should actually become a fundamental requirement for all SSL implementations. They already use DNS names as part of the certificate subject - it wouldn't be a disaster for SSL/TLS to rely more explicitly on DNSSEC to retrieve signing authorities.
"This should actually become a fundamental requirement for all SSL implementations. They already use DNS names as part of the certificate subject - it wouldn't be a disaster for SSL/TLS to rely more explicitly on DNSSEC to retrieve signing authorities."
is there a concrete proposal floated somewhere?
The whole point of DNSSEC is that it *can't* be hijacked (for a given value of can't!)
I suggest you have a read up here: http://www.dnssec.net/ In theory your DNS resolver would stop your browser from going to an invalid site.
Basically the root servers tells you that .uk is signed, .uk tells you that .co.uk is signed, .co.uk tells you that example.co.uk is signed. example.co.uk's DNS is thus verifiable The trust bit starts at the top and provided your resolver has a copy of the public keys for root, the chain runs down to the bottom - ie the DNS record that your browser is presented with. A failure in the chain would cause your browser to fail to connect to anything.
However this assumes that your resolver supports DNSSEC records and that you can do your own recursive look ups and that zones are signed.
I personally run a BIND daemon on my laptop but that's a bit excessive for most people as is the OpenVPN tunnel back to the office down which the daemon gets its forwarders. If its fast enough I use the office web proxy as well.
So if you can trust your DNS queries and an SSL cert fails to compare with a DNS record then you could use that to put up a warning that most people will click through anyway 8(
Based on your explanation, doesn't this mean It's reliance on the root server means if your DNS itself was redirected to a alt root. Everything falls apart as they do now?
The Alt Root would fake DNSSEC from the top down. No reason why governments with unlimited resources can't do that.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
