tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject RE: HTTPS to HTTP
Date Thu, 09 Jan 2003 18:51:09 GMT


On Thu, 9 Jan 2003, Shrotriya, Sumit wrote:

> Date: Thu, 9 Jan 2003 12:45:20 -0600
> From: "Shrotriya, Sumit" <Sumit.Shrotriya@westgroup.com>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: 'Tomcat Users List' <tomcat-user@jakarta.apache.org>
> Subject: RE: HTTPS to HTTP
>
> Craig,
>
>   I agree with you 100% but there can be a simple solution to the problem
> that you just raised..and that is that a new session id is created and
> mapped in some table when moving from https-->http this way user B can not
> get access to the admin page.
>

How would this stop B?

After the switch back to HTTP, if a session id works for A it will also
work for B.  It doesn't matter whether it's a "real" session id or a
"mapped" session id -- the problem is that B can snoop it in cleartext.

> ~Sumit

Craig


>
>
> On Thu, 9 Jan 2003, John Holman wrote:
>
> > Date: Thu, 09 Jan 2003 12:56:16 +0000
> > From: John Holman <j.g.holman@qmul.ac.uk>
> > Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> > To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> > Subject: Re: HTTPS to HTTP
> >
> > Yes, that is clearly a risk. The *whole* web application needs have no
> > risks in order to allow http access to any of it - any sensitive link
> > and it must all be https. (And of course if SSO is enabled *all* web
> > applications for the virtual host must be considered safe).
> > Otherwise I'm not convinced that session stealing is really a problem -
> > though open to counter-arguements.
> >
>
> 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).
>
> Once an application has switched from HTTP to HTTPS for a session, it
> should be programmed to never go back again.
>
> > John
> >
>
> Craig
>
>
> > Ralph Einfeldt wrote:
> >
> > >But be aware that quite simple changes in the
> > >configuration of tomcat can lead to big security holes.
> > >Guess what happens if you or somebody else someday
> > >decides to switch from basic authentification to form
> > >authentifcation and the sysadmin visits the user side
> > >and somebody steals the sysadmins session ...)
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: David Hemingway [mailto:dbh001@kooee.com.au]
> > >>Sent: Thursday, January 09, 2003 12:08 PM
> > >>To: Tomcat Users List
> > >>Subject: Re: HTTPS to HTTP
> > >>
> > >>Thats is my exact situation. The sysadmin section of teh site
> > >>is 100% https.
> > >>but the on the user side there is nothing that sensitive and
> > >>little harm they could be cause stealing someones session.
> > >>It would not be worth going to the trouble of stealing the
> > >>session for the benefit you would get.
> > >>
> > >>
> > >>
> > >
> > >--
> > >To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> > >For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
> > >
> > >
> > >
> >
> >
> > --
> > To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail:
> <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:tomcat-user-help@jakarta.apache.org>
>
> --
> To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message