Weekly Edition
Return to the Security page
| |||||||||||||
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica)Over at Ars Technica, Dan Goodin writes about Trust Assertions for Certificate Keys (TACK), a proposed extension to SSL/TLS designed to discover fake certificates before they are accepted. "The opt-in system works by allowing SSL sites to sign valid SSL certificates, the domain name, and an expiration date with a TACK key. Once an end user has visited the site a few times using a TACK-compatible browser, a 'pin' for that site is activated on the user's computer. If the end user later encounters a forged certificate for that same site—as was the case when DigiNotar was breached—the browser will reject the session and return a warning to the user." One of TACK's co-creators is Moxie Marlinspike, who proposed the Convergence alternative certificate-management framework in 2011. (Log in to post comments)
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 24, 2012 15:20 UTC (Thu) by epa (subscriber, #39769) [Link] Sounds great. And it would partially solve the SSL stupid warning problem (to recap: browser shows a scary warning for https with self-signed certificate, but no warning at all for plain http, which is at least equally unsecure) by allowing an intermediate security level where the browser just checks that the certificate presented is signed in the same way as on previous visits.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 24, 2012 15:27 UTC (Thu) by ajross (subscriber, #4563) [Link]
Also: best alliterative tech headline I've seen in a good long while. Someone had fun with that one.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 24, 2012 17:26 UTC (Thu) by proski (subscriber, #104) [Link]
I kept misreading "fix flags" as "six flags" until I checked the story and read its title in a different font.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 24, 2012 16:50 UTC (Thu) by jwarnica (subscriber, #27492) [Link]
Not sure why this requires any effort on the TLS spec, at all. Just deal with keys exactly the same way as SSH does. Its time to kill off the CA-centric system, not add to the insanity.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 24, 2012 16:59 UTC (Thu) by randomguy3 (subscriber, #71063) [Link]
The problem is that the SSH scheme doesn't scale so well. It assumes you have a way of checking the server keys for the first time you connect - not unreasonable for SSH's use-case. CAs provide third-party assurance that those keys are correct. TACK+CA seems to be way of getting the best of both worlds.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 24, 2012 17:08 UTC (Thu) by jwarnica (subscriber, #27492) [Link]
Except that CAs don't provide any level of assurance, they never had, even when working "as designed". And CAs a are frequently successfully attacked, even if you do trust their "verification" processes.
In the real world, SSH is free, works, and is successful in replacing insecure predecessors. In the real world CA based solutions are expensive, troublesome, don't actually provide any assurances, are directly broken frequently, and have replaced only very select communications.
CA+automatic pinning, always. That would also provide something better, and not give CAs and opportunity to upsell you on adding this flag.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 24, 2012 17:39 UTC (Thu) by clint (subscriber, #7076) [Link]
With an OpenPGP-style scheme, you could accumulate as many useless third-party certifications as you'd want.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 24, 2012 19:32 UTC (Thu) by tialaramex (subscriber, #21167) [Link]
SSH already has a standardised DNS record for this problem. RFC 4255's SSHFP
A recent-ish Fedora with a local caching DNSSEC configuration, plus a recent-ish OpenSSH with the config set to allow this method of verification gets you the ability to securely authenticate a remote host via SSHFP. No prior contact between you and the server or its administrator is needed.
Since you are using ssh to connect to a hostname, which spells out the hierarchy, it's very easy to understand who you're trusting. If you SSH to foo.example.org for example, you must trust the DNS root, the org registry and the people running example.org (on top of the OpenSSH coders, your distribution's packagers, and the people with 'root' on your machine who you'd have to trust for any method).
This is a huge improvement over the opaque situation with SSL CAs today.
SSHFP Posted May 24, 2012 20:37 UTC (Thu) by robbe (guest, #16131) [Link]
It requires DNSSEC on the server side, which is still not that easy to set up. At least compared to setting up ssh, which any dummy can do.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 25, 2012 22:27 UTC (Fri) by Lennie (subscriber, #49641) [Link]
DNSSEC is similar to an one-CA system and thus doesn't satisfy what a lot of people want.
Obviously, without the domainname I think most people wouldn't visit your site anyway (not even if it is listed in a search engine).
As I see it DNS is already similar to an one-CA system of which parts are controlled by different organisations and governments.
I don't expect anyone outside of the root server operaters to have real power over what goes into the root.
Although now with DNSSEC signed, I wonder what they would do when the keys are gonna expire and they don't want to publish the content they've been given. Would they let the keys expire ?
Currently probably yes, but what if things start to depend on it as the new CA-system for example ?
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 25, 2012 22:45 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]
Incorrect. DNSSEC is _hierarchical_ unlike SSL CAs.
I.e. you have one DNSSEC root and a lot of other entities maintaining security of subdomains. And what's good, upper levels of hierarchy do not control lower levels directly.
So you can create a subdomain in .se zone and in practice you'll only need to trust your DNS registrar and .se zone operators. There's no practical way for The Evil Government to subvert your trust chain except by forcing your registrar to create fake records in its zone.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 25, 2012 22:53 UTC (Fri) by Lennie (subscriber, #49641) [Link]
There currently is nothing stopping the root from removing .se or taking over .se completely with new nameservers (and removing DNSSEC or replacing it with a new DNSSEC key).
That way they can publish anything at .se they want including everything which is currently at .se (even signed with a new DNSSEC key) ;-)
Obviously this would be noticed, but there is no technical limit which would prevents this.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 26, 2012 11:16 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]
>There currently is nothing stopping the root from removing .se or taking over .se completely with new nameservers (and removing DNSSEC or replacing it with a new DNSSEC key).
I've specifically said that there are no _practical_ attacks. Completely taking over a domain of a sovereign state is not practical and it won't be covert.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 26, 2012 11:29 UTC (Sat) by Lennie (subscriber, #49641) [Link]
We agree, I was just mentioning there is no technical barrier.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 26, 2012 0:01 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
"doesn't satisfy what a lot of people want"
No, not a lot of people. A handful of people, like Moxie, who seemingly have no idea about usability and over-estimate both their own understanding of the cryptography they'd be relying upon and the general public's level of interest in this technology.
We tried listening to people like this _last time_ and the present CA disaster is what we got for our trouble. All the posturing about individuals being empowered to make their own trust decisions ended up with the reality that _everyone_ (near as makes no difference) delegates that decision to a handful of browser makers who in turn trust anybody willing to put their signature to a bullet list of prevarications, optimism and outright lies.
As a result of this delegation there will be a central authority anyway, so we should make it one we more or less have to trust anyway, and one that is obliged to operate out in the open where malfeasance will be noticed almost immediately and punished severely. That's unlike _every SSL CA which now exists or has been proposed_ but it's exactly what DNSSEC does.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 26, 2012 0:15 UTC (Sat) by Lennie (subscriber, #49641) [Link]
I do think Moxie understands usability though, this TACKS/pinning proposal proves it. Most of it works automatically (on the client).
Although I have to admit, as an admin an other set of keys to manage isn't a lot of fun (DNSSEC, TACS, SSL-cert).
Personally I think having DNSSEC is a big improvement already, it can be used to put a hash of the cert of your site in DNS signed by DNSSEC. If properly done, this will prevent other CA's from signing the wrong cert.
You can even go the DANE route and not even involve a CA. Obviously that last bit isn't very compatible with the current system (read: deployed browsers).
Even if that becomes common practice, CA-certs would still be needed for the Extended Validation certs (green addressbar). DANE or similair can help them be more secure by preventing other CA's from signing the wrong certs.
But DNSSEC still has some deployment problems, there are to many places where DNSSEC currently doesn't work (yet). A good fallback like Google Public DNS servers over HTTP would solve that.
And we'll probably get a DNSSEC-validator in every OS and probably even browser before it can be used for other protocols.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted Jun 1, 2012 4:04 UTC (Fri) by draco (subscriber, #1792) [Link]
I can't tell if you're aware of this or not from your comment, but DANE gives you a choice between using a CA-signed certificate or a self-signed certificate. So you can stay compatible with the existing CA system and still authenticate the cert you're using via DNSSEC. That way clients unaware of DANE work correctly, and clients aware of DANE know they're using your real certificate.
Or, if you're the type that uses self-signed certificates, DANE-aware clients can tell that the certificate is yours and not a MITM.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted Jun 1, 2012 10:15 UTC (Fri) by Lennie (subscriber, #49641) [Link]
Actually, I am very much aware.
It was something I was trying to explain, but English isn't my native tongue, so maybe that is the cause of the confusion.
With DANE you have 3 possibilities:
- cert-information in DNS (validatable with DNSSEC) which says: only this/these cert(s) are used for this site.
- non-CA-cert in DNS (validatable with DNSSEC), DNSSEC-only certificate. Which is not backwardcompatible with the current situation.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted Jun 1, 2012 10:24 UTC (Fri) by Lennie (subscriber, #49641) [Link]
Correction, the RFC actually has 4 types:
0 CA constraint
http://tools.ietf.org/html/draft-ietf-dane-protocol-21
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 25, 2012 11:19 UTC (Fri) by guillomovitch (subscriber, #58314) [Link]
If I understand correctly the proposal, there would be now way to distinguish a server certificate change for legitimate reason (such as loss of the original key after a crash) from a man-in-the-middle attack. Which means than certificate renewal after expiration should be handled with specific care, for instance: you can not just replace the current certificate/key pair, you have to resign again the same certificate.
SSL fix flags forged certificates before they're accepted by browsers (Ars Technica) Posted May 26, 2012 9:57 UTC (Sat) by Lennie (subscriber, #49641) [Link]
And the important part is the TACS private key can (and should !) be kept somewhere else than on the server(s). Where it can't be compromised the same way as the server certificate/private key.
|
|||||||||||||