Ben Laurie blathering

Is SSL Enough?

In response to my post on OAuth WRAP, John Panzer asks

[A]re you arguing that we shouldn’t rely on SSL? OAuth WRAP (and for that matter, OAuth 1.0 PLAINTEXT) rely on SSL to mitigate the attacks mentioned. Ben Adida’s argument is that SSL libraries won’t save you because people can misconfigure and misuse the libraries. But OAuth libraries will save you; apparently they can’t be misconfigured. There seems to be a small contradiction here. Especially since OAuth is much less mature than SSL.

I am not saying we shouldn’t rely on SSL, and I am not arguing that SSL libraries won’t save you (though it’s pretty clear that they are often misused – in particular, failure to check that the certificate presented corresponds to the server you were trying to connect to is a fantastically common error, it seems – in other words, SSL is often used in a mode that gives no protection against a man-in-the-middle). What I am saying is that when you design a security protocol, you should design something that addresses the appropriate threat model. Now, I am not aware of a published threat model for OAuth WRAP, so I instead apply the one I have in my head for authentication protocols, since that’s what it is. In my off-the-top-of-my-head model of authentication protocols there are various properties I want

  • No replays: if someone gets hold of a request, they should not be able to replay it.
  • Not malleable: if someone sees one request, they should not be able to create another correct one.
  • No credential equivalent: the server should not be able to create a request that looks like it came from the client.

And so forth. I will not create a complete set of requirements, because that’s a tough job, and it’s nearly time for supper. However, you can easily see that OAuth WRAP does not satisfy any of these requirements. Nor, incidentally, do username/password logins.

Now, you can argue that the use of SSL makes the requirements redundant, and I have some sympathy for that argument but, as we have seen, SSL can have flaws in it. And, in fact, for example, the current flaw is perfect for attacking OAuth WRAP – I could inject a request in front of your WRAP request that causes your credential to be sent to me, and now, bingo, I can do anything at all that you can do. A well designed protocol would not suffer from this issue.

But even if we ignore the weakness in SSL, there are other requirements that are not met – in particular, the “no credential equivalent” requirement is not addressed at all by SSL. The server can easily fabricate a request and claim I made it. This is a terrible property for a protocol that is supposed to be used to protect my assets.

So, in short, I agree that you can use SSL to make a crappy protocol less crappy. But the right thing to do is to figure out what your requirements are (really, not fudge them so they fit your protocol, as I rather suspect will happen here) and then design a protocol that satisfies them. If that protocol happens to be “password over SSL” then great, you’re home and dry. But I do not see how any modern, well-designed authentication protocol could be that way.


  1. Agreed that there should be a published threat model for OAuth WRAP (I had hoped it was in the PDF somewhere, and also hoped that the PDF would magically transform into something reasonable like an HTML page at some point). But “No credential equivalent: the server should not be able to create a request that looks like it came from the client.” isn’t, I believe, a goal or a property for either OAuth 1.0 or OAuth WRAP. Whether it _should_ be is an interesting discussion which should happen before discussing the merits of OAuth WRAP vs. OAuth 1.0.

    Note that OAuth 1.0 without SSL doesn’t even fulfill the “Not malleable” goal, as you can twiddle with request bodies all day long. If you can block or modify the original, or if the recipient is not checking nonces, there could be quite a bit of fun to be had.

    Comment by John Panzer — 13 Jan 2010 @ 21:31

  2. I’m not familiar with OAuth, but for pw-based web authentication TLS-SRP(rfc5054) is clearly the way to go. I guess one could use that for OAuth. From a design point of view however, thats nothing but a bad hack. Its like being unable to correctly configure a server and thus tunnelling all its traffic through a trusted VPN. SSL by itself is rather complex and had numerous extensions. X.509 is so complex with regards to trust relations and implementation that most admins and end users don’t know how to use it correctly and all available implementations are probably hopelessly broken.

    So, please, let some system security guy make a sane protocol for you. Then you can implement a library in some language that does bounds checking and variable initialization for you and that doesn’t wrap-around integers. Then you consult with another crypto guy to beat your implmentation until its secure, e.g. remove timing side channels. Hopefully you get some positive peer review of the base protocol while the implementation matures. Then you a some fancy documentation with pictures and everyone will love it.

    Comment by pepe — 14 Jan 2010 @ 2:09

  3. The two technologies are entirely unrelated. I’m not sure what you’re going an about here. In fact OAuth relies on SSL.

    Comment by OMG — 14 Jan 2010 @ 2:21

  4. This would be relevant if WRAP actually used SSL for accessing protected resources. It doesn’t. All it does is use SSL for getting tokens. Once tokens are obtained, it uses NOTHING to protect them. And no, short lifetime for tokens isn’t a protection, it just limits the duration an attacker can use the credentials. But since it is so easy to capture them in the first place, it just means a bit more hassle, nothing else.

    In fact, WRAP doesn’t even recommends SSL for accessing resources while requiring it for getting tokens. This will lead developers to think that SSL adds nothing here…

    Comment by Eran Hammer-Lahav — 14 Jan 2010 @ 7:22

  5. There are certainly a number of use cases that we should enumerate in order to help guide this work — as I have many such cases in my head, and that I’ve revealed through conversations — but that probably aren’t well-captured yet.

    At the end of the day, it’s easier to pick apart the progress that we’ve made then examine the unfortunate reality that we exist in today — but all of these modern security/access efforts (i.e. OpenID/OAuth/WRAP) are predicated on [consumer-facing] use cases that simply weren’t as common when things like SSL and TLS were developed (to the best of my knowledge, which admittedly is limited).

    In fact, I imagine that in some ways we are reinventing wheels here — but part of the problem it seems is that many of those protocols didn’t solve some of the things that we’re now trying to solve, in a way that works with the way that both developers and companies are working today — which is fast and quick. There are many more data consumers that will gleefully take a user’s third party credentials because it’s simply easier for them to build a one-off scraper than it is to go through a pre-registration and authorization dance, especially with multiple parties.

    While it’s the job of the security community to be prudish and conservative — in the meanwhile, the lack of a more pragmatic solution that finds some kind of middle ground is leading more and more people to seem comfortable with giving away their passwords in exchange for basic services. That to me is a threat that MUST be addressed — and therefore requires a solution that lazy and/or unmotivated developers must be willing to adopt because it’s actually JUST AS EASY or only slightly harder than their current practice.

    You can go blue in the face about how such folks shouldn’t ever touch a security protocol, or are selling out their users’ security — and I think for many of them, they’ll just shrug and explain that they did what they had to because the alternative would have cost too much to “get right”.

    Whatever the correct approach is with these protocols — and I’m not the one to decide that — it needs to be supported by better documentation, more quality library coverage, and an awareness and promotion campaign undertaken by the 800-lb gorillas in the space to help move this ball forward. If it was possible to achieve this with SSL (to the point where it’s now on-by-default for all Gmail users), I think we can do the same thing with OAuth, WRAP, OpenID, OpenID Connect, or whatever other protocol appears to be the right path forward.

    Comment by Chris Messina — 14 Jan 2010 @ 17:22

  6. […] Ben Laurie on SSL and crypto in general. Well worth a read. < […]

    Pingback by Is SSL Enough? « Priocept Blog — 23 Feb 2010 @ 17:03

  7. […] with applications, which means you can play with it in your browser. While there are drawbacks to exclusive reliance on SSL, it is so simple to get started that it can’t be beat for most developers. OAuth 2.0 also […]

    Pingback by Under the covers of OAuth 2.0 at Facebook | Social Lipstick — 11 May 2010 @ 16:03

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress