SSL and the Future of Authenticity

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

Comments

The CAKE protocol

[Omnifarious]

This, Diaspora, and personal interest by friends have gotten me interested in working on The CAKE Protocol again. My goal is a Python reference implementation that can speak over TCP, email, and possibly IM.

Last time I stalled out once I got a job. I also realized that the protocol design was flawed, and the API design for the internals was awkward. Also, I was all alone in a new city. I have friends who are interested now, which makes it easier. And maker spaces with people to talk to. When you have to work on something all by yourself it's hard to stay motivated.

Re:The CAKE protocol

[Anonymous Coward]

The "CAKE" protocol you say?

Liar.

Re:The CAKE protocol

[Omnifarious]

I've revised the protocol spec, and I think version 2 is fairly good. It still has a problem with liveness, but this is due to the fact the protocol is very round-trip avoidant, and there are some mitigating strategies that can be adopted. Another problem is the lack of forward secrecy due to not using Diffie-Hellman for key negotiation and instead directly encrypting the keys with RSA. That can also be fixed in a later version without altering the protocol so significantly that users will have to modify their code.

One last flaw is that I'm not positive a 256-bit namespace is quite large enough to handle all names that will ever be generated given that the birthday paradox effectively halves this to 128-bits. But I think that's pretty minor.

Re:The CAKE protocol

[cjb658]

No matter how good SSL is, you can always just remove it with a tool like sslstrip (also developed by Moxie Marlinspike). I guess you could have banks and other web sites instruct the user to look for the lock icon, but like Moxie said in his Defcon talk, he tested it on hundreds of users by running a Tor exit node, and every one of them still logged in after being sent an unencrypted login page.

THE MESSAGE IS CLEAR

[Anonymous Coward]

Texting one time pads is the ONLY SOLUTION.

Re:THE MESSAGE IS CLEAR

[Roogna]

I realize the comment was posted as a joke of sorts, but on the sense of taking it seriously... say you've got someone with AT&T based Internet access and AT&T cell access. Then you're trusting the phone provider to not intercept and replace the one time pad with their own in a MITM attack. While texted messages is probably a fair amount of security for say, your WoW account, I wouldn't consider it secure for the communications that really matter. As the article says, when SSL was developed a lot of the ideas behind secure Internet communications were still being figured out on a basic level. Without the knowledge of just how sophisticated attacks were going to become. Anything designed today needs to consider just how sophisticated attacks are likely to be in 10 years. The backbone providers themselves have frequently in recent years proven highly untrustworthy. In the future communications will need to be at least verifiable, if not safely encrypted, even despite governments and major corporations controlling the wire.

RTFA

