tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Barker" <>
Subject Re: Tomcat 5.5 / Apache 2 / Join (Tomcat-) Session with SSL-Session / Which mod should be used?
Date Sat, 20 May 2006 01:41:02 GMT

"Darryl Miles" <> wrote in message
> Michael Decker wrote:
>>>> My problem is, that the application session (set by cookie or url
>>>> parameter) is not associated with the SSL session. And I hope, there is
>>>> an easy way to that.
>>> I dont understand why you want to connect to two (under my definition of
>>> each explained above).
>> Why I want that? If you've an application with session. So you can get
>> the application information by spying (XSS, browser plugin etc.) or
>> copying (URL with session ID).
>> Because of that the idea was to join SSL session id and application
>> session id, you can avoid that.
> Understood on what you are trying to do now.  Maybe: 
> and :
> sslSession = ( 
> request.getAttribute("");
> byte[] sslId = sslSession.getId()
> Will do the trick.

Actually, no.  This will just result in an NPE :).  And, if you think about 
it, if Apache is handling the SSL traffic, then there would be no way to get 

What does work is:
       String sslid = 

This will give you the SSL Session-ID even if you are fronting with Apache 
(Apache passes it to Tomcat).  However, be warned that this is a 
Tomcat-specific feature:  It won't work if you try and port your app to 
another Servlet Container.

> Before all HttpSession object usage you want to validate it, maybe a 
> Servlet Filter would be a good way to handle this. 
> The AJP protocol seamlessly conveys the SSL related information between 
> apache and tomcat.  Although apache+mod_ssl is the SSL endpoint, the 
> web-app still have access to it just as-if you had setup SSL on tomcat 
> directly.
>>> It is not normal to connect the SSL session in
>>> this way, as the HTTP protocol may (or may not) use the same SSL session
>>> details during the next request, the client may (or may not) support
>>> persistent connections.  The SSL session cache is a performance
>>> optimization, not something an application gets to see or use directly.
>> I'm not sure if I completely understand you: The SSL session (ID) can
>> change between two requests?
> HTTP is a stateless protocol.  So from a pure HTTP perspective, yes sure 
> the ID can change between requests.  In practice with featurefull browsers 
> and a normal usage pattern linking them is probably safe you'll have to 
> test with your userbase to be sure.
> Darryl 

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message