a) (the scenario I suggested) the *only* secure page requiring https is the login page. Accessing that using the sniffed session id will only let the bad guy login - which gains him nothing.
b) (my understanding of the scenario suggested by Jeff Schnitzer). There *are* other secure pages within the site but (somehow) reauthentication is forced when these are requested with a session id that has previously been used in the http context. I don't actually see how that would be implemented but assuming that it was it seems plausible.
I'd like to see an analysis of the risks for these two scenarios.
John.
Jacob Kjome wrote:
It is my understanding that if Tomcat allowed you use the same session and the session was created under https for a particular user, then once it gets to http the session id is now in clear text. This is what, I believe, Craig is talking about when he says that using SSL in this manner only creates the appearance of security, not true security. All I'd have to do to wreak some serious havoc is sniff packets, hijack the session, and browse back into the secure sections of the site under the guise of the user whose session I hijacked. How is that security?
Jake
At 08:17 PM 1/9/2003 -0800, you wrote:
I'm aware of that. The tomcat-specific issue is that it won't let you make the transition from https to http on the same session. That's frustrating.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
