Why not SSL?

SSL stacks up in an intriguing way against our requirements. Consider:

  • It certainly meets the test of being a tried and tested protocol believed to be very secure, especially when used with mutual authentication (certificates at both ends). While occasionally there will be reports of how SSL can be defeated, with rare exception those are reports about attacks on SSL used without mutual authentication. Even when a flaw in SSL is genuinely discovered, it is because it is under constant scrutiny. Given that we would much rather use a proven protocol under constant scrutiny, and consequent improvement, SSL even in this case meets our needs.
  • It is constantly being improved (e.g. TLS 1.2, EV certificates, etc.)
  • Many of the web applications under discussion already have SSL certificates, and businesses know how to get and manage one.
  • An entire trust infrastructure exists for validating businesses and issuing SSL certificates.
  • SSL has this notion of an abbreviated handshake, so that if two parties have established a session once, they can create additional sessions without having to do any costly public-key operations.

But, there are three gotchas:

  • The show stopper: It does not work for our problem! SSL was explicitly designed to be a two party protocol. Our problem is inherently multi-party.
  • The solvable problem: SSL has been designed as a transport level protocol. With a few exceptions we reference in our White Paper, SSL has been pretty much exclusively deployed over TCP.
  • The image issue: SSL is perceived as a large and complex standard. Those who have followed the development of the protocol over the last fifteen years can appreciate why it is what it is, but for our problem what is needed is a simple specification that can be implemented in a RESTful fashion. The short and sweet OAuth specification is the model more likely to be adopted.

So regrettably SSL cannot be used.