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

This enhancement request has been transferred to Tomcat 5 because:
- TC4 and TC5 share the connectors
- TC4 is no longer being developed, only supported

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.

I guess you don't care enough to suggest such text, so I'm closing the item.

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.

Try 
  String sslID = (String)request.getAttribute
("javax.servlet.request.ssl_session");

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
hijacking?
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
remoteAddress?

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:
  request.getAttribute("javax.servlet.request.key_size");
  String sslID = (String)request.getAttribute
("javax.servlet.request.ssl_session");

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.

thx, seems to work!
Had troubles finding the doc pages in CVS to provide the promised diff patch

Docs enhanced accordingly for Tomcat 5.0.30 and 5.5.5.

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!

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.

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 ->
INVALID.

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.

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.

(In reply to comment #15)

Ralf,
  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
specs.

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 
connections.