Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security Encryption The Internet IT

SSL and the Future of Authenticity 98

An anonymous reader writes "There has been a growing tide of support for replacing SSL's Certificate Authorities with an alternative authentication mechanism. Moxie Marlinspike, the security researcher who has repeatedly published attacks against SSL, has written an in-depth piece about the questions we should be asking as we move forward, and urges strong caution about adopting DNSSEC for this task."
This discussion has been archived. No new comments can be posted.

SSL and the Future of Authenticity

Comments Filter:
  • The main issue (Score:5, Insightful)

    by dev.null.matt ( 2020578 ) on Monday April 11, 2011 @02:53PM (#35784472)

    It seems like the real problem is that any good solution to this issue will, by necessity, require the user to make informed decisions about who to trust and who to not trust. Based on the state of non-technical scamming, the success of confidence men throughout history and the fact that most people just want their browser to take them to whatever is linked off their friends' facebook pages, I can't see that this will ever be resolved.I mean, unless we decide to trust some body to make these decisions for people. Unfortunately, that pretty much brings us back to our current problem.

    That's the main problem I see with the author's notion of "trust agility:... it requires action from Joe Sixpack users who just want their browser to work in the same way their TV does.

  • Re:The main issue (Score:4, Insightful)

    by jonbryce ( 703250 ) on Monday April 11, 2011 @03:06PM (#35784626) Homepage

    The problem is that any non-technical user is going ask what buttons they need to press to get the website to work, and will then press them blindly no matter what.

  • Re:RTFA (Score:4, Insightful)

    by Artraze ( 600366 ) on Monday April 11, 2011 @03:14PM (#35784700)

    I agree about the safari nonsense. Still, GoDaddy is a sleazy company that often seems to cater more to scammers and spammers than it does people that just want a domain name.

    The domain takedowns bit is basically referring to the fact that ICANN is not untouchable. Practically, this isn't _too_ much different than the DHS having a trusted root certificate (as they're _probably_ the only ones that can manipulate ICANN). However, it does mean that you can't un-trust the DHS (and maybe Chinese) root certificates because the manipulation will be happening in the background. (Which isn't to say they can't/don't manipulate Verisign at the moment, but I hope you get the point.)

    "Forever" is a relative term. As far as I'm concerned, it means long enough to exploit a vulnerability. Say... a month? Certificates don't expire that fast, and protocols are glacial by comparison. We're still using SSL, after all, how long do you think it'll be until we replace its replacement? Forever. Maybe even literally.

    Those points made, I do agree that DNSSEC probably wouldn't hurt; the more independent sources of trust the better. Augmenting it further with a traditional web of trust would be even better too.

  • I don't have a big problem with the way the chain of trust works. I have software on my computer that allows me to manage the certificates that I trust. That way, I can decide for myself. Since I don't actually want to bother to do so, I defer to my operating system vendor's judgment. They provide a package containing a list of trusted certificates, which I then use. I can have as much or as little control as I want. I think this is a good system.

    What I do have a problem with is the fact that many applications will use cleartext connections without complaint, but give ominous warnings when using TLS with self-signed certificates. Sure, self-signed certificates don't provide authentication, but neither do clear connections. With TLS, at least I get encryption. This should be a step up in security. At the very least, security is no worse than without TLS.

    I am OK with a warning being shown the first time I connect to a service with a non-trusted SSL certificate, but I feel applications should take a page from SSH here: give a warning that isn't too ominous, and offer the chance to save the public key. Then, next time I connect, if the key matches, go right ahead without a warning. And shout if the key does not match. This should provide good security if the first contact is uncompromised. Importantly, it matches the scariness of the warnings with the risk of the situation.

The use of money is all the advantage there is to having money. -- B. Franklin

Working...