Bill the Plumber

Now that Resteasy 3.0-beta-1 is out, I’ve been thinking a lot about some custom security protocols I’d like to prototype.  Client cert authentication has always been a part of that thinking, but when it comes to browsers, client certificates are complex and even scary for most users.  Why does it have to be this way?

Current web authentication uses cookies to set up a secure session between an authenticated user and his browser.  Cookies are allocated and stored per-domain and forwared with HTTP requests to those domains.  Why can’t we do something similar with SSL and client certificates?

For example, what if when you registered at Google.com, it asked you, “Do you want to authorize this device?”.  You would click on a “OK” button and Google would generate a key-pair and a digitially google-signed certificate for your device.  The HTTP response to clicking that “OK” button would provide a base 64 encoded headers that contained the generated private key and signed certificate:

HTTP/1.1 200 OK
Content-Type: text/html
Set-Private-Key: 23423ab1123affaccde12312
Set-Certificate: 11ab332789dff


<h1>All Set</h1>
<p>Your machine is now authorized</p>

For the google.com domain, your browser would store the private key and certificate in your browser’s persistent store.  The next time your browser makes an HTTPS connection to google.com, it would use this certificate to connect.  When you think about it, this isn’t much different than google setting a persistent cookie to remember who you are.  Now its remembering you in a much more secure way.

Additionally, what would be cool, if this google-generated client-cert could be negotiated and sent to other domains/websites on the internet.  For example, let’s say you had a social media site that exchanged sensitive information and wanted to use HTTPS.  The social media site could send a redirect, with an additional certificate negotiation header stating which client-cert domains it prefers

HTTP/1.1 307
Location: https:/.../
Accept-Certificate: google.com, facebook.com

Here, the server is redirecting us to an HTTPS based URL.  The Accept-Certificate says that it requires a google.com or facebook.com generated client certificate.  The browser would then make an SSL connection to the redirect URL using a stored client cert from one of the preferred domains.

There’s a bunch of cool things about this.  For one, you could have SSO to multiple different social media sites and applications without the need to enter one password.  Secondly, there’s a lot of secure protocols you could implement on top of this to make the internet as a whole, more secure.  Most importantly, there’s no knowledge the human user has to have as to install a client certificate.  It really sucks that the microsofts, mozillas, apples, and googles of the world haven’t put much more thought into client-certs and making them easier to use.

Way back in June I was brainstorming about ideas for decentralized authentication.  Here’s a summary of the requirements I wanted:

• Competely stateless servers.  Servers that host browser applications and restful services would not have to store usernames, passwords, or permission metadata (roles allowed).
• Servers would not have to handshake with an Identity Provider (IDP).  An HTTP request should contain all the information a server needs to authenticate and authorize a client.
• A single web request can spawn complex authenticated and authorized interactions between underlying distributed web services.  This single web request would have all the metadata needed to invoke these complex underlying interactions between distributed services.

Unifying Interactions With Cookies

The problem with the protocol discussed in my previous blog was that it relied on new headers being transmitted between the client and server.  This sort of mechanism just wouldn’t work with browser-based applications.  Why?  Well, a browser isn’t going to know how to transmit and process new headers.  The only way to get a browser to store and forward metadata is via a cookie.  Most browser-based apps already use a session cookie to authenticate users (after a log-in of course).  There’s no reason we couldn’t re-use the digital signature techniques discussed in my previous blog with cookies.  Here’s how it could work:

1. Browser points to example.com
2. example.com redirects browser to idp.com (the identity provider)
3. User logins into the IDP
4. IDP redirects back to example.com.  The forward URL has all security metadata needed for the request, digitally signed (a query parameter would have the signature).  The amazon url signing technique could be used.
5. Example.com would authenticate and authorize based on the query parameters of the forward URL and also verify the signature.
6. Example.com would send back a set of cookies that contained all the security metadata expressed as cookie name/value pairs.  A special digital signature cookie would be used to sign them all so that on subsequent requests, the server could verify all the information stored in these cookies.

Step #4 might be problematic as the URLs could get quite large.  Who knows if a browser barfs on absurdly long URLs.  In this cast we could do a double form-post.  IDP could response from a successful login with an HTML Form whose target is Example.com.  This form would have all hidden fields within it containing security metadata.  One particulr form parameter would have a digital signature (I think SAML HTTP bindings work like this).

One vulnerability here is the cross-site scripting hack.  Most website already have this vulnerability I believe, so using existing techniques would be best.  I’m not sure how website solve this particular problem, but the HttpOnly flag could be used with each session cookie.  Javascript apps could have their javascript dynamically generated by the server and include the necessary code to manually apply and send the appropriate cookies.  Another thing that might mitigate things, is to include a timestamp with the cookies.  The application server would check for stale timestamps and with each request reset the digitally signed cookies with a new timestamp.

Non-Browser Clients Use Cookies Too

For non-browser clients, they could use a simpler RESTful protocol to obtain a signed URL or the set of signed form parameters.  There’s also no reason they couldn’t get a set of signed cookies instead of either of these approaches.