Re: sessions, security, and the RFCs
Ralph, I could not find anything that disallow switching between https and http in any order while maintaining. Although not a particularly good idea, it is anyhow used out there to protect passwords but be less protective about the session. I think that security issues should be dealt with as options to not outlaw schemes that actually are used. cheers, Anders - Original Message - From: Ralph Einfeldt [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Wednesday, April 03, 2002 09:28 Subject: AW: AW: AW: sessions, security, and the RFCs I can't find in the spec that the session shall be maintained if you switch from http to https. Can you provide a reference? Wouldn't this be as dangerous as to keep the session after you go back from SSL to non-SSL ? As I see it, this would open the door to anyone who could listen to the http network traffic to steel the secure session. | SRV.7.1.2 SSL Sessions | Secure Sockets Layer, the encryption technology | used in the HTTPS protocol, has a mechanism built | into it allowing multiple requests from a client | to be unambiguously identified as being part of a | session. A servlet container can easily use this | data to define a session. | 12.8 ... | The container must at least use SSL to respond to | requests to resources marked integral or confidential. | If the original request was over HTTP, the container | must redirect the client to the HTTPS port. -Ursprüngliche Nachricht- Von: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 2. April 2002 18:47 An: Tomcat Users List Betreff: Re: AW: AW: sessions, security, and the RFCs snip/ Servlet 2.3 (basis for Tomcat 4.x) added some specific requirements (such as the ability to redirect from the non-SSL port to the SSL port and maintain the session). snip/ Note -- anyone who goes from the SSL port back to the non-SSL port has just created a security hole. -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: sessions, security, and the RFCs
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.) IMHO, HTTP session cannot do authentication. That is the job of SSL/TLS and client certificates. There is nothing in the session that can prevent "hostile takeover". I think that even HTTPS cannot guard against this. Unless server fixes Session-ID to Client-IP upon successful creation of session... Nix.
RE: sessions, security, and the RFCs
I am not sure which RFC you are referring to. It appears to me that the Session semantic Tomcat should implement has nothing (directly) to do with cookies, etc.. Tomcat implements sessions because the Java Servlet specification requires it to do so. Shouldn't the question therefore be what session semantic/scope/rules does the Java Servlet Spec impose and if Tomcat's implementation is conformant to this specification? I don't have the Servlet 2.3 specification in front of me but scanning the 2.2 specification there is no mention of the session scope with respect to https vs http. It only states that a session (it's attributes) is scoped to a servlet context. One conclusion from this could be that if a servlet in the same servlet context is invoked with the same "JSESSIONID" it belongs to the same session independent if it was invoked through a http or https request. Obviously this is the approach taken by Tomcat 3.2.x. It would be interesting to learn why the Tomcat designers have chosen to change this in Tomcat 4. Manuel -Original Message- From: Joel Rees [mailto:[EMAIL PROTECTED]] Sent: Wednesday, 27 March 2002 15:12 To: Tomcat Users List Subject: sessions, security, and the RFCs I've been watching the conversation on https, http, session switching, and so forth. If I followed this right, it sounds as if Tomcat 4, in dropping session information on the switch, is being RFC compliant. ... -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: sessions, security, and the RFCs
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]
