Tomcat should not carry over a session id generated under HTTP do HTTPS requests. After authentication, the session ID becomes THE secret password. In reality, many standard servlets (including e.g. Apache MyFaces servlet) return a session ID on the first request. After switch to SSL (with authentication), the session ID is retained, thus allowing easy session hijacking. In the ideal world the session should survive the switch from HTTP to HTTPS, but the session ID must change upon switch to HTTPS.
Are you sure the same session is indeed carried over? I thought we'd implemented the opposite (new session when moving from HTTP to HTTPS), quite purposefully for security, as far back as Tomcat 3.x. See for example http://mail-archives.apache.org/mod_mbox/tomcat-users/200301.mbox/%3C3E1F642E.4610DE28@attbi.com%3E
(In reply to comment #1) > Are you sure the same session is indeed carried over? I thought we'd > implemented the opposite (new session when moving from HTTP to HTTPS), quite > purposefully for security, as far back as Tomcat 3.x. See for example Yes, I am sure. The problem can be demonstrated like this: 1) Using HTTP, go to an insecure page which assigns a JSESSIONID (eg. any JSF page) 2) Notice the JSESSIONID (which can be sniffed on the network by man-in-the-middle) 3) Go to an authenticated HTTPS page (eg. via form-based login). Look at the "secure data". The JSESSIONID is still the same! 4) From another computer, write the URL of the authenticated page including the JSESSIOND obtained in step 2 above. Bingo - the hacker is in! In order to circumvent the problem, we had to insert code into the login page which invalidates previously assigned session, loosing all session info. An easy fix in Tomcat would be to change (or append) the JSESSIONID upon switching from HTTP to HTTPS. Switching from HTTPS to HTTP is already forbidden as you mention, which is correct. Tomas
I was able to easily replicate this on 5.5.20. RE #1 - unless I'm misreading the referenced post, that discussion is about new sessions being created when going https-->http, not the other way around.
NO, the problem is that the SessionID, when switching from HTTP to HTTPS remains the same!!! I believe this is a serious security issue and should be dealt with. The attack scenario again: 1) A HTTP page assigns a SessionID 2) Man-in-the-Middle notices the SessionID 3) Upon switch to HTTPS, the SesssionID remains the same. After login to HTTPS secure area the man-in-the-middle is able access all HTTPS pages just using the SessionID obtained.
The session id as defined by the specification can be used by the user for a variety of things, or can be pretty much set in stone due to other factors (session clustering, persistent storage). So I'd suggest calming down and relaxing, because this is not going to be fixed. The proprietary solution (which could be enabled using a valve) is to expire the session and create a new one with a different session id, and as a convenience, Tomcat could copy over some of the session data. Feel free to submit such a valve if you'd like to.
Marking this as an enhancement and awaiting a patch for review.
Tomcat now provides an option to change the session ID on authentication. This should address the concerns raised here. *** This bug has been marked as a duplicate of bug 45255 ***