Shibboleth Developers

[Peter Williams <>]

Don't focus on sessionid, in SSL3 and later. Work with the channel binding 
that cues off the finished messages (not the endpoint certs).

I know that's hard because the commodity APIs don't expose the finished state 
(they are still not allowed to). But, before channel bindings were added to 
Digest and Negotiate scheme in the inner channel,  there were no exposure 
points for the outer channels endpoints either.

Progress is slow, but its happening.

-----Original Message-----
From: 

 
[mailto:]
 On Behalf Of Chad La Joie
Sent: Wednesday, February 09, 2011 6:53 AM
To: Shib Dev
Subject: [Shib-Dev] Viability of SSL/TLS Session IDs usage for application 
Session IDs

We currently do various things to try and guard our IdP's session:
using  cryptographic random identifiers to prevent session fixation, checking 
IP addresses to prevent hijacking, and computing a MAC over the data to 
ensure data integrity.  Scott's work on channel bindings, and the Servlet 3.0 
spec, gave me the idea that another option would simply be to bind the 
session to the TLS session ID.

Doing this seems like it would address all the aforementioned issues and 
obviate the need for a session cookie (in most cases, see below).
Those seem like two big wins.  It should also address the issues that 
occasionally turn up when there are not-so-transparent proxies between the 
browser and the IdP (e.g., ones that randomly change the client's IP address).

I can, however, see a few possible issues with using the TLS session 
identifier.  First, the IdP may not be using TLS (either because it's just a 
test system or because they really don't need it for some reason).  In that 
case I think the IdP can just fall back to doing what we do now.  Second, the 
IdP may be behind TLS-terminating hardware (e.g., web server, load balancer, 
accelerator) but all such systems this that I've encountered can be 
configured to pass the TLS data through and if they don't then it just looks 
like the previous case.  Lastly, and this is my big concern, browsers may do 
dumb things and, seemingly randomly, drop/restart TLS sessions.

Does anyone have any experience really using these TLS session identifiers in 
their web apps?  If so, what sorts of issues did you encounter?  Did you find 
solutions to them?

--
Chad La Joie
www.itumi.biz
trusted identities, delivered