In this scenario, the *only* page requiring SSL would be the login page that collects the username and password. (That could be either a dedicated application login page or the login page configured for form-based login. Basic authentication is never an option!). If this condition is met I still don't see that stealing the session id will enable anything that would be considered a risk. The benefit is that it hides the password while gaining any benefits of not using SSL where it is not needed.
Having said all that - for our own situation the extra costs of requiring SSL for non-sensitive pages are negligible so everything involving a user authentication is done under SSL. But that may not be true for everyone.
John
Craig R. McClanahan wrote:
On Thu, 9 Jan 2003, John Holman wrote:Date: Thu, 09 Jan 2003 12:56:16 +0000 From: John Holman <[EMAIL PROTECTED]> Reply-To: Tomcat Users List <[EMAIL PROTECTED]> To: Tomcat Users List <[EMAIL PROTECTED]> 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.
JohnCraigRalph 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:[EMAIL PROTECTED]] 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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
