Tomcat behind Apache with SSL terminated at firewall - share session between Tomcat connectors?

[Richard Levy]

Hi all,

We have a web application that we're migrating to Tomcat 6 from OC4J. Half way thru the application flow it moves from HTTP to HTTPS. When it does this, instead of using the same session, it creates a new one and falls over. In OC4J there was a "shared=true" setting that meant the session was shared and the problem didn't occur. Tomcat is much more strict and does not allow sharing of the session between HTTP & HTTPS (its the law - well ,the servlet spec!).

When our application goes secure, SSL is terminated at the firewall, so actually Tomcat never performs any SSL processing, although it has to realise certain pages are secure. We've achieved this using 2 connectors in the server.xml. The firewall sends requests to either a secure or non-secure virtual host in Apache, which knows to use the appropriate connector in Tomcat. One is pretty much a vanilla AJP1.3 connector for non-secure and the other has the scheme property set to https, along with secure set to true and SSLEnabled set to false. This seems to ensure that pages are rendered appropriately. So, although neither connector is _actually_ secure, the 2nd one believes that it is and does not use the same session as the 1st one.

    <!-- Define an AJP 1.3 Connector on port 8009 -->
    <Connector port="8009" 
               protocol="AJP/1.3" 
               redirectPort="8010" 
               maxThreads="200"/>

    <!-- This is the secure connector, although its not using SSL, it's just secure traffic -->
    <Connector port="8010" 
               protocol="AJP/1.3"
               connectionTimeout="20000" 
               scheme="https"
               SSLEnabled="false"
               secure="true"
               maxThreads="200"
               proxyPort="443"/>

Is their a way to achieve session sharing through configuration in this environment, or do I need to write code to pass session data over?

Thanks for your help,
Rich

[Tim Holloway]

I think you've got that a little garbled. The session id changes when you switch to SSL, but the session itself does not. Otherwise I'd have massive breakage every time I did a login on a JSF webapp, seeing as how JSF is session-obsessed.

On the other hand, if you're actually running 2 different hosts there, as your post seems to imply, well, each host is going to have its own independent session unless you configure Tomcat to do session-sharing.

[Richard Levy]

Hi,

thanks for replying.

I have proved now that the the two connectors (as defined below) use the same session by changing the 2nd connector to an insecure one and moving through our site, manually changing port numbers to exercise both.

I'm a little confused - If the session ID changes, you're getting a different session object underneath. Why would the session ID need to change moving between HTTP & HTTPS?

We've now actually moved this forward a little. The problem we appear to be having is that when we move between HTTP & HTTPS, the sticky session routing in mod_jk in apache is not keeping us on the same Tomcat, so it creates a new session.

We do have two virtual hosts defined in Apache, but for the same site. One for non-ssl and one for ssl traffic. We need to do this because the SSL is terminated in the firewall in front of Apache and we need to separate the traffic down to Tomcat and use the appropriate connetor so it serves up pages with correctly rendered URLs etc (hence the reason for the 8010 connector which believes it's secure!).

My initial post was typed in a hurry so I hope this has cleared up a few things. I think a diagram would probably help!

Thanks
Rich

[Tim Holloway]

The session ID is ONLY an ID. It contains nothing descriptive about the session itself, thus eliminating the ability for an attacker to gain insight into the app internals by decoding the session ID. For all intents and purposes, it's just a random number.

The reason SSL uses a different ID is so that an attacker can't steal the id from a non-secure request and use it as a lever into an SSL request. However, you can consider the session to be an entry in a Map full of sessions. Changing the key won't change the value.

You do not need 2 separate hosts for SSL and non-SSL in tomcat. The Apache front-end is perfectly capable of working with a single Tomcat host.

[Richard Levy]

Hi,

I've written a much better description which explains the full architecture, has all the reasoning behind it, and contains the relevant config. I'll start a new topic with this as I haven't been very clear here.

This thread can be considered closed.

Thanks
Rich