Slashdot Mirror
Can We Fix SSL Certification?
Em Adespoton writes "At DEFCON this year, Moxie Marlinspike gave an excellent presentation showing how broken the current SSL certification model is and proposing a replacement. Naked Security adds to the issue, asking: does it even matter if you can trust your certificate notaries?"
I've got a great idea. How about we let the government verify both ends of the connection for us so we are assured that no man-in-the-middle attack can take place? Surely that will alleviate any problems, right?
And how do you know the signature is the signature of the domain's owner?
Man, what's happening with you? Your comments are usually nice, but lately they are just too aggressive or troll-like. Are you getting enough sleep?
I rarely respond to comments. Also, don't ask for clarifications: a brain and Google are faster, believe me!
Wouldn't it be possible to verify the certificates via the DNS? Once that is secured with DNSSEC, this should be a very good solution. Or am I missing something?
Do you have a solution for MITM attacks? No? Well then.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
There is exactly one way for SSL certification to be fixed, and that's for browser makers to grow a pair and stop trusting root CAs who do not enforce strict rules for identifiability on all the lesser CAs under them.
Right. CA's are supposed to be financially liable if they issue a cert to a party other than the one they're certifying. Part of the problem is that CAs get to write their own "relying party agreements". We need a tough, standard relying party agreement with a minimum guaranteed liability to get into a browser's approved root cert list.
Once in a while a CA will slip up. Then they pay. That keeps them honest. A CA is an insurance company, and should be regulated as such.
You do need someone to verify the domain first time you access it unless you have some means of verifying it yourself. Otherwise you don't know that the server you are sending encrypted data to is the server you think it is. Without some form of verification (what we have now, broken as it is becoming, or some replacement system that is at least no more broken) anyone could create a server pretending to be amazon.com or yourbank.com, create a certificate saying that the server is the real one. All that is needed then is a DNS poisoning attack or other such and the data that you are sending is all nice and safely encrypted all the way to a server that you don't want to send it to. Now the owners of that pretend server can use you data to gain access to your accounts on the real servers and so forth.
Some verification system is absolutely required, so until something better is proposed, designed, implemented, tested and widely available we can't just drop the system we have now.
Must have missed the part that actually proposes a replacement. Article disses DNSSEC (probably rightly) as being just more complicated than SSL/TLS , but not really any better architecturally.
Seems SSL/TLS does the job pretty well for what it does, at least from an architecture standpoint, it is just a shame that browsers only recognize (by default) only certain trusted certificate authorities, which introduces a third "trusted" party into your two-party communications.
Cutting out the third party (or parties) trust hierarchy would leave you vulnerable to man in the middle attacks, so it is hard to see a way around certificate authorities or something basically identical. DNSSEC, might make sense from the perspective of the same companies providing dns also providing a inline method of verifying that the name of the host matches the certificate and distributing that over the existing DNS infrastructure. Assuming some hierarchy of trusted DNS. But really this would be more of a process improvement, for one stop shopping for DNS and certificates with perhaps some distributedness of the actual certificates to make it a bit more resilient, than anything else more fundamental.
Is SSL/TLS really broken in a way that can be fixed? Or is it the nature of the problem that is the problem?
It would be great to have SSL fixed but it won't happen. The reasons are (same as Flash, HTML5 and Java, IPV6):
1) has a monetary interest in the technology
2) The public/private sectors have adopted this as defacto standard
3) Haters hate change in the name of "secure"
The only way to change this is to implement a work-around which excludes the current 'key masters' and makes the previous technology obsolete (like HTML5.. ok, mostly obsolete).
Join the Slashcott! Feb 10 thru Feb 17!
Do you know what a major PITA it is to deal with the insane browser policies that treat self signed certificates as if they are a terrorist organization, while giving a complete pass to the http based authorization with clear text passwords?
Bloody hell, what is wrong with this picture, where a self signed cert is actually presented as some form of a VIRUS almost to the end user, when all that is needed is a warning that there is a self signed certificate in the address bar, with an ability to mouse over to copy the fingerprint and compare it to a fingerprint found on a site or on a business card or email, etc?
How about making it easier for the web to adopt https in the first place by showing some humility and not behaving like total assholes on the part of the browser development/management teams and realize that majority of the sites that could use encryption for data transfers, especially where it concerns privacy matters, like user names / passwords, and rework the interface notifications that warn the users about self signed certs to something that doesn't look like a bomb is about to go off?
You can't handle the truth.
It doesn't work. If a web site you need uses a CA you don't trust, you're screwed. Unless you can get through to major banks and governments and tell them who to buy their certificates from...
Which is why we need to allow multiple signatures, so you can remove trust from a bad CA without losing access to major sites.
Finally! A year of moderation! Ready for 2019?
Does SSL? No? Well then.
Whoa there. Please review the entire concept of a CA root cert. I suppose on a meta-level someone could MITM a torrent download of your OS install, to replace the real verisign cert with their own, but...
Anybody can create an SSL certificate for any domain given the right access and if you or your computer accepts a certain CA
If you own the secret key of a public root key for a CA that is installed on the victim's PC, then yeah. Or, if you can force your own CA into a victims machine. Otherwise, not so much.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
You can only trust what you can see with your own eyes; trust does not inherit, plain and simple. Any system that relies on inherited trust is broken before it starts.
Our whole society is reliant on inherited trust. Feel free to try to escape from it.
Finally! A year of moderation! Ready for 2019?
The DNSSEC layer only verifies no one has altered the port 53 packets. [...] SSL layer encrypts the whole data stream.
Then use them together. Have each domain owner run his own CA and use an RFC 4398 resource record to put the certificate for that in DNS. If a TLS connection's certificate chain ends up at an untrusted certificate, the browser would fetch a CERT RR for the domain and treat the result as a domain-validated intermediate CA certificate signed by the DNSSEC root.
Just ask everybody you trust today whether they've ever visited diamonds-usa.com and think it's a trustworthy site.
... and thus making useless to them any sites that you visited.
Congrats, you just proved brilliantly why a "web" of trust can't be trusted, even if it's only one hop "deep". Yes, I am aware that is actually the point you are trying to make, but you probably didn't intend to make in this way...
You may trust your friends' integrity and honesty, but you better won't trust their knowledge about what a certificate actually means.