Heey, now that's an answer I can deal with! ; ) That's really good to know! I will now do some research on how to configure Tomcat or my app code along these lines.
Thank you Ian. -----Original Message----- From: Daniel Brown [mailto:[EMAIL PROTECTED]] Sent: Tuesday, February 04, 2003 2:54 PM To: Tomcat Users List Subject: RE: Session lost between HTTPS and HTTP Cookies can be set 'secure' (Cookie.setSecure(true)). Secure cookies are only sent to servers by browsers over a secure connection. When Tomcat starts a new session, it sets the cookie to be secure if the session is opened over a secure connection. This seems to fit with everything so far observed: if a session starts using an http: URL, it's available over http: and https: connections. If the session starts over https:, it's available over https: only. This also fits with how one would hope this would work from a security point of view. Dan. > -----Original Message----- > From: Zabel, Ian [mailto:[EMAIL PROTECTED]] > Sent: 04 February 2003 18:06 > To: 'Tomcat Users List' > Subject: RE: Session lost between HTTPS and HTTP > > > Hm, I understand what you're saying, and I agree. > > But, this used to work fine before Tomcat. ServletExec maintained our > sessions across HTTP and HTTPS. > > I don't know how Tomcat deals with this, which I guess is why I'm > asking the > list. > > One thing I have discovered by using a bit of a sniffer locally is that > Internet Explorer simply does not send the jsessionid cookie created in > HTTPS to the HTTP server. To me, this looks like a choice IE is making. > > If cookies are not to be shared across HTTP and HTTPS server, I would > appreciate a link to a specification or some documentation, if > anyone knows > where it is. > > Ian. > > -----Original Message----- > From: Filip Hanik [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 12:58 PM > To: Tomcat Users List > Subject: RE: Session lost between HTTPS and HTTP > > maybe you misunderstood me. > > if I want to pretend that I am you, all I have to do is to put a network > packet sniffer between your computer and your bank, look up your > session Id > and then make a request to your bank server using your sessionId. So I am > not switching domain. > > Filip > > -----Original Message----- > From: Zabel, Ian [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 9:55 AM > To: 'Tomcat Users List' > Subject: RE: Session lost between HTTPS and HTTP > > > Cookies are only valid for a domain though. So if the cookie was > created on > http://banksite.com it will be valid for https://banksite.com as > well. It is > the same website. Banksite.com resolves to the same IP address either way. > It's just a protocol switch. > > You session id will never be sent to a third party server. > > If you go to http://www.bankaffiliate.com and click on a link to > https://banksite.com you will have two different sessions, two different > cookies. Hijacking in that way is not possible. > > Ian. > > -----Original Message----- > From: Filip Hanik [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 12:51 PM > To: Tomcat Users List > Subject: RE: Session lost between HTTPS and HTTP > > This scenario will convince you...maybe :) > > 1. You enter a bank on non secure page- HTTP > 2. You log in and start messing with your accounts > 3. Then you go back to HTTP and somebody can hi-jack your sessionID > 4. They use that ID to go back to HTTPS and now have access to > your account > information. > > For security purposes, I believe Tomcat must use a different > sessionId when > you are in secure mode. Because this ID is encrypted using SSL on HTTPS > mode. > > Filip > > -----Original Message----- > From: Zabel, Ian [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 9:47 AM > To: 'Tomcat Users List' > Subject: RE: Session lost between HTTPS and HTTP > > > As far as I know, http://www.app.com/ and https://www.app.com/ > are supposed > to be allowed to share cookies on standard ports. > > http://w6.metronet.com/~wjm/tomcat/2000/Dec/msg00626.html > > Ian. > > -----Original Message----- > From: Filip Hanik [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 12:40 PM > To: Tomcat Users List > Subject: RE: Session lost between HTTPS and HTTP > > yeah, it is a security issue I believe. Not sure how tomcat does that, but > it shouldn't allow a session that was created on HTTPS to switch to HTTP. > > Filip > > -----Original Message----- > From: Zabel, Ian [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, February 04, 2003 9:35 AM > To: [EMAIL PROTECTED] > Subject: Session lost between HTTPS and HTTP > > > All; > > > > We are having a chronic problem that is causing a lot of trouble with our > application's users. > > > > In our app, we authenticate users on our HTTPS server and then serve the > homepage also on HTTPS. All links on the homepage to the other > pages in our > app switch the user to the same url on HTTP. If a user's session > is created > on HTTPS (https://www.app.com <https://www.app.com/> ), when they are > switched over to HTTP (http://www.app.com <http://www.app.com/> ) the > session cookie is not sent by the browser and they therefore lose their > session. > > > > NOTE: This is not a problem if the user's session is created on HTTP. The > session is created on HTTP, they authenticate over HTTPS and then are > switched back to HTTP, and their session is maintained with no problems. > > > > Our workaround has been to pass the jsessionid on the url wherever we can, > but there are places we can't do this. > > > > We did not start having this problem until we switched from > Apache/ServletExec to Apache/Tomcat4.0.x/mod_jk. > > > > We are using Apache with OpenSSL to serve our HTTPS pages. > > > > Is it valid for a cookie created on HTTPS to be sent to the same exact URL > on HTTP? > > > > Ian. > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
