Re: Session lost when switching from https to http in Tomcat 5.
Tomcat (starting with Tomcat 4) stores the JSESSIONID cookie as a secure cookie that is tagged for port 443 (or 8443) when the session begins under HTTPS. Browsers are not allowed to send secure cookies under plain HTTP, so your session is lost. For Tomcat 4 or 5 you must start your session under HTTP, then switch to HTTPS to maintain a session across both. Tomcat 3 had a config.xml option to always store JSESSIONID as non-secure. It's a long story. See the mailing list archive for the rants. In the its current state, Tomcat's implementation does not agree with published Best Practices and the *proposed* State Management standard, but the decision was made to err on the side of security. I have modified Tomcat 4 to permit sessions that span HTTP and HTTPS. The changes are not difficult, but you must implement your own mechanism to prevent session hijacking. Non-secure JSESSIONID cookies create a security hole. The committees are supposed address the security vs. state management issue in the next Servlet Spec. Regards, Bob Feretich I have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. The session appears not to be preserved between https and http, ie. after switching from back to http the request.getSession(false) call returns null. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 5 I might have missed? Thanks Anthony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session lost when switching from https to http in Tomcat 5.
Greetings, Your help is greatly appreciated, I have hade a devil of a time with this. I am glad to know this was not caused by an error in my code. Again, thanks very much for your help. Best Regards, Anthony- - Original Message - From: Bob Feretich [EMAIL PROTECTED] To: [EMAIL PROTECTED]; tomcat-user@jakarta.apache.org Sent: Sunday, May 01, 2005 4:48 AM Subject: Re: Session lost when switching from https to http in Tomcat 5. Tomcat (starting with Tomcat 4) stores the JSESSIONID cookie as a secure cookie that is tagged for port 443 (or 8443) when the session begins under HTTPS. Browsers are not allowed to send secure cookies under plain HTTP, so your session is lost. For Tomcat 4 or 5 you must start your session under HTTP, then switch to HTTPS to maintain a session across both. Tomcat 3 had a config.xml option to always store JSESSIONID as non-secure. It's a long story. See the mailing list archive for the rants. In the its current state, Tomcat's implementation does not agree with published Best Practices and the *proposed* State Management standard, but the decision was made to err on the side of security. I have modified Tomcat 4 to permit sessions that span HTTP and HTTPS. The changes are not difficult, but you must implement your own mechanism to prevent session hijacking. Non-secure JSESSIONID cookies create a security hole. The committees are supposed address the security vs. state management issue in the next Servlet Spec. Regards, Bob Feretich I have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. The session appears not to be preserved between https and http, ie. after switching from back to http the request.getSession(false) call returns null. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 5 I might have missed? Thanks Anthony - 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]
Session lost when switching from https to http in Tomcat 5.
I have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. The session appears not to be preserved between https and http, ie. after switching from back to http the request.getSession(false) call returns null. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 5 I might have missed? Thanks Anthony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session lost when switching from https to http in Tomcat 5.
On 4/28/05, Anhony [EMAIL PROTECTED] wrote: I have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. The session appears not to be preserved between https and http, ie. after switching from back to http the request.getSession(false) call returns null. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 5 I might have missed? Thanks Anthony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Please specify version of Tomcat and URLs which you used which caused problems. It is working fine for me on Tomcat 4.1.12,4.1.30,4.1.31. -- rgds Anto Paul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session lost when switching from https to http in Tomcat 5.
I am using Tomcat 5.0.28 Users log into my application from https://xxx.com/login.jsp. When submitted, I check for a valid userID/Password, create a session with getSession(), and then save the userID/Password in a session variable. The validated user is then returned to my main tools page. If the user then selects a link to a non secure page, http://..., I get a return of null when performing getSession( false) when trying to check that the user is valid. Thanks for the help. Anthony - Original Message - From: Anto Paul [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Thursday, April 28, 2005 10:26 AM Subject: Re: Session lost when switching from https to http in Tomcat 5. On 4/28/05, Anhony [EMAIL PROTECTED] wrote: I have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. The session appears not to be preserved between https and http, ie. after switching from back to http the request.getSession(false) call returns null. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 5 I might have missed? Thanks Anthony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Please specify version of Tomcat and URLs which you used which caused problems. It is working fine for me on Tomcat 4.1.12,4.1.30,4.1.31. -- rgds Anto Paul - 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]
Re: Session lost when switching from https to http in Tomcat 5.
Last I knew sessions are not shared between SSL and non-SSL connections by design (as opposed to a bug). Your best bet is probably: 1. Start a session on the non-ssl side 2. Forward the user to the ssl login w/ the session id in the request 3. The ssl login stores the session id and any other important info in a shared persistence layer (i.e. database) and forwards back to the non-ssl side 4. The non-ssl side checks the persistence layer for it's session id and any other info left by the login page. --David Anhony wrote: I am using Tomcat 5.0.28 Users log into my application from https://xxx.com/login.jsp. When submitted, I check for a valid userID/Password, create a session with getSession(), and then save the userID/Password in a session variable. The validated user is then returned to my main tools page. If the user then selects a link to a non secure page, http://..., I get a return of null when performing getSession( false) when trying to check that the user is valid. Thanks for the help. Anthony - Original Message - From: Anto Paul [EMAIL PROTECTED] To: Tomcat Users List tomcat-user@jakarta.apache.org Sent: Thursday, April 28, 2005 10:26 AM Subject: Re: Session lost when switching from https to http in Tomcat 5. On 4/28/05, Anhony [EMAIL PROTECTED] wrote: I have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. The session appears not to be preserved between https and http, ie. after switching from back to http the request.getSession(false) call returns null. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 5 I might have missed? Thanks Anthony - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Please specify version of Tomcat and URLs which you used which caused problems. It is working fine for me on Tomcat 4.1.12,4.1.30,4.1.31. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session lost when switching from https to http in Tomcat 5.
Anhony [EMAIL PROTECTED] wrote: I am using Tomcat 5.0.28 Users log into my application from https://xxx.com/login.jsp. When submitted, I check for a valid userID/Password, create a session with getSession(), and then save the userID/Password in a session variable. The validated user is then returned to my main tools page. If the user then selects a link to a non secure page, http://..., I get a return of null when performing getSession( false) when trying to check that the user is valid. I am using Tomcat 5.0.16. An https session will have a different JSESSIONID than a http session, so Tomcat will think going from one to another is stating a new session. The JESSIONID is stored as a secure cookie when you start from https; get this cookie and re-add it to the response as a non-secure cookie (setSecure(false)), and then redirect to the http page. -- Lynn Hollerman. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
forwarding from HTTPS to HTTP
Hi, I am trying to implement SSL for Tomcat 5.0.30 Java 1.4 latest for selected sites only. I configured a url path pattern: /jsp/login.jsp logging onto this site, SSL works, redirecting to /jsp/index.jsp still uses SSL :-( Requesting java actions are comepletely igonored like /controller?action=LoginAction I would really appreciate if you could help folks. thx anyway Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Tomcat session continuation from https to http
The Tomcat code distinguishes between http and https accesses, with respect to session continuation. Specifically, when HttpServeletResponse.encodeRedirectURL(} or HttpServeletResponse.encodeURL() are called for URL rewriting (client has cookies turned off), if the current servlet is accessed via https and the new URL is accessed via http (or visa versa) HttpResponseBase.isEncodeable(} determines that the sessionId should not be appended to the URL, causing session continuity to be lost. Why? My web application has mostly non-secure pages, but some pages need SSL security. I would like to avoid the SSL overhead on non-secure pages. However, my client sessions must span access to both types of pages. How am I to do this with Tomcat? (The latest level of Tomcat my hosting service supports is Tomcat 4.1.24.) I have noticed, that with cookies turned on, there is no problem maintaining the session. Regards, Bob Feretich - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Session lost on switch from HTTPS to HTTP via JavaScript location replace
Hello, I have a problem with Tomcat 5.0.26 where I need to use JavaScript to set the page location (document.location.href) in order to trigger a page reload. The session gets lost when the protocol changes from HTTP to HTTPS due to the secure setting in the session cookie. I seems Tomcat will create the session cookie as secure when the request was secure. Unless there was a prior redirect this session cookie will then not be available to any unsecure request. In the event of a redirect to unsecure Tomcat undr the hood will take care to update the cookie to become insecure. Is there any way to control this behavior in the configuration? I would like to configure all session cookies to be created as insecure. Or, is there a ay to rewrite the session cookie in its entirety? It cannot be done just with the request, as browsers do not send all cookie attributes back. Any help greatly appreciated. Thanks, Tim _ FREE pop-up blocking with the new MSN Toolbar get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Session lost on switch from HTTPS to HTTP via JavaScript location replace
On Sat, Aug 28, 2004 at 12:53:15PM -0700, Tim Waldner wrote: : The session gets lost when the protocol changes from HTTP to HTTPS : due to the secure setting in the session cookie. : [snip] : Is there any way to control this behavior in the configuration? I would : like to configure all session cookies to be created as insecure. If I understand your question, there's no (realistic) way around this. That's the cookie spec. -QM -- software -- http://www.brandxdev.net tech news -- http://www.RoarNetworX.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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.
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]
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]
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]
RE: Session lost between HTTPS and HTTP
I could be wrong of course :)) -Original Message- From: Filip Hanik Sent: Tuesday, February 04, 2003 9:51 AM 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]
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]
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]
RE: Session lost between HTTPS and HTTP
Hijacking is possible for any man-in-the-middle situation. That's one of the reasons that going https for just the login is a bad idea (tm). --mikej -=- mike jackson [EMAIL PROTECTED] -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]
RE: Session lost between HTTPS and HTTP
for example https://banking.wellsfargo.com, once you are logged on to https, they will not let you access that server using http. filip -Original Message- From: Filip Hanik Sent: Tuesday, February 04, 2003 9:58 AM 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]
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
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
RE: Session lost between HTTPS and HTTP
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
Re: HTTPS to HTTP
As said, I was thinking of the scenario where the *whole* site can be accessed without SSL - no admin links or anything like that. I agree with Craig that if there are any sensitive areas at all it is not safe to reuse the session id - and that before enabling any keep session id option it is vital that the user understands the consequences. In this scenario, the *only* page requiring SSL would be the login page that collects the username and password. (That could be either a dedicated application login page or the login page configured for form-based login. Basic authentication is never an option!). If this condition is met I still don't see that stealing the session id will enable anything that would be considered a risk. The benefit is that it hides the password while gaining any benefits of not using SSL where it is not needed. Having said all that - for our own situation the extra costs of requiring SSL for non-sensitive pages are negligible so everything involving a user authentication is done under SSL. But that may not be true for everyone. John Craig R. McClanahan wrote: On Thu, 9 Jan 2003, John Holman wrote: Date: Thu, 09 Jan 2003 12:56:16 + From: John Holman [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: HTTPS to HTTP Yes, that is clearly a risk. The *whole* web application needs have no risks in order to allow http access to any of it - any sensitive link and it must all be https. (And of course if SSO is enabled *all* web applications for the virtual host must be considered safe). Otherwise I'm not convinced that session stealing is really a problem - though open to counter-arguements. Consider a scenario where you have admin pages that require SSL, and normal pages that can run on either. Assume Tomcat were modified to migrate your session back. Consider the following course of events: * User A logs on, selects link for an admin function, and is switched to SSL for that part. * User A then switches back to non-SSL. Among other things, this means that the session id is now visible in plaintext on the wire. * User B snoops the network, acquires the session id, and submits an SSL request (with the stolen session id) to an admin function. * Server blithely executes the forged request, because login identity is attached to the session id (which is now plaintext -- it wouldn't be if the session had been created under SSL and never allowed to switch back). Once an application has switched from HTTP to HTTPS for a session, it should be programmed to never go back again. John Craig Ralph Einfeldt wrote: But be aware that quite simple changes in the configuration of tomcat can lead to big security holes. Guess what happens if you or somebody else someday decides to switch from basic authentification to form authentifcation and the sysadmin visits the user side and somebody steals the sysadmins session ...) -Original Message- From: David Hemingway [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 12:08 PM To: Tomcat Users List Subject: Re: HTTPS to HTTP Thats is my exact situation. The sysadmin section of teh site is 100% https. but the on the user side there is nothing that sensitive and little harm they could be cause stealing someones session. It would not be worth going to the trouble of stealing the session for the benefit you would get. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
My understanding (at the moment) is that there are two scenarios where sesssion id reuse might be safe: 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]
RE: HTTPS to HTTP
As long as you know what you do and are shure that you (or any other person that may maintain the site in the future) always remember what you have done that may be ok. The risk I see that with such an approach is that it is quite easy to forget about the potential risks of this solution when somebody adds some functionality to the side somewhere in the future that breaks the basic assumption behind this solution. If you use form based login make damn shure that there is no way for an user to edit his password or other sensitive data as this way you can't protect that page against an intruder after the user switched back to http. With form based-login the user is stored in the session and somebody who steals a session is authenticated as far as tomcat is considered. -Original Message- From: John Holman [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 2:02 PM To: Tomcat Users List Subject: Re: HTTPS to HTTP In this scenario, the *only* page requiring SSL would be the login page that collects the username and password. (That could be either a dedicated application login page or the login page configured for form-based login. Basic authentication is never an option!). If this condition is met I still don't see that stealing the session id will enable anything that would be considered a risk. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
I agree with all of this. For functionality like changing the password I'd use a different SSL-only web application, not include that functionality in the mixed application. The user would then have to reauthenticate to change the password - but I'd want them to do that anyway since they may have gone off to lunch leaving an active session on their PC ... John Ralph Einfeldt wrote: As long as you know what you do and are shure that you (or any other person that may maintain the site in the future) always remember what you have done that may be ok. The risk I see that with such an approach is that it is quite easy to forget about the potential risks of this solution when somebody adds some functionality to the side somewhere in the future that breaks the basic assumption behind this solution. If you use form based login make damn shure that there is no way for an user to edit his password or other sensitive data as this way you can't protect that page against an intruder after the user switched back to http. With form based-login the user is stored in the session and somebody who steals a session is authenticated as far as tomcat is considered. -Original Message- From: John Holman [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 2:02 PM To: Tomcat Users List Subject: Re: HTTPS to HTTP In this scenario, the *only* page requiring SSL would be the login page that collects the username and password. (That could be either a dedicated application login page or the login page configured for form-based login. Basic authentication is never an option!). If this condition is met I still don't see that stealing the session id will enable anything that would be considered a risk. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTPS to HTTP
Is there an FTP connector for Tomcat? If so, I would be very interested in it. Thanks, John -Original Message- From: Shah, Sanjay [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 1:03 PM To: 'Tomcat Users List' Cc: 'Craig R. McClanahan' Subject: RE: HTTPS to HTTP Hello Craig: I was reading one of your post in tomcat user archive regarding implementation of FTP protocol under Catalina. One of my requirement is exactly the same. In my case the FTP security and processing needs to be managed on a per customer basis, however this tends to be closely coupled to the web-app side. Infect my FTP processing would re-use underlying classes contained in the client's existing web-app. Hence I would prefer to have a logical mapping between host-customer. Your mapping approach seems like the way to go. Could you please let me know if you were successful in your effort and if so, can you give me some details about settings FtpConnector, FtpRequest, FtpResponse etc.? Your response is greatly appreciated. Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
Hi Bill, Honestly, as a user, I don't feel competent enough with the Tomcat internal architecture to write a patch. However, to me, this is a vital thing missing from the tomcat 4.1.x branch. Quite a few of the sites that I work on require that a session created under https be accessible under http, and as a security measure, we drop our own Secure cookie... and make sure it is present on any pages with confidential information (which we of course make https as well). Because tomcat prevents us from doing this, and because of the lack of a secureCookies feature in 4.1.x, I just keep hacking away at the Connectors code in every new release, and comment out the if statement that prevents the desired functionality (which is NOT an elegant solution). I think there IS a demand for the secureCookies feature, because I have seen several posts for this before, and I just hope that someone who has more knowledge of tomcat's internal workings than myself will figure out the proper way to patch this. -Raiden (and I will be forever grateful to anyone that can do this!) From: Bill Barker Date: 2003-01-10 7:42:35 As the person that implemented the 3.3.2 behavior documented below, I'm more than willing to review a patch to 4.1.x that would implement the same behavior. I just can't bring myself to believe that it's that big of an issue if it's not worth anyone's time to construct a patch. David Hemingway [EMAIL PROTECTED] wrote in message 031c01c2b7ac$a6f50a90$0b7bfea9@w9b1jqmyjsd9ds1">news:031c01c2b7ac$a6f50a90$0b7bfea9@w9b1jqmyjsd9ds1... Hi, I am trying to allow session cookies that created via https to retain the session when stepping down to http, however by default a new session will be made. It seems that a session made under http will sustain if you step up to https but not the reverse. I read in the following document that in tomcat 3.3.2 you can allow a session to be valid via http even if it was created via https: http://jakarta.apache.org/tomcat/tomcat-3.3-doc/serverxml.html#SessionId secureCookie [Tomcat 3.3.2] If true, then Tomcat will mark the Session ID cookie as as Secure if the session is created over a SSL connection. A conforming browser will only send the cookie back to a page that is using SSL. The effect is that if a session is created from a SSL page, than it is not available to any non-SSL pages. SessionId cookiesFirst=true noCookies=false / SessionId noCookies=true / SessionId noCookies=true checkSSLSessionId=true/ I am using tmocat 4.1.18 and I would like to implement this as it will greatly simply a section of my site. I have 2 questions regarding it though. 1 Can anyone tell me how this can be imlpemented in 4.1.18 to being with :-) (I can't find any docs). 2 Does this open up a huge security hole that I am not seeing. I have heard things about session hijacking? Many thanks regards, Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
Raiden, If you really want to maintain the session between HTTPs and HTTP you can do it by writing the link to the insecure page with the session id like this: (using JSP) From the insecure page: form method=post action=http://(youraddress/insecurepage)%=session.getId()% input type=submit value=go insecure/ /form The same thing will work going from insecure to secure. Your session will get dragged around. --- Also, it is interesting to note that a recent Feature of Expresso is the ability to maintain session when going between HTTPS and HTTP. It must be that users need this capability. Dan Raiden wrote: Hi Bill, Honestly, as a user, I don't feel competent enough with the Tomcat internal architecture to write a patch. However, to me, this is a vital thing missing from the tomcat 4.1.x branch. Quite a few of the sites that I work on require that a session created under https be accessible under http, and as a security measure, we drop our own Secure cookie... and make sure it is present on any pages with confidential information (which we of course make https as well). Because tomcat prevents us from doing this, and because of the lack of a secureCookies feature in 4.1.x, I just keep hacking away at the Connectors code in every new release, and comment out the if statement that prevents the desired functionality (which is NOT an elegant solution). I think there IS a demand for the secureCookies feature, because I have seen several posts for this before, and I just hope that someone who has more knowledge of tomcat's internal workings than myself will figure out the proper way to patch this. -Raiden (and I will be forever grateful to anyone that can do this!) From: Bill Barker Date: 2003-01-10 7:42:35 As the person that implemented the 3.3.2 behavior documented below, I'm more than willing to review a patch to 4.1.x that would implement the same behavior. I just can't bring myself to believe that it's that big of an issue if it's not worth anyone's time to construct a patch. David Hemingway [EMAIL PROTECTED] wrote in message 031c01c2b7ac$a6f50a90$0b7bfea9@w9b1jqmyjsd9ds1">news:031c01c2b7ac$a6f50a90$0b7bfea9@w9b1jqmyjsd9ds1... Hi, I am trying to allow session cookies that created via https to retain the session when stepping down to http, however by default a new session will be made. It seems that a session made under http will sustain if you step up to https but not the reverse. I read in the following document that in tomcat 3.3.2 you can allow a session to be valid via http even if it was created via https: http://jakarta.apache.org/tomcat/tomcat-3.3-doc/serverxml.html#SessionId secureCookie [Tomcat 3.3.2] If true, then Tomcat will mark the Session ID cookie as as Secure if the session is created over a SSL connection. A conforming browser will only send the cookie back to a page that is using SSL. The effect is that if a session is created from a SSL page, than it is not available to any non-SSL pages. SessionId cookiesFirst=true noCookies=false / SessionId noCookies=true / SessionId noCookies=true checkSSLSessionId=true/ I am using tmocat 4.1.18 and I would like to implement this as it will greatly simply a section of my site. I have 2 questions regarding it though. 1 Can anyone tell me how this can be imlpemented in 4.1.18 to being with :-) (I can't find any docs). 2 Does this open up a huge security hole that I am not seeing. I have heard things about session hijacking? Many thanks regards, Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
Ralph Einfeldt wrote: Anybody who can listen to your traffic, can hijack a session. He just has to create a request with the same sessionid (either as cookie or in the url). So after you go back from https to http you open the session to an attacker. The risks that are involved with that, depends on the application. I think it would be useful to be able to configure Tomcat to use the same session id when downgrading from https to http. This caters for the case where an application really does not have significant security requirements - the login is needed only to identify the user so that e.g their non-confidential preferences can be applied and it does not matter that others might masquerade as that user. In that case the session may as well be conducted in http (e.g. for performance reasons). However the password itself should always be hidden using https, because it is likely that the user will employ that same password for other applications where security *is* important. Note that when there are risks with the application there should be no http access at all - that's easy enough to arrange. John -Original Message- From: David Hemingway [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 7:59 AM To: Tomcat Users List Subject: HTTPS to HTTP 2 Does this open up a huge security hole that I am not seeing. I have heard things about session hijacking? Many thanks regards, Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
Thats is my exact situation. The sysadmin section of teh site is 100% https. but the on the user side there is nothing that sensitive and little harm they could be cause stealing someones session. It would not be worth going to the trouble of stealing the session for the benefit you would get. Thanks for the comments regards, Dave - Original Message - From: John Holman [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, January 09, 2003 9:44 PM Subject: Re: HTTPS to HTTP Ralph Einfeldt wrote: Anybody who can listen to your traffic, can hijack a session. He just has to create a request with the same sessionid (either as cookie or in the url). So after you go back from https to http you open the session to an attacker. The risks that are involved with that, depends on the application. I think it would be useful to be able to configure Tomcat to use the same session id when downgrading from https to http. This caters for the case where an application really does not have significant security requirements - the login is needed only to identify the user so that e.g their non-confidential preferences can be applied and it does not matter that others might masquerade as that user. In that case the session may as well be conducted in http (e.g. for performance reasons). However the password itself should always be hidden using https, because it is likely that the user will employ that same password for other applications where security *is* important. Note that when there are risks with the application there should be no http access at all - that's easy enough to arrange. John -Original Message- From: David Hemingway [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 7:59 AM To: Tomcat Users List Subject: HTTPS to HTTP 2 Does this open up a huge security hole that I am not seeing. I have heard things about session hijacking? Many thanks regards, Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTPS to HTTP
I don't think that performance is a reason to keep the session after a switch because in the most applications the amount of protocol switches is quite small when compared to the total number of requests within one protocol. -Original Message- From: John Holman [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 11:44 AM To: Tomcat Users List Subject: Re: HTTPS to HTTP In that case the session may as well be conducted in http (e.g. for performance reasons). -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTPS to HTTP
But be aware that quite simple changes in the configuration of tomcat can lead to big security holes. Guess what happens if you or somebody else someday decides to switch from basic authentification to form authentifcation and the sysadmin visits the user side and somebody steals the sysadmins session ...) -Original Message- From: David Hemingway [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 12:08 PM To: Tomcat Users List Subject: Re: HTTPS to HTTP Thats is my exact situation. The sysadmin section of teh site is 100% https. but the on the user side there is nothing that sensitive and little harm they could be cause stealing someones session. It would not be worth going to the trouble of stealing the session for the benefit you would get. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
Yes, that is clearly a risk. The *whole* web application needs have no risks in order to allow http access to any of it - any sensitive link and it must all be https. (And of course if SSO is enabled *all* web applications for the virtual host must be considered safe). Otherwise I'm not convinced that session stealing is really a problem - though open to counter-arguements. John Ralph Einfeldt wrote: But be aware that quite simple changes in the configuration of tomcat can lead to big security holes. Guess what happens if you or somebody else someday decides to switch from basic authentification to form authentifcation and the sysadmin visits the user side and somebody steals the sysadmins session ...) -Original Message- From: David Hemingway [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 12:08 PM To: Tomcat Users List Subject: Re: HTTPS to HTTP Thats is my exact situation. The sysadmin section of teh site is 100% https. but the on the user side there is nothing that sensitive and little harm they could be cause stealing someones session. It would not be worth going to the trouble of stealing the session for the benefit you would get. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
On Thu, 9 Jan 2003, John Holman wrote: Date: Thu, 09 Jan 2003 12:56:16 + From: John Holman [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: HTTPS to HTTP Yes, that is clearly a risk. The *whole* web application needs have no risks in order to allow http access to any of it - any sensitive link and it must all be https. (And of course if SSO is enabled *all* web applications for the virtual host must be considered safe). Otherwise I'm not convinced that session stealing is really a problem - though open to counter-arguements. Consider a scenario where you have admin pages that require SSL, and normal pages that can run on either. Assume Tomcat were modified to migrate your session back. Consider the following course of events: * User A logs on, selects link for an admin function, and is switched to SSL for that part. * User A then switches back to non-SSL. Among other things, this means that the session id is now visible in plaintext on the wire. * User B snoops the network, acquires the session id, and submits an SSL request (with the stolen session id) to an admin function. * Server blithely executes the forged request, because login identity is attached to the session id (which is now plaintext -- it wouldn't be if the session had been created under SSL and never allowed to switch back). Once an application has switched from HTTP to HTTPS for a session, it should be programmed to never go back again. John Craig Ralph Einfeldt wrote: But be aware that quite simple changes in the configuration of tomcat can lead to big security holes. Guess what happens if you or somebody else someday decides to switch from basic authentification to form authentifcation and the sysadmin visits the user side and somebody steals the sysadmins session ...) -Original Message- From: David Hemingway [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 12:08 PM To: Tomcat Users List Subject: Re: HTTPS to HTTP Thats is my exact situation. The sysadmin section of teh site is 100% https. but the on the user side there is nothing that sensitive and little harm they could be cause stealing someones session. It would not be worth going to the trouble of stealing the session for the benefit you would get. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
On Thu, 9 Jan 2003, John Holman wrote: Date: Thu, 09 Jan 2003 12:58:19 + From: John Holman [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: HTTPS to HTTP Ralph Einfeldt wrote: I don't think that performance is a reason to keep the session after a switch because in the most applications the amount of protocol switches is quite small when compared to the total number of requests within one protocol. Just thinking that the overhead of encrypting data when https is used might be a cost that sites with a lot of traffic might prefer to avoid by using http for all but the authentication exchange. The problem with your theory is that its a waste of time to bother doing the encrypted authentication at all -- it adds zero to the security of the overall transaction. In fact, it's worse than that, because it gives you a *false* sense of security. :-). If you're going to support HTTPS-HTTP anyway, you might as well just do the whole appolication non-SSL. John. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTPS to HTTP
Hello Craig: I was reading one of your post in tomcat user archive regarding implementation of FTP protocol under Catalina. One of my requirement is exactly the same. In my case the FTP security and processing needs to be managed on a per customer basis, however this tends to be closely coupled to the web-app side. Infect my FTP processing would re-use underlying classes contained in the client's existing web-app. Hence I would prefer to have a logical mapping between host-customer. Your mapping approach seems like the way to go. Could you please let me know if you were successful in your effort and if so, can you give me some details about settings FtpConnector, FtpRequest, FtpResponse etc.? Your response is greatly appreciated. Thanks -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTPS to HTTP
On Thu, 9 Jan 2003, Shah, Sanjay wrote: Date: Thu, 9 Jan 2003 13:02:32 -0500 From: Shah, Sanjay [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Cc: 'Craig R. McClanahan' [EMAIL PROTECTED] Subject: RE: HTTPS to HTTP Hello Craig: I was reading one of your post in tomcat user archive regarding implementation of FTP protocol under Catalina. One of my requirement is exactly the same. In my case the FTP security and processing needs to be managed on a per customer basis, however this tends to be closely coupled to the web-app side. Infect my FTP processing would re-use underlying classes contained in the client's existing web-app. Hence I would prefer to have a logical mapping between host-customer. Your mapping approach seems like the way to go. Could you please let me know if you were successful in your effort and if so, can you give me some details about settings FtpConnector, FtpRequest, FtpResponse etc.? Your response is greatly appreciated. Thanks I never went any further than a thought experiment to see if it could be done. It also became a much less interesting problem when I remembered that I could just set up a standard FTP server pointed at the same directories, giving me FTP access to the files with zero effort modifying Tomcat. Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTPS to HTTP
Craig, I agree with you 100% but there can be a simple solution to the problem that you just raised..and that is that a new session id is created and mapped in some table when moving from https--http this way user B can not get access to the admin page. ~Sumit On Thu, 9 Jan 2003, John Holman wrote: Date: Thu, 09 Jan 2003 12:56:16 + From: John Holman [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: HTTPS to HTTP Yes, that is clearly a risk. The *whole* web application needs have no risks in order to allow http access to any of it - any sensitive link and it must all be https. (And of course if SSO is enabled *all* web applications for the virtual host must be considered safe). Otherwise I'm not convinced that session stealing is really a problem - though open to counter-arguements. Consider a scenario where you have admin pages that require SSL, and normal pages that can run on either. Assume Tomcat were modified to migrate your session back. Consider the following course of events: * User A logs on, selects link for an admin function, and is switched to SSL for that part. * User A then switches back to non-SSL. Among other things, this means that the session id is now visible in plaintext on the wire. * User B snoops the network, acquires the session id, and submits an SSL request (with the stolen session id) to an admin function. * Server blithely executes the forged request, because login identity is attached to the session id (which is now plaintext -- it wouldn't be if the session had been created under SSL and never allowed to switch back). Once an application has switched from HTTP to HTTPS for a session, it should be programmed to never go back again. John Craig Ralph Einfeldt wrote: But be aware that quite simple changes in the configuration of tomcat can lead to big security holes. Guess what happens if you or somebody else someday decides to switch from basic authentification to form authentifcation and the sysadmin visits the user side and somebody steals the sysadmins session ...) -Original Message- From: David Hemingway [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 12:08 PM To: Tomcat Users List Subject: Re: HTTPS to HTTP Thats is my exact situation. The sysadmin section of teh site is 100% https. but the on the user side there is nothing that sensitive and little harm they could be cause stealing someones session. It would not be worth going to the trouble of stealing the session for the benefit you would get. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTPS to HTTP
On Thu, 9 Jan 2003, Shrotriya, Sumit wrote: Date: Thu, 9 Jan 2003 12:45:20 -0600 From: Shrotriya, Sumit [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Subject: RE: HTTPS to HTTP Craig, I agree with you 100% but there can be a simple solution to the problem that you just raised..and that is that a new session id is created and mapped in some table when moving from https--http this way user B can not get access to the admin page. How would this stop B? After the switch back to HTTP, if a session id works for A it will also work for B. It doesn't matter whether it's a real session id or a mapped session id -- the problem is that B can snoop it in cleartext. ~Sumit Craig On Thu, 9 Jan 2003, John Holman wrote: Date: Thu, 09 Jan 2003 12:56:16 + From: John Holman [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: HTTPS to HTTP Yes, that is clearly a risk. The *whole* web application needs have no risks in order to allow http access to any of it - any sensitive link and it must all be https. (And of course if SSO is enabled *all* web applications for the virtual host must be considered safe). Otherwise I'm not convinced that session stealing is really a problem - though open to counter-arguements. Consider a scenario where you have admin pages that require SSL, and normal pages that can run on either. Assume Tomcat were modified to migrate your session back. Consider the following course of events: * User A logs on, selects link for an admin function, and is switched to SSL for that part. * User A then switches back to non-SSL. Among other things, this means that the session id is now visible in plaintext on the wire. * User B snoops the network, acquires the session id, and submits an SSL request (with the stolen session id) to an admin function. * Server blithely executes the forged request, because login identity is attached to the session id (which is now plaintext -- it wouldn't be if the session had been created under SSL and never allowed to switch back). Once an application has switched from HTTP to HTTPS for a session, it should be programmed to never go back again. John Craig Ralph Einfeldt wrote: But be aware that quite simple changes in the configuration of tomcat can lead to big security holes. Guess what happens if you or somebody else someday decides to switch from basic authentification to form authentifcation and the sysadmin visits the user side and somebody steals the sysadmins session ...) -Original Message- From: David Hemingway [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 12:08 PM To: Tomcat Users List Subject: Re: HTTPS to HTTP Thats is my exact situation. The sysadmin section of teh site is 100% https. but the on the user side there is nothing that sensitive and little harm they could be cause stealing someones session. It would not be worth going to the trouble of stealing the session for the benefit you would get. -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
Thats is my exact situation. The sysadmin section of teh site is 100% https. but the on the user side there is nothing that sensitive and little harm they could be cause stealing someones session. It would not be worth going to the trouble of stealing the session for the benefit you would get. But how does the intruder know in advance that there is nothing valuable on the site? And what about the damage that could be done by a l33t h4x0r d00d just out for a joy-ride? Mixing secure with insecure might be something of an attractive nuisance, I'd think. -- Joel Rees [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
I don't think that performance is a reason to keep the session after a switch because in the most applications the amount of protocol switches is quite small when compared to the total number of requests within one protocol. A possibly stupid question -- is it possible to send graphics raw and text encrypted? (This could leave a trap for obscurationists who send confirmation codes as images, of course.) -- Joel Rees [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
I agree with you 100% but there can be a simple solution to the problem that you just raised..and that is that a new session id is created and mapped in some table when moving from https--http this way user B can not get access to the admin page. Two things you'd have to be really careful about -- Never let the https session id be exposed in an http session. (How do you do that? Tested it under all operating contexts, every browser?) Never let a switch back to https occur without re-verifying the user. (Can this be done seamlessly?) If you used two distinct (sub)domains (for instance, http://user.myapp.com and https://secureuser.myapp.com) and were really careful about the cookie settings for the session ids, might it be workable? Would it require customizing Tomcat? Is it worth the time to test (and the risk that the testers didn't think of everything)? -- Joel Rees [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
On Fri, 10 Jan 2003, Joel Rees wrote: Date: Fri, 10 Jan 2003 10:56:37 +0900 From: Joel Rees [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: HTTPS to HTTP I don't think that performance is a reason to keep the session after a switch because in the most applications the amount of protocol switches is quite small when compared to the total number of requests within one protocol. A possibly stupid question -- is it possible to send graphics raw and text encrypted? Sure ... make your img src=... URLs in the encrypted pages point at absolute http: (not https:) URLs of where the images are. (This could leave a trap for obscurationists who send confirmation codes as images, of course.) If you're going to switch from https-http, you are totally wasting your time messing with https in the first place. It buys you nothing except a *perception* that you are more secure -- that is not the reality. -- Joel Rees [EMAIL PROTECTED] Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
I don't think that performance is a reason to keep the session after a switch because in the most applications the amount of protocol switches is quite small when compared to the total number of requests within one protocol. A possibly stupid question -- is it possible to send graphics raw and text encrypted? Sure ... make your img src=... URLs in the encrypted pages point at absolute http: (not https:) URLs of where the images are. I'm thinking that shipping images raw and text under https might help those who are concerned about performance. Would this open other holes besides the booby-trap I mentioned below? Would shipping the images http open the entire transaction to snooping? (This could leave a trap for obscurationists who send confirmation codes as images, of course.) If you're going to switch from https-http, you are totally wasting your time messing with https in the first place. It buys you nothing except a *perception* that you are more secure -- that is not the reality. Am I way out in left field with this idea? -- Joel Rees [EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTPS to HTTP
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] If you're going to switch from https-http, you are totally wasting your time messing with https in the first place. It buys you nothing except a *perception* that you are more secure -- that is not the reality. You keep repeating this over and over as if it's some sort of Absolute Truth. It's not. As long as you require reauthentication whenever you make the transition to the secure (https) portions of your webapp, there is nothing magically insecure about sending your users back to plain old http when they're navigating the boring parts. It's not rocket science, and people build webapps that do this all the time. Just not with Tomcat. Jeff Schnitzer -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: HTTPS to HTTP
On Fri, 10 Jan 2003, Joel Rees wrote: Date: Fri, 10 Jan 2003 11:22:42 +0900 From: Joel Rees [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: HTTPS to HTTP I don't think that performance is a reason to keep the session after a switch because in the most applications the amount of protocol switches is quite small when compared to the total number of requests within one protocol. A possibly stupid question -- is it possible to send graphics raw and text encrypted? Sure ... make your img src=... URLs in the encrypted pages point at absolute http: (not https:) URLs of where the images are. I'm thinking that shipping images raw and text under https might help those who are concerned about performance. Would this open other holes besides the booby-trap I mentioned below? Would shipping the images http open the entire transaction to snooping? Presumably the sessions would *not* be part of the same session (assuming you haven't modified your Tomcat to allow HTTPS-HTTP transitions on the same session), so you wouldn't be exposing the secure sessionid. (This could leave a trap for obscurationists who send confirmation codes as images, of course.) If you're going to switch from https-http, you are totally wasting your time messing with https in the first place. It buys you nothing except a *perception* that you are more secure -- that is not the reality. Am I way out in left field with this idea? Well, it certainly reduces the performance overhead, but how many extra $$$ does it really cost to buy enough CPU power (or specialized SSL hardware, for very high volume sites) to deal with SSL? Come on guys, we're in a world where gigahertz processors are cheap! If you care about security, buy enough CPU power to run your app secure (once you switch -- a typical ecommerce site can still let the user browse the catalog on regular http and only switch to https during checkout). If you don't care enough about security to do this, don't bother with it at all -- it's just a waste of time. -- Joel Rees [EMAIL PROTECTED] Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTPS to HTTP
On Thu, 9 Jan 2003, Schnitzer, Jeff wrote: Date: Thu, 9 Jan 2003 18:39:34 -0800 From: Schnitzer, Jeff [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: RE: HTTPS to HTTP From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] If you're going to switch from https-http, you are totally wasting your time messing with https in the first place. It buys you nothing except a *perception* that you are more secure -- that is not the reality. You keep repeating this over and over as if it's some sort of Absolute Truth. It's not. As long as you require reauthentication whenever you make the transition to the secure (https) portions of your webapp, there is nothing magically insecure about sending your users back to plain old http when they're navigating the boring parts. There are two problems with this, based on listening to this mailing list for the last five years: * The most common use case for wanting HTTPS-HTTP is to let you log on with HTTPS so your password does not go across the Internet unencrypted, but run the rest of the application on HTTP. Having to reauthenticate again means they don't get what they thought they wanted. * Reauthentication happens in cleartext again, right? So it's subject to snooping and forgery just the same as if you had never bothered with SSL in the first place. Another way to say what you propose is run the post-SSL stuff on a separate session id, so you don't expose the secure session id to attack. That would be fine, but it basically ignores why the large majority of people want to do this in the first place. It's not rocket science, and people build webapps that do this all the time. Just not with Tomcat. None of the concerns about HTTPS-HTTP are specific to Tomcat, or even to Java-based web servers. They are fundamental to the nature of the way HTTP and HTTPS work. Jeff Schnitzer Craig -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTPS to HTTP
From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] * The most common use case for wanting HTTPS-HTTP is to let you log on with HTTPS so your password does not go across the Internet unencrypted, but run the rest of the application on HTTP. Having to reauthenticate again means they don't get what they thought they wanted. My employer has some websites that work like this: Password exchanges are encrypted. Most user interaction is not encrypted. Reauthentication is necessary if you want to edit your credit card information or other personal data. The secure sections of the application are accessed infrequently, so the extra user interaction is not very annoying. * Reauthentication happens in cleartext again, right? So it's subject to snooping and forgery just the same as if you had never bothered with SSL in the first place. Of course not. That would be stupid. Another way to say what you propose is run the post-SSL stuff on a separate session id, so you don't expose the secure session id to attack. That would be fine, but it basically ignores why the large majority of people want to do this in the first place. I'll throw another example in, this one related to the projects I work on: My user accounts exist in a foreign database; the credentials must be kept secure because they could be used on other websites and with other tools to wreak havoc. However, other than requiring one of these accounts, my specific website does not contain sensitive data and there is no compelling need for SSL. It's not rocket science, and people build webapps that do this all the time. Just not with Tomcat. None of the concerns about HTTPS-HTTP are specific to Tomcat, or even to Java-based web servers. They are fundamental to the nature of the way HTTP and HTTPS work. 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. Look, I'm not suggesting that HTTPS-HTTP transitions are for everyone; given how fast and cheap computers are these days, most people are probably better off running their entire applications under SSL even if they aren't worried about security. But there are a number of us out here with high volume sites that *could* benefit from Tomcat allowing the transition. It's not categorically evil. Jeff Schnitzer [EMAIL PROTECTED] The Sims Online -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTPS to HTTP
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.
Re: HTTPS to HTTP
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? I'll bite on this one. But first I'll say that I agree mostly with your and Craig's position on this because in general most people aren't experienced enough with security to make good decisions about what is going on. However this particular issues that has been raised can make use of the HTTPS-HTTP switch securely but with fairly bogus user experience. (My opinion on the user experience, nothing more) Security is made of a number of components, these are generally: Authentication, Access Control,Data Integrity and Confidentiality. Rather than boring people about this,the two important parts to this discussion are essentially Authentication and Confidentiality. We want to use Authentication to allow the right person to access the data and we want to use Confidentiality to make sure that bad people can't see things in transit. _Normally_ authentication is handled once and then confidentiality is used to ensure the tokens remain private. However this is not the only way to do it. Here's an example scenario which I believe matches the desired result and why HTTPS-HTTP _is desirable and secure in this instance_. 1. There are 2 areas of the website, secret stuff and public stuff. 2. Requests and responses from secret stuff is handled by HTTPS 3. Requests and responses from public stuff is handled by HTTP 4. To access the secret stuff, each and every time you try to access the secret stuff from the public stuff you are forced to authenticate. 5. The authentication mechanism uses confidentiality to protect the tokens and any transfer of secret stuff 6. There is nothing in the public stuff that matters if a session is hijacked. This is desirable under the circumstances where you might wish to initially authenticate under HTTPS to protect the tokens _only_, switch to HTTP and keep the session valid either for tracking purposes or merely to display the user name on the page. Given that it is possible to force re-presentation of the authentication tokens each time then I cannot see the security related problem with this scenario. (User experience problems, however) I am happy to have people poke holes in the scenario and tell me what I've done wrong, but it seems correct to me. Would I build it this way ? Probably not, but I generally don't like to double-guess the constraints or problems my customers might have. I could see that this might be useful if there is an enormous user base that accesses a lot of public content and very, very occasionally needs to access very secret information. If 99.9% of the traffic doesn't need to be secured, _and your user base is huge_ and you want the results of the authentication to be available in the public area then this seems like a reasonable request. I will stress however that I feel that providing HTTPS-HTTP session migration within Tomcat is a highly dangerous thing as it will be utilised in the single authentication continued session approach by most people because they will not be able to understand why it's a bad thing. After having said all that, I'm sure it can't be hard to write a SessionMigration object that can contain the data you want to throw over the wall store it in the web application context and pass a parameter through the URL redirection so it can be recovered on the other side. Maybe that's the workaround that's required in this situation. Cheers, -- jon 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. -- Jon Eaves [EMAIL PROTECTED] http://www.eaves.org/jon/ -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: HTTPS to HTTP
Yes, but then you have to specify the protocol for each image in the page. (Somehow the browser has to know that he has to use the right protocol when requesting the image, it may be possible to achieve the same by configuration of tomcat, but that would force a redirect so you won't win much performance) -Original Message- From: Joel Rees [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 2:57 AM To: Tomcat Users List Subject: Re: HTTPS to HTTP A possibly stupid question -- is it possible to send graphics raw and text encrypted? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
HTTPS to HTTP
Hi, I am trying to allow session cookies that created via https to retain the session when stepping down to http, however by default a new session will be made. It seems that a session made under http will sustain if you step up to https but not the reverse. I read in the following document that in tomcat 3.3.2 you can allow a session to be valid via http even if it was created via https: http://jakarta.apache.org/tomcat/tomcat-3.3-doc/serverxml.html#SessionId secureCookie [Tomcat 3.3.2] If true, then Tomcat will mark the Session ID cookie as as Secure if the session is created over a SSL connection. A conforming browser will only send the cookie back to a page that is using SSL. The effect is that if a session is created from a SSL page, than it is not available to any non-SSL pages. SessionId cookiesFirst=true noCookies=false / SessionId noCookies=true / SessionId noCookies=true checkSSLSessionId=true/ I am using tmocat 4.1.18 and I would like to implement this as it will greatly simply a section of my site. I have 2 questions regarding it though. 1 Can anyone tell me how this can be imlpemented in 4.1.18 to being with :-) (I can't find any docs). 2 Does this open up a huge security hole that I am not seeing. I have heard things about session hijacking? Many thanks regards, Dave
RE: HTTPS to HTTP
Anybody who can listen to your traffic, can hijack a session. He just has to create a request with the same sessionid (either as cookie or in the url). So after you go back from https to http you open the session to an attacker. The risks that are involved with that, depends on the application. -Original Message- From: David Hemingway [mailto:[EMAIL PROTECTED]] Sent: Thursday, January 09, 2003 7:59 AM To: Tomcat Users List Subject: HTTPS to HTTP 2 Does this open up a huge security hole that I am not seeing. I have heard things about session hijacking? Many thanks regards, Dave -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Tomcat SSL - Changing URL https to http
I've secure my website with Apache, using the SSL connector. But I have a problem : Imagine I have a page with confidential data to send. This page has the following URL : https://localhost:8443/importantData.html We only have to change manually the URL with http://localhost:8080/importantData.html to avoid the SSL connection? It's not very secure. please give me a hand Thanks Steph
AW: Tomcat SSL - Changing URL https to http
security-constraint web-resource-collection web-resource-nameSecure Portion Of The Site/web-resource-name url-pattern/importantData.html/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint -Ursprüngliche Nachricht- Von: Frédéric LE MAISTRE [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 10. Oktober 2002 10:04 An: [EMAIL PROTECTED] Betreff: Tomcat SSL - Changing URL https to http This page has the following URL : https://localhost:8443/importantData.html We only have to change manually the URL with http://localhost:8080/importantData.html to avoid the SSL connection? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: Tomcat SSL - Changing URL https to http
Forgot to mention that this belongs in web.xml. -Ursprüngliche Nachricht- Von: Ralph Einfeldt Gesendet: Donnerstag, 10. Oktober 2002 10:29 An: Tomcat Users List Betreff: AW: Tomcat SSL - Changing URL https to http security-constraint web-resource-collection web-resource-nameSecure Portion Of The Site/web-resource-name url-pattern/importantData.html/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint -Ursprüngliche Nachricht- Von: Frédéric LE MAISTRE [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 10. Oktober 2002 10:04 An: [EMAIL PROTECTED] Betreff: Tomcat SSL - Changing URL https to http This page has the following URL : https://localhost:8443/importantData.html We only have to change manually the URL with http://localhost:8080/importantData.html to avoid the SSL connection? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat SSL - Changing URL https to http
thanks very much. does CONFIDENTIAL a keyword? - Original Message - From: Ralph Einfeldt [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, October 10, 2002 10:34 AM Subject: AW: Tomcat SSL - Changing URL https to http Forgot to mention that this belongs in web.xml. -Ursprüngliche Nachricht- Von: Ralph Einfeldt Gesendet: Donnerstag, 10. Oktober 2002 10:29 An: Tomcat Users List Betreff: AW: Tomcat SSL - Changing URL https to http security-constraint web-resource-collection web-resource-nameSecure Portion Of The Site/web-resource-name url-pattern/importantData.html/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint -Ursprüngliche Nachricht- Von: Frédéric LE MAISTRE [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 10. Oktober 2002 10:04 An: [EMAIL PROTECTED] Betreff: Tomcat SSL - Changing URL https to http This page has the following URL : https://localhost:8443/importantData.html We only have to change manually the URL with http://localhost:8080/importantData.html to avoid the SSL connection? -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
AW: Tomcat SSL - Changing URL https to http
Sorry, but I didn't understand this question. To learn more about this topic you might have a look at: http://www.onjava.com/pub/a/onjava/2001/08/06/webform.html?page=2 http://kb.atlassian.com/content/orion/docs/deployment/web.xml.html or the servlet spec 2.3 at http://java.sun.com/products/servlet/download.html#specs -Ursprüngliche Nachricht- Von: Frédéric LE MAISTRE [mailto:[EMAIL PROTECTED]] Gesendet: Donnerstag, 10. Oktober 2002 10:50 An: Tomcat Users List Betreff: Re: Tomcat SSL - Changing URL https to http thanks very much. does CONFIDENTIAL a keyword? - Original Message - From: Ralph Einfeldt [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Thursday, October 10, 2002 10:34 AM Subject: AW: Tomcat SSL - Changing URL https to http -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
RE: Tomcat SSL - Changing URL https to http
Disable the connector on 8080 in server.xml if you don't want requests going to that port. In production, you should only have the connectors enabled that you are actually using...anything else should be disabled. Simply comment out the entry in server.xml and restart Tomcat. John -Original Message- From: Frédéric LE MAISTRE [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 4:04 AM To: [EMAIL PROTECTED] Subject: Tomcat SSL - Changing URL https to http I've secure my website with Apache, using the SSL connector. But I have a problem : Imagine I have a page with confidential data to send. This page has the following URL : https://localhost:8443/importantData.html We only have to change manually the URL with http://localhost:8080/importantData.html to avoid the SSL connection? It's not very secure. please give me a hand Thanks Steph -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: Tomcat SSL - Changing URL https to http
thanks a lot - Original Message - From: Turner, John [EMAIL PROTECTED] To: 'Tomcat Users List' [EMAIL PROTECTED] Sent: Thursday, October 10, 2002 2:57 PM Subject: RE: Tomcat SSL - Changing URL https to http Disable the connector on 8080 in server.xml if you don't want requests going to that port. In production, you should only have the connectors enabled that you are actually using...anything else should be disabled. Simply comment out the entry in server.xml and restart Tomcat. John -Original Message- From: Frédéric LE MAISTRE [mailto:[EMAIL PROTECTED]] Sent: Thursday, October 10, 2002 4:04 AM To: [EMAIL PROTECTED] Subject: Tomcat SSL - Changing URL https to http I've secure my website with Apache, using the SSL connector. But I have a problem : Imagine I have a page with confidential data to send. This page has the following URL : https://localhost:8443/importantData.html We only have to change manually the URL with http://localhost:8080/importantData.html to avoid the SSL connection? It's not very secure. please give me a hand Thanks Steph -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tunneling https through http
Rich Catlett wrote: Yes, I am trying to access an https site through a proxy. As I said before I'm asking this question because the error I get on the client side - Unrecognized SSL handshake says, as far as I can tell, that an https connection is being attempted on an http line. I have set debug=99 on the connection, and I am not getting any helpful information on why the connection is failing. But is the proxy you are talking about a reverse proxy or a forward proxy? CONNECT only makes sense with a forward proxy, ie set up use proxy for https in your browser settings. If it works fine direct, but not through the proxy, then the proxy you are using has a problem. If you are trying to use it as a reverse proxy it won't work. The reverse proxy needs to be set up as a receiver of SSL connections, which are then forwarded independantly to Tomcat. Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: tunneling https through http
Yes, I am trying to access an https site through a proxy. As I said before I'm asking this question because the error I get on the client side - Unrecognized SSL handshake says, as far as I can tell, that an https connection is being attempted on an http line. I have set debug=99 on the connection, and I am not getting any helpful information on why the connection is failing. Rich Catlett On Tue, 2002-05-14 at 03:54, Graham Leggett wrote: Rich Catlett wrote: I'm trying to tunnel https through a proxy using the CONNECT method. tomcat 4.1-dev is running with a connector expection an https connection on port 445. CONNECT only makes sense if you need to access an https site through a proxy - there is no https through http happening anywhere. What are you trying to achieve? Regards, Graham -- - [EMAIL PROTECTED]There's a moon over Bourbon Street tonight... -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
tunneling https through http
I'm trying to tunnel https through a proxy using the CONNECT method. tomcat 4.1-dev is running with a connector expection an https connection on port 445. The proxy returns a 200 to the client which then attempts to create the tunneled connection and do a handshake. The error I get is unrecognized ssl handshake, which as far as I can tell is an attempt at an https connection via an http link. My question is has anybody else done this or even can the tomcat connectors do this? I am fairly certain that everything on the client side is correct. Rich Catlett
Re: Session lost when switching from https to http in Tomcat 4
Gurmeet, I'm pretty sure this is because the page you were looking at was cached on your browser. When you clicked refresh, the server returned an updated copy. Because of Tomcat's behavior with https - http, you then lost your session. This has happened to me a ton of times. As developers, we're constantly looking at pages multiple times for testing. One of the best things to do is to create a jsp tag/code that prevents caching in both the document's html and prevent caching at the request level (2 different methods...the request level is the correct way, but MS IE requires both methods). This way, while testing, you never see a cached page. When its time for deployment, you can remove the tags/code that prevents caching if you want to allow it to your users. Les Gurmeet writes: Hi, It might drive me crazy. But I just noticed one thing. I have a JSP with a bean in session scope ---it swtches to https does something switches back to http --- in this jsp in http I call a method on the bean which was there in session , it returns me the value as if it sustained the session, but when I refresh the page it behaves otherwise. I have not applied the patch yet. Any clue. why? Gurmeet -Original Message- From: Manuel Mall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 27, 2002 7:09 AM To: 'Tomcat Users List' Subject: RE: Session lost when switching from https to http in Tomcat 4 Anders, thanks, I will try your patch and hope that the Tomcat developer community will take your suggestion to make this behaviour configurable on board. Manuel -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 26 March 2002 18:38 To: [EMAIL PROTECTED]; Tomcat Users List Cc: Peter Tornberg Subject: Re: Session lost when switching from https to http in Tomcat 4 You are right Manuel, Tomcat 4.0.2 using SSL unfortunately always sets a Secure flag on JSESSIONIDs, which do not (depending on browser) allow you to do this https-http switch. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to this. This is why I have requested this behavior to become an option. The option would actually disable a cookie-RFC compliant feature, but so what, if you cannot get things to work? cheers, Anders - Original Message - From: Manuel Mall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 11:17 Subject: Session lost when switching from https to http in Tomcat 4 Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- 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] -- 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] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Session lost when switching from https to http in Tomcat 4
Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Session lost when switching from https to http in Tomcat 4
You are right Manuel, Tomcat 4.0.2 using SSL unfortunately always sets a Secure flag on JSESSIONIDs, which do not (depending on browser) allow you to do this https-http switch. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to this. This is why I have requested this behavior to become an option. The option would actually disable a cookie-RFC compliant feature, but so what, if you cannot get things to work? cheers, Anders - Original Message - From: Manuel Mall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 11:17 Subject: Session lost when switching from https to http in Tomcat 4 Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- 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: Session lost when switching from https to http in Tomcat 4
Hi, I just read this and tested for my app also wherein I would have the same problem in coming days. Any better way of overcoming this problem other than persisting the session manually. Regards, Gurmeet -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 4:08 PM To: [EMAIL PROTECTED]; Tomcat Users List Cc: Peter Tornberg Subject: Re: Session lost when switching from https to http in Tomcat 4 You are right Manuel, Tomcat 4.0.2 using SSL unfortunately always sets a Secure flag on JSESSIONIDs, which do not (depending on browser) allow you to do this https-http switch. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to this. This is why I have requested this behavior to become an option. The option would actually disable a cookie-RFC compliant feature, but so what, if you cannot get things to work? cheers, Anders - Original Message - From: Manuel Mall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 11:17 Subject: Session lost when switching from https to http in Tomcat 4 Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- 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] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Session lost when switching from https to http in Tomcat 4
Gurmeet, The only known workarounds I know of are handling sessions in URLs or patching the CookieTools class which we did. Anders - Original Message - From: Gurmeet [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 13:51 Subject: RE: Session lost when switching from https to http in Tomcat 4 Hi, I just read this and tested for my app also wherein I would have the same problem in coming days. Any better way of overcoming this problem other than persisting the session manually. Regards, Gurmeet -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 4:08 PM To: [EMAIL PROTECTED]; Tomcat Users List Cc: Peter Tornberg Subject: Re: Session lost when switching from https to http in Tomcat 4 You are right Manuel, Tomcat 4.0.2 using SSL unfortunately always sets a Secure flag on JSESSIONIDs, which do not (depending on browser) allow you to do this https-http switch. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to this. This is why I have requested this behavior to become an option. The option would actually disable a cookie-RFC compliant feature, but so what, if you cannot get things to work? cheers, Anders - Original Message - From: Manuel Mall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 11:17 Subject: Session lost when switching from https to http in Tomcat 4 Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- 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] -- 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: Session lost when switching from https to http in Tomcat 4
Thanks Anders, But as you must be knowing if I implement a HttpSessionBindingListener then it would still be a problem. Can u please elaborate on the patching u did on CookieTool class. Regards Gurmeet -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 6:49 PM To: Tomcat Users List Subject: Re: Session lost when switching from https to http in Tomcat 4 Gurmeet, The only known workarounds I know of are handling sessions in URLs or patching the CookieTools class which we did. Anders - Original Message - From: Gurmeet [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 13:51 Subject: RE: Session lost when switching from https to http in Tomcat 4 Hi, I just read this and tested for my app also wherein I would have the same problem in coming days. Any better way of overcoming this problem other than persisting the session manually. Regards, Gurmeet -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 4:08 PM To: [EMAIL PROTECTED]; Tomcat Users List Cc: Peter Tornberg Subject: Re: Session lost when switching from https to http in Tomcat 4 You are right Manuel, Tomcat 4.0.2 using SSL unfortunately always sets a Secure flag on JSESSIONIDs, which do not (depending on browser) allow you to do this https-http switch. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to this. This is why I have requested this behavior to become an option. The option would actually disable a cookie-RFC compliant feature, but so what, if you cannot get things to work? cheers, Anders - Original Message - From: Manuel Mall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 11:17 Subject: Session lost when switching from https to http in Tomcat 4 Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- 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] -- 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] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
Re: Session lost when switching from https to http in Tomcat 4
Gurmeet, I (or rathe my college), removed the line that appends Secure to JSESSIONIDs. Anders - Original Message - From: Gurmeet [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 14:32 Subject: RE: Session lost when switching from https to http in Tomcat 4 Thanks Anders, But as you must be knowing if I implement a HttpSessionBindingListener then it would still be a problem. Can u please elaborate on the patching u did on CookieTool class. Regards Gurmeet -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 6:49 PM To: Tomcat Users List Subject: Re: Session lost when switching from https to http in Tomcat 4 Gurmeet, The only known workarounds I know of are handling sessions in URLs or patching the CookieTools class which we did. Anders - Original Message - From: Gurmeet [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 13:51 Subject: RE: Session lost when switching from https to http in Tomcat 4 Hi, I just read this and tested for my app also wherein I would have the same problem in coming days. Any better way of overcoming this problem other than persisting the session manually. Regards, Gurmeet -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 4:08 PM To: [EMAIL PROTECTED]; Tomcat Users List Cc: Peter Tornberg Subject: Re: Session lost when switching from https to http in Tomcat 4 You are right Manuel, Tomcat 4.0.2 using SSL unfortunately always sets a Secure flag on JSESSIONIDs, which do not (depending on browser) allow you to do this https-http switch. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to this. This is why I have requested this behavior to become an option. The option would actually disable a cookie-RFC compliant feature, but so what, if you cannot get things to work? cheers, Anders - Original Message - From: Manuel Mall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 11:17 Subject: Session lost when switching from https to http in Tomcat 4 Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- 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] -- 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] -- 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: Session lost when switching from https to http in Tomcat 4
Anders thanks a lot. -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 7:34 PM To: Tomcat Users List Subject: Re: Session lost when switching from https to http in Tomcat 4 Gurmeet, I (or rathe my college), removed the line that appends Secure to JSESSIONIDs. Anders - Original Message - From: Gurmeet [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 14:32 Subject: RE: Session lost when switching from https to http in Tomcat 4 Thanks Anders, But as you must be knowing if I implement a HttpSessionBindingListener then it would still be a problem. Can u please elaborate on the patching u did on CookieTool class. Regards Gurmeet -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 6:49 PM To: Tomcat Users List Subject: Re: Session lost when switching from https to http in Tomcat 4 Gurmeet, The only known workarounds I know of are handling sessions in URLs or patching the CookieTools class which we did. Anders - Original Message - From: Gurmeet [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 13:51 Subject: RE: Session lost when switching from https to http in Tomcat 4 Hi, I just read this and tested for my app also wherein I would have the same problem in coming days. Any better way of overcoming this problem other than persisting the session manually. Regards, Gurmeet -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, March 26, 2002 4:08 PM To: [EMAIL PROTECTED]; Tomcat Users List Cc: Peter Tornberg Subject: Re: Session lost when switching from https to http in Tomcat 4 You are right Manuel, Tomcat 4.0.2 using SSL unfortunately always sets a Secure flag on JSESSIONIDs, which do not (depending on browser) allow you to do this https-http switch. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to this. This is why I have requested this behavior to become an option. The option would actually disable a cookie-RFC compliant feature, but so what, if you cannot get things to work? cheers, Anders - Original Message - From: Manuel Mall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 11:17 Subject: Session lost when switching from https to http in Tomcat 4 Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- 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] -- 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] -- 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] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Session lost when switching from https to http in Tomcat 4
Anders, thanks, I will try your patch and hope that the Tomcat developer community will take your suggestion to make this behaviour configurable on board. Manuel -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 26 March 2002 18:38 To: [EMAIL PROTECTED]; Tomcat Users List Cc: Peter Tornberg Subject: Re: Session lost when switching from https to http in Tomcat 4 You are right Manuel, Tomcat 4.0.2 using SSL unfortunately always sets a Secure flag on JSESSIONIDs, which do not (depending on browser) allow you to do this https-http switch. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to this. This is why I have requested this behavior to become an option. The option would actually disable a cookie-RFC compliant feature, but so what, if you cannot get things to work? cheers, Anders - Original Message - From: Manuel Mall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 11:17 Subject: Session lost when switching from https to http in Tomcat 4 Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- 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] -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
RE: Session lost when switching from https to http in Tomcat 4
Hi, It might drive me crazy. But I just noticed one thing. I have a JSP with a bean in session scope ---it swtches to https does something switches back to http --- in this jsp in http I call a method on the bean which was there in session , it returns me the value as if it sustained the session, but when I refresh the page it behaves otherwise. I have not applied the patch yet. Any clue. why? Gurmeet -Original Message- From: Manuel Mall [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 27, 2002 7:09 AM To: 'Tomcat Users List' Subject: RE: Session lost when switching from https to http in Tomcat 4 Anders, thanks, I will try your patch and hope that the Tomcat developer community will take your suggestion to make this behaviour configurable on board. Manuel -Original Message- From: Anders Rundgren [mailto:[EMAIL PROTECTED]] Sent: Tuesday, 26 March 2002 18:38 To: [EMAIL PROTECTED]; Tomcat Users List Cc: Peter Tornberg Subject: Re: Session lost when switching from https to http in Tomcat 4 You are right Manuel, Tomcat 4.0.2 using SSL unfortunately always sets a Secure flag on JSESSIONIDs, which do not (depending on browser) allow you to do this https-http switch. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6983 A Macintosh using IE 5 cannot even obtain a _standard_ SSL jsession due to this. This is why I have requested this behavior to become an option. The option would actually disable a cookie-RFC compliant feature, but so what, if you cannot get things to work? cheers, Anders - Original Message - From: Manuel Mall [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 26, 2002 11:17 Subject: Session lost when switching from https to http in Tomcat 4 Has the session semantic changed between Tomcat 3 and Tomcat 4? We have a servlet/JSP application in which users establish their servlet session using https but conduct the rest of their interactions using http. This works fine under Apache 1.3.22 with Tomcat 3.2.1 connecting using ajp12. After upgrading to Tomcat 4.0.3 now using ajp13 the session appears not to be preserved between https and http, ie. after switching back to http the request.getSession(false) call returns null. This seems to indicate that the session tracking mechanism has changed between Tomcat 3 and Tomcat 4. Can anyone shed light on this for me? Is this expected? Is there a workaround/configuration/setting in Tomcat 4 I might have missed? Thanks Manuel -- 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] -- 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]
Come on and help me - Tomcat 4 ssl - Can't connect with https ot http now!
Hi again , Well my problem stems from migrating from Tomcat 3.2.3 to Tomcat 4 . Thus i wanted to set up a secure tomcat 4 server utilising SSL , I have installed the JSSE support and placed the the 3 jars into jdk installation/jre/lib/ext dir . The CA'S and CERT'S have been self-created( Using Keytool) and my keys and certs placed in tomcat 4 home/keys Folder to help tomcat locate my .Keystore that is named keys. Thus my Keystore is called bbnpakeys in the tomcat home/keys/bbnpakeys Thus i hoped that the keystore called keys would locate the server cert as i have configured the SSL Connector via tomcat 4 home /conf/server.xml. I have uncommented the connector/ in question. !-- Define an SSL HTTP/1.1 Connector on port 8443 (Uncommented this entry)-- Connector className=org.apache.catalina.connector.http.HttpConnector port=8443 minProcessors=5 maxProcessors=75 enableLookups=true acceptCount=10 debug=0 scheme=https secure=true Factory className=org.apache.catalina.net.SSLServerSocketFactory clientAuth=false keystoreFile=keys/bbnpacert keystorePass=test123 protocol=TLS/ /Connector Thus via IE.5 signed my own cert as CA. Used keytool utility to export my created cert and imported to IE.5 using base64 encoded format into a file called bbnpa.cert into Trusted Root Certification. Thus on re-start on startup script and typing https://localhost:8443/ . I get a Dialog box with the Yellow Box Icon it try's to connect to site 127.0.01 but then a IE.5 page cant be dispayed. I can't use Mozilla as i haven't dnd the cert or imported yet but when i try any other ip address i get connection refused while attempting a connection. Please help as it's delaying other work. NB Tomcat 4 is running from the startup script. Cheers Chuck Amadi -- To unsubscribe: mailto:[EMAIL PROTECTED] For additional commands: mailto:[EMAIL PROTECTED] Troubles with the list: mailto:[EMAIL PROTECTED]
how can I fix this Https vs. Http problem
hi I know I've gotten a response to this question but I'm still somewhat in the dark. My problem if you weren't the one responding to it or if you didn't get a chance to read it is this I have a website https://mysite.com:8443. when I delete this the s from https and the port number from the url I get access to my content over a nonsecure connection. I was told this is because I'm using the securehost as the default host. I'm still pretty new to tomcat so I was wondering if anyone could tell me roughly how I would have to go about fixing this, thanks. -Pete
Preserving session state from https to http on tomcat
Hi, I am using form login and I'd like to send my username/password via https to the server. That can be easily accomplished by setting up the https connection on port 8443 on tomcat. The problem is after logging in, I'd like to switch back to http with the user login state preserved from the https session. But alas, switching from https to http wipes out session info on Netscape (4.7). When my post login jsp pages reference the previously set session login object via http, null is returned. However, if I stay in https, everything is fine. I know bea weblogic has a solution where the server can be set to inhibit the server port number from being included in the cookie sent back to Netscape. This way only the domain name is sent. But I can't find that a similar setting in Tomcat. Any advice on this would be greatly appreciated. Thanks Ben Wong
Switching between HTTPS and HTTP
I've implemented a sample web application which implements the common use of Form Based Login: if the user tries to access a protected resource and is not authenticated yet, he receives a login form. After authentification he gains access to the protected resource. So far everything is allright and my application behaves as expected (with Tomcat 4b1). To make the transmission of username/password secure, I'd like to restrain access to the login form so that it can be accessed only via SSL. But this is the *only thing I'd like to secure with SSL, everything else should be accessible via http. My deployment descriptor is attached. My PROBLEM is now that Tomcat doesn't switch between http and https respectively. If the initial access to the protected resource is via http, also the login form is accessed via http, *although I required secure access in the deployment descriptor. If I access the login form via https://sample.org/login.html a secure connection is established, but j_security_check sends me nowhere. Am I missing something? Why does Tomcat not switch automatically? Can I switch manually? -martin ps: Sorry if this had been on the list, but I wasn't able to find something like this in the (hardly usable) archive. ~~ web-app !-- Define a Security Constraint on the Login Page -- security-constraint web-resource-collection web-resource-nameLogin Page/web-resource-name url-pattern/login.html/url-pattern /web-resource-collection user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint !-- Define a Security Constraint on the protected area -- security-constraint web-resource-collection web-resource-nameProtected Area/web-resource-name url-pattern/protected/*/url-pattern /web-resource-collection auth-constraint role-nameuser/role-name /auth-constraint /security-constraint !-- Define the Login Configuration for this Application -- login-config auth-methodFORM/auth-method form-login-config form-login-page/login.html/form-login-page form-error-page/login-error.html/form-error-page /form-login-config /login-config /web-app - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: HTTPS to HTTP proxying
Any particular reason you're using a proxy instead of Tomcats built in HTTPS support? (it came with 3.2 so you need to get that version if you're not already using it). Regards, Stefan. -Original Message- From: Geoff Lane [mailto:[EMAIL PROTECTED]] Sent: 29. janar 2001 23:31 To: [EMAIL PROTECTED] Subject: HTTPS to HTTP proxying Ok, so I have a situation where we are doing an HTTPS to HTTP proxy. Essentially a proxy recieves the HTTPS request, makes an HTTP request to the server with Tomcat running standalone and then the response is returned through the proxy back to the user. So, I access something like: https://somehost/index.html and there is a redirect in it like: out.sendRedirect( "nextpage.html" ); Tomcat in this case will return the user to http://somehost/nextpage.html (notice no https). This makes some sense because Tomcat sees the scheme as HTTP not HTTPS. The odd part though is that this same setup worked with Java Web Server. Anyone know how to handle this other than rewriting all of the redirects to absolute URLs? Thanks. -- Geoff Lane [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: HTTPS to HTTP proxying
Because it allows us to have multiple machines serving one URL without having multiple SSL certificates. It also offloads SSL encryption to dedicated hardware. Those are the main reasons. Stefn F. Stefnsson wrote: Any particular reason you're using a proxy instead of Tomcats built in HTTPS support? (it came with 3.2 so you need to get that version if you're not already using it). Regards, Stefan. -Original Message- From: Geoff Lane [mailto:[EMAIL PROTECTED]] Sent: 29. janar 2001 23:31 To: [EMAIL PROTECTED] Subject: HTTPS to HTTP proxying Ok, so I have a situation where we are doing an HTTPS to HTTP proxy. Essentially a proxy recieves the HTTPS request, makes an HTTP request to the server with Tomcat running standalone and then the response is returned through the proxy back to the user. So, I access something like: https://somehost/index.html and there is a redirect in it like: out.sendRedirect( "nextpage.html" ); Tomcat in this case will return the user to http://somehost/nextpage.html (notice no https). This makes some sense because Tomcat sees the scheme as HTTP not HTTPS. The odd part though is that this same setup worked with Java Web Server. Anyone know how to handle this other than rewriting all of the redirects to absolute URLs? Thanks. -- Geoff Lane [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] -- --- Geoff Lane [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
