Bug 22679 - how to access ssl session ID out of tomcat to prevent session hijacking and allow for phishing protection
Summary: how to access ssl session ID out of tomcat to prevent session hijacking and a...
Alias: None
Product: Tomcat 6
Classification: Unclassified
Component: Jasper (show other bugs)
Version: 6.0.10
Hardware: HP Linux
: P1 major (vote)
Target Milestone: default
Assignee: Tomcat Developers Mailing List
URL: http://www.fec.uff.br
Depends on:
Reported: 2003-08-24 06:50 UTC by Ralf Hauser
Modified: 2014-02-17 13:50 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Ralf Hauser 2003-08-24 06:50:46 UTC
hi, I am using the tomcat SSL engine.
In order to avoid session fixation attacks (see more on that in
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22649), I would like to put
the SSL session ID into my jsessionid.

RFE: enhance the "SSL ho wto" description at the above URL with a section on how
to do this.

P.S.: I am aware that this possibly reduces the availability of my application
as per http://groups.yahoo.com/group/jetty-support/message/2085
Comment 1 Ralf Hauser 2004-03-05 07:31:50 UTC
one example where hijacking is particularly likely when you integrate with
third-party applications that after doing their job should send the user back to
your own application and you don't want the user to be forced to log into your
own application again!
While it should be possible to offer such a process to the user of my
application, I would like to maintain some level of mutual distrust with that
third-party provider.
One example of such third-party provider might be paypal with their IPN - see
related post in http://www.paypaldev.org/topic.asp?TOPIC_ID=5255
Comment 2 Mark Thomas 2004-06-19 11:46:12 UTC
This enhancement request has been transferred to Tomcat 5 because:
- TC4 and TC5 share the connectors
- TC4 is no longer being developed, only supported
Comment 3 Yoav Shapira 2004-07-21 18:29:07 UTC
Please suggest text in patch diff format for "RFE: enhance the "SSL ho wto" 
description at the above URL with a section on how
to do this." and we'll consider adding it.
Comment 4 Yoav Shapira 2004-10-29 18:43:23 UTC
I guess you don't care enough to suggest such text, so I'm closing the item.
Comment 5 Ralf Hauser 2004-10-30 08:01:14 UTC
I do care, but I don't know the technical solution how to do it. If you tell me
how to access the SSL session ID out of my web application, I am happy to
provide the text patch you have asked for.
Comment 6 william.barker 2004-10-30 21:12:44 UTC
  String sslID = (String)request.getAttribute

Comment 7 Ralf Hauser 2004-10-31 08:27:41 UTC
Thanks for the hint, but unfortunately, after tomcat 3.2.
SSLSupport.SESSION_ID_KEY appears to be no longer present in coyote.
For those web-applications that do not use session cookies because quite some
users do not want cookies - how are they supposed to protect against session
Still, if for example the web application lets paypal's IPN know how to return
into an ongoing (url-rewritten) session, one has to trust them not to spoof the
Comment 8 william.barker 2004-10-31 21:55:22 UTC
It seems that Tomcat 3.3.x & 4.1.x work fine.  With Tomcat 5 you need to 
access a standard attribute to trigger, and then it works fine:
  String sslID = (String)request.getAttribute

It's true that TC 3.3 has a setting to deny access to the servlet session if 
the SSL session doesn't match.  In TC >= 4, it is easy enough to do this type 
of check in a Filter.
Comment 9 Ralf Hauser 2004-11-01 07:07:40 UTC
thx, seems to work!
Had troubles finding the doc pages in CVS to provide the promised diff patch
Comment 10 Yoav Shapira 2004-11-18 16:01:24 UTC
Docs enhanced accordingly for Tomcat 5.0.30 and 5.5.5.
Comment 11 Ralf Hauser 2004-11-19 07:11:00 UTC
thx a lot (also in the name of future security-concerned application
programmers) for honoring this documentation RFE after 15 months (and
unfortunately having to go through the apparently unavoidable WONTFIX/INVALID
episodes  :(  ).

Furthermore, I contend that these functions also will become key to true
phishing protection as per https://bugzilla.mozilla.org/show_bug.cgi?id=268835!
Comment 12 Ralf Hauser 2005-01-20 01:23:25 UTC
good practice for such a anti-session-hijacking/anti-cross-site scripting is to
implement a 2 out of 3 approach: i.e. SSL-session ID, remote IP and user-agent
are compared between each http request and only if 2 out of 3 remain the same,
the login-status is maintained. Not 3 out of 3 because quite some DSL-dynamic IP
assignments change relatively frequently and users are annoyed if the have to
re-authenticate often during a session. Similarly, some browsers do not keep an
SSL session alive for the same duration as a application-user session may last.
Comment 13 Remy Maucherat 2007-04-24 15:49:52 UTC
It is not possible to change the session id of a session, it has to be asssumed.
If you want to submit a valve which would enforce "better" security (= a lame
hack which would pretend to be secure), then I would be ok to commit it and let
this bug report live. Despite the dynamic IP thing, I think 3 out of 3 is a
minimum requirement, despite possible problems (IPs do not change every 5s, so I
don't see the point, and if they do, let the user log back in). Otherwise ->
Comment 14 Lucas Galfaso 2007-10-25 18:43:08 UTC
A browser is free to open multiple SSL connections to a single Tomcat, even when
doing this might be a performance hit. With this in mind, any way to tie the
JSESSIONID to the SSL id is not the proper way to prevent session hijacking.
Comment 15 Ralf Hauser 2007-10-25 20:06:56 UTC
Lucas, you are right that there can be multiple legitimate SSL Session IDs with
one JSESSIONID. So while I stick to the statement that observing the SSL Session
ID is still one good measure against Session Hijacking, if applied alone, it may
also lock out legitimate additional SSL sessions. At least for sequentially
changing SSL-IDs, we account for with the described "n-1 our of n" approach
(comment 12). So if the other n-1 parameters to considered stay the same, the
mechanism probably even works with simultanous sessions with IDs A, B, C since
the tomcat application for each request will just assume that it is a change
from A->B, then from B->C, C->A and so on - not noticing there are actually
multiple simultaneous SSL sessions going on in parallel. Anyway, we have the
approach in operation since months with hundreds of users and no problems.
Comment 16 Lucas Galfaso 2007-10-26 07:39:46 UTC
(In reply to comment #15)

  I understand that Tomcat should provide ways to prevent session hijacking, but
building something into Tomcat to associate a jsessionid with the ssl id is not
the solution. This may be an interesting issue for the Tomcat dev list, but this
is not a bug.
  You can have the same behavior that you are asking to be build in into Tomcat
using a filter that is specific to your application, and I am somehow inclined
into not building into Tomcat something that prevents browsers work within the
Comment 17 william.barker 2007-12-28 21:01:40 UTC
In TC 3.3 this is a setting, and in TC >= 4.x, it is easy enough to implement 
this as a Filter.  I don't see that it is useful to implement this "feature" 
in the core Tomcat code, especially since it may break perfectly valid SSL