Ralph Einfeldt explained: > The problem is, that if you keep the same session id after you switch to > https it is possible that somebody steals your secure session.
Yes, of course. (Sometimes I miss the obvious.) >The only information that > is used to identify the session is the session id. And this is easy to forget. > As long as you talk http the session id is readable to anyone who can > listen to your traffic. The cookie and the url are transmitted in clear > text. And the session id is either in the cookie or in the URL. > One little example > > You have a application with a form to edit some sensible data that has > a confirmation page. In other words, a form on a supposedly secure page that is accessed via https. > If some can gues or know your session id he can easily request the > confirmation page with the same session id and see your > submitted data. Because there is nothing the server can do to prevent other people from using the same URL and cobbling together a page that spoofs the cookie. > I don't know if this thought is the reason behind tomcats behaviour. I think that would explain why Tomcat 4 would be tightening up on this. So, having separate sessions (and session ids) for the secure and non-secure pages is the only safe solution. I know the following questions are a little off-topic, but, Since only the browser which successfully logged on should have the session id (cookie or link) for the secure session, switching back and forth might be possible? The non-secure session id would be used to access an intermediate page in https, and the intermediate page would check for the secure cookie? Could this work? How dangerous would it be? Joel Rees Alps Giken Kansai Systems Develoment Suita, Osaka -- To unsubscribe: <mailto:[EMAIL PROTECTED]> For additional commands: <mailto:[EMAIL PROTECTED]> Troubles with the list: <mailto:[EMAIL PROTECTED]>