[Tigger's Pet]

I just hope that the many people who will post on here, with all their different opinions will actually take the time to read the article first. I know that is asking for a lot on /. but I can hope. Moxie Marlinspike (what a great name by the way) has really done a great piece of work here and it deserves to be read and digested before being critiqued.

Re:RTFA

[Tigger's Pet]

It shouldn't be government regulation. No one country has the right to try and regulate the Internet, even though both the US and the UK seem to think they do far too often.
This is yet another reason why we (that's the global 'we', not just the few) need a totally independent Internet regulation authority, funded by every government, to oversee the whole thing. They could make decisions for the good of the Internet, not for the good of their own little corner of the world, or because industry is threatening to withdraw funding for their next election campaign.

Re:RTFA

[Securityemo]

It was a wondefully terse piece of work. He's got a talent for writing. You won't be wasting your time, RTFA.

Re:RTFA

[Burdell]

I RTFAd, and a few things jump out at me:

- Attacking GoDaddy's trust because Bob Parsons went hunting in Africa to help farmers. Way to bring politics into a supposed technical discussion.

- Confusing management of the DNS root with domain takedowns done at the registrar level.

- Repeated use of "forever", as if certificates don't expire (and protocols never change).

I think DNSSEC could be used to augment SSL security. For example, sites could list valid key IDs in a DNSSEC-signed record. You still use CA-signed certs, but a rogue CA can't also edit your DNSSEC-signed record. It is also much easier to monitor DNS for somebody trying to change something.

Re:RTFA

[DarkOx]

Ok many of your points are fair but your issue with the word forever really isnt. Many of the root CA certs don't expire for like 30 years! In Internet which has only really existed that long and only been public for a little under 20 years and SSL even less, 30 years is for all practical discussion the same thing as forever.

Re:RTFA

[Artraze]

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.

Re:RTFA

[yincrash]

Are you positive GoDaddy is being picked on because of the hunting thing? There are definitely many more reasons to not trust the security of GoDaddy.

Re:RTFA

[Culture20]

Are you positive GoDaddy is being picked on because of the hunting thing?

I am. The link to the hunting is in a sentence denouncing goDaddy's trustworthiness based on his personal trustworthiness (without other reasons cited).

There are definitely many more reasons to not trust the security of GoDaddy.

Would have been nice for TFA to state them. Sure, we here at /. know those reasons, but the populace at large doesn't. Most people think GoDaddy is a porn site.

The main issue

[dev.null.matt]

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

[jonbryce]

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:The main issue

[DarkOx]

Well maybe we need to admit there might not be a solution you. Sometimes you can't solve social problems with technical solutions and what is more social than the concept of trust!

Re:The main issue

[increment1]

There is a reasonably straight forward technical solution, that could be implemented in a future SSL protocol, to resolve the issue of trust when you already have an account on a site. A host site can add the hash of your password to the symmetric key used after the key exchange, your browser can then do the same on your side. This is essentially using a a shared secret (the hash of your password) as part of the symmetric key. The result is that no one in the middle can intercept your communication even if they have compromised the certificate.

Since most attacks are done on people who already have accounts, this is a decent improvement in security. It will not, however, prevent spoofing a site before you have an account on it, so extra precaution would need to be taken.

The implementation of this protocol would require that when initiating an https session with the server, you need to input your account credentials to your browser (not posted to the host), which then uses them to establish the SSL session.

Irony

[MobyDisk]

I tried to click the link, but my employer blocks thoughtcrime.org.

Re:Sure, we can replace SSL.

[Anonymous Coward]

The idea isn't to replace SSL, just the authenticity mechanism the browsers employ. Most of what's on the table allows browsers to use the new system and old system simultaneously, with a "both must pass" or "either can pass" setting. So it's not the transition that is difficult.

TLS-SRP for the win?

[WaffleMonster]

Every SSL web site I care about requires me to login. Why not just make mutual password knowledge part of the SSL handshake and be done with it? Then even if a TLA or someone from a convention in vegas decides to take over the world at least the billions of people who have already established trust won't have to worry.

There is still a problem of initial trust when establishing an account but by punting that to the edge people would be better able to make their own decisions. Is SSL good enough? Or would they for example require me to show up in person with ID when setting up an online bank account?

The real issue with the use of DNSSEC is that CAs verify "who" you are...Not "what" domain you have..in practice I'm not sure anyone cares about that. Such a scheme would theoretically be easier to register a typo domain name close enough to a bank to scrape a steady stream of credentials from unsuspecting victims.

Self-signed certs + notaries?

[GameboyRMH]

Why not switch to self-signed certs + a notary system like Perspectives? It would at least be an improvement on today's situation, since there would be no need for CAs and there would be some MITM prevention built into the system.

Re:Self-signed certs + notaries?

[Terrasque]

Agreed. Perspectives is the best solution I've seen for this problem so far.

The only problem I see with it at the moment is either if

1. An attacker control all your internet access from before you install it
2. An attacker control the majority of the Perspectives servers.

But I don't see any of those as impassable problems. 1 can be solved by a trusted install (f.x. from a cdrom), and nr 2 can be solved by crowdsourcing (and some cleverness, like requiring the servers to be in different subnets / countries - thus really complicating things for an attacker).

But, as it threaten a current drug^H^H^H^Hbusiness cartel, and it won't make anyone rich, I doubt it will become a widely enough deployed standard.

Two Faces of an Issue

[NicknamesAreStupid]

Like many things that are too hard to grasp or solve at a technical level, people tend to shift focus to something more discernible. In this case, it is the fact that millions of people who are a part of SSL need to be persuaded to change. This is called "the devil you know verses the devil you don't know" choice. Since most of the unknown devils are of the same paradigm as the known devil, then the status quo will remain. True, there may be a catastrophe that frightens everyone to adopt whatever seems like a safe harbor at the moment. Barring that, it will probably take a new paradigm, perhaps a transparent network that can converge very very fast, making most catastrophic exploits ephemerally limited in scope. True, that would be far from perfect, but then, what is close to perfect?

Chain of Trust is Good, Penalty for Encryption Bad

[inglorion_on_the_net]

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.

Minimum standards for CA Relying Party Agreements

[Animats]

Certificate Authorities issue "Relying Party Agreements", which specify their obligations to users relying on their certificates. Some of these specify financial penalties payable to end users.Over the years, as with EULAs, these have been made so favorable to the CAs as to make them meaningless. (See, for example, Verisign's relying party agreement. Or, worse, the one from Starfield, GoDaddy's CA.)

Now it's time to push back.

The Mozilla Foundation should issue a tough standard for CA Relying Party Agreements to get a root cert into Mozilla. One that makes CA's financially responsible for false certs they issue, with a minimum liability limit of at least $100,000. The CA must be required to post a bond. A third party consumer-oriented organization like BEUC (in the EU) or Consumer's Union (in the US), not the CA, must decide claims.

The technology behind SSL is fine. The problem is allowing CA's that aren't doing due diligence on their customers to have root certificates in major browsers. Mozilla all by itself has enough power to tighten up standards in this area. All it takes is the will.

Leaving out the CAs - like with PGP/GPG

[bradgoodman]

I do like the PGP/GPG model as well, but my belief is that it could be extended more into the "real-world".

For example - if I get a (GPG Encrypted) Email from a RedHat employee, how do I know it's real? Simple. RedHat employees put their GPG Fingerprints on their physical-old-school business cards.

If businesses took this approach too, it would work.

For example, why doesn't my bank print their SSL fingerprint (assuming they have those - not really sure) on my credit card, letterhead, and other "official" materials?

Taking this kind of approach literally takes the CA out of the equation. I trust the certificate because I know it's valid - not because someone else says it is.

P.S. With a name like Moxie Marlinspike - it seems like he should have a handlebar mustache.