[Proposal] Securely sharing sessions between HTTP and HTTPS

[Ceki Gülcü <ce...@qos.ch>]

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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: [Proposal] Securely sharing sessions between HTTP and HTTPS

[Ceki Gülcü <ce...@qos.ch>]

One more thing.

Given that in the current version of Tomcat the session id created in
HTTP mode remains the same when switching to HTTPS, then the a
vulnerability similar to that described by Craig is already there. One
does not need to switch from HTTPS to HTTP to create a vulnerability,
*just* switching from HTTP to HTTPS will do it too!

I have actually tried this and was able to hijack the session both in
http and https modes. All I had to know was the JSESSIONID that was
revealed in HTTP mode. Oh, I used the default ports, that is 80 for
HTTP and 443 for HTTPS. It probably does not work otherwise.

Is this an obvious vulnerability or a new one?

One possible fix was already described in my previous message copied
below.

At 19:30 22.01.2003 +0100, you wrote:

>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:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>

--
Ceki



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>