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]

Reply via email to