This is a follow up on Craig's message: http://marc.theaimsgroup.com/?l=tomcat-user&m=104213500528622&w=2
> Consider a scenario where you have "admin" pages that require SSL, and > normal pages that can run on either. Assume Tomcat were modified to > migrate your session back. > > Consider the following course of events: > > * User A logs on, selects link for an admin function, > and is switched to SSL for that part. > > * User A then switches back to non-SSL. Among other things, > this means that the session id is now visible in plaintext > on the wire. > > * User B snoops the network, acquires the session id, > and submits an SSL request (with the stolen session id) > to an admin function. > > * Server blithely executes the forged request, because login > identity is attached to the session id (which is now > plaintext -- it wouldn't be if the session had been > created under SSL and never allowed to switch back). Craig, thank you for this explanation. It clarifies the rationale for me. > Once an application has switched from HTTP to HTTPS for a session, it > should be programmed to never go back again. I think there is a way to *securely* switch from HTTP to HTTPS and vice versa. Here is how. Let S be a session shared in both HTTP and HTTPS modes. Furthermore, let 'c' be the session identifier of S in HTTP mode and let 't' be the session identifier of S in HTTPS mode. Thus, 'c' and 't' identify the same session S. If we assume that 'c' and 't' are such that by only knowing 'c' it is still impossible or excessively hard to guess the value of 't', then revealing 'c' on the insecure HTTP channel does not give the attacker an advantage. Of course, the servlet container should only honor an HTTPS request identified by 't'. It should reject an HTTP request based on 'c'. Has the above technique consisting of mapping two session ids to one servlet session been previously considered? Note the technique is secure because knowing 'c' does not allow the attacker to hijack an HTTPS session. -- Ceki -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
