Re: https -- http session problem
I ran into this issue about 2 years ago and posted the same question. Had an application which had 3 different types of users: One group should be authenticated using https only to protect password, then switch to http, but sometimes switch back to https again. Other group should be authenticated over https and stay secure (to prevent possibility of hijacking) Last group should only connect over http, no switching. In the end I had to do code around it by doing session-migration. Basically, a simple container where the httpsession attributes were saved in a migrating session object. Resources was configured as secure and unsecure and if the current connection did not match the requested resources' security level, the session would migrate. The sequence was something like this: Httpsessions attributed was saved, a one time unique key was assigned, session was invalidated, user was redirected to opposite protocol with unique key as request parameter. New HttpSession created, session attributes restored, migrating session object destroyed. forwarded to original requested resource. This could work both ways (http to https) but there is no reason since tomcat keeps non-secure cookies in secure domain. And this migration only has to be done once, since the cookie is valid in both domains from now on. It did create a tiny bit of overhead, but with an app. where users log in once and stay connected for long periods of time this turned out to be insignificant. Not the best solution, but with deadline looming it did the job. Later, when switching with Struts, this ported nicely(if you can call it that) by extending sslext. In the end I wish this was covered by the servlet spec. Does anybody know how other containers behave(Jetty, Resin, etc)? -Henrik Bentel Adam Hardy [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On 11/17/2003 05:15 PM Andrew Mottaz wrote: Also, as far as I can see, the java community has decided that once you start a secure session, you should stay in a secure session, for various security reasons. Are you doing a secure login and then redirecting back to http afterwards? Imagine the following scenario -- A web site has different levels of user access. The difference between the users is what products they can see. The data is not terribly sensitive. However, the log-in should be secure for several reasons -- 1) For the users perception -- people do not like the This form is not secure message when logging in. 2) Capturing a user id and password is worse than hijacking one session. [snipped] Also -- this is the standard for Tomcat -- not Java --( it may be in the servlet/jsp spec -- but if so, it is a new addition). Other Java based app servers treat this differently. [snipped] Again -- Just my 2 cents -- Is there a security issue I'm missing? If the argument is that you should NEVER go from secure to non-secure, the Tomcat solution does not assure that. It only means that you have to go non-secure, secure, and then non-secure. That seems quite arbitrary to me. I'm not sure I would put the argument in those terms - obviously you can go from secure to non-secure via redirects, but tomcat is not going to be nice about it, i.e. wave your cookies goodbye. There is new stuff in the spec related to secure sessions, but I'm not sure if it involves cookies. The issue is about encrypting the form-based CMS login form and in bugzilla it didn't get much sympathy: http://issues.apache.org/bugzilla/show_bug.cgi?id=23970 I assume the issue was discussed in depth but I couldn't find it on the tomcat-dev list. Perhaps it was discussed by JCP somewhere else while writing the spec. If anyone who is on the dev list knows, I'd love to read the discussion. You'll have to go back at least two years to get the tomcat-dev discussion ;-). At the moment, the Tomcat-Developer's don't believe that there is anything to discuss :). Also, the Servert-2.4 spec has already gone 'final' (not that I get a chance to see it :(), so all you can do now is to lobby for the whenever Servlet-2.5 Spec. The spec is about to go final after which any change of the issue is doomed, unfortunately IMHO. I'd gladly lend my voice to any last-ditch attempt to get it changed. Adam -- struts 1.1 + tomcat 5.0.12 + java 1.4.2 Linux 2.4.20 RH9 - 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]
better configuration for Apache and Tomcat?
Hi Im having some performance problems with my apache/tomcat setup and I'm looking for ideas. first, my setup. I'm running apache 2 with tomcat 4.1.24, mod_jk2. My webapp serves content over both http and https. 1 coyote connector is used to handle both secure and unsecure requests. Static content is served by apache, dynamic content by my webapp. I have 2 virtual hosts in apache, one for http and on for https. mod_jk2 loadmodule is declared in root host of apache, along with all directory directives for static content. the 2 virtualhosts(ip based) does very little. The https virtual host uses pretty much the default configuration that comes with the source(some basic sessioncache, really long chiperSuite directive and so on). Certificate is self signed based on 1024 bit RSA key. Now, even when I'm just loadtesting retrieval of an image(which should involve apache only), I see a lot of mod_jk errors of can't find child in scoreboard?? And, even when removing mod_jk the performance stinks. So what I'm looking for is the following: 1. A way to not have connector involved if request is only for static resources. 2. If request is for static resource(art, css, javascripts, which all have a defined alias and directory directive) ssl check should become really lax, no checking for much. I don't want to generate absolute URLs in my pages so that they can be retrieved over http, was hoping there was a way in apache to do this.(yes, I probably should have asked this in mod_ssl user group, but if anybody here konws a lot easier) 3. more of a question: should I configure 2 coyote connectors, one for http and one for https in tomcat? Even when apache is doing all the certificate management? hope someone can help Henrik Bentel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem with session tracking and redirection http--- https
One of my problems is that I can't find anything in the servlet or tomcat documentation that mentiones any of this behaviour. If there is any, please send me the link. Also, since any time session tracking is used it can be picked up by someone, all use of https should stay strictly under https(ok, I'm over doing it). So basically if a webapp has any sensitive information, it should solely use https protocol for all transmissions, if using session tracking? I don't see why the servlet container should force this behaviour. Shouldn't it be up to the developer to determine what is a security issue and not? Just like JSP doesn't neccesseraly force the separation of business logic and content, just allowing it, should the servlet container force a restrictive behaviour of session tracking? A lot of web sites don't want the over head of sending everything over https. Only parts of it for secure user validation. But they still want session tracking. Just as a simple example: So let's say you use the existence of an http session as a validation for a logged in user, but you don't store any vital information. And you only allow http sessions to be created under https protocol to secure the submition of password. Beyond that point, no sensitive data is shared, so users can be redirected back to http protocol. With tomcat 4, the only way to use the same method would be to create a http seesion for every http request, then redirect to https, add some kind of validation flags in the session object, then redirect back. This to me is worse, as a DoS attack could force the servlet container to create a http session for every Request, really putting a strain on your container. The example probably isn't a good example for how a typical website enforces secure validation, but I just want to raise the point that the hole is still there, since sessions created under http are available in all schemes. It could just as easily be misused by a developer. From: Craig R. McClanahan [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Fri, 18 Oct 2002 21:48:36 -0700 (PDT) On Fri, 18 Oct 2002, Maninder S Batth wrote: Date: Fri, 18 Oct 2002 19:28:59 -0700 From: Maninder S Batth [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https please correct me if i am wrong. Session id could be hijacked anytime if it is transmitted as clear text. so once user has loged in , and user gets new session id , this session id could be sniffed and the person can still be impersonated.?? Yes. how is this related to https--http transitiion? If the session was originally established on the https connection, the session id has never been transmitted in the clear, so it cannot be hijacked except when the application accepts a non-https request for that session (or the attacker can impersonate an existing SSL session, in which case we've all got much bigger problems). If the session was originally established under https, but the application switches back to http, the session id is transmitted in the clear from that point on, and is subject to hijacking. This is the logical flaw we discussed earlier this week with regards to a request to accept the login screen on https (to avoid the password being transmitted in the clear) and then switch back to http for the remainder of the session. From the security point of view, this is worse than useless (worse because it gives you a false sense of confidence). Craig Craig R. McClanahan wrote: On Fri, 18 Oct 2002, Henrik Bentel wrote: Date: Fri, 18 Oct 2002 23:07:17 + From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https yeah, I always encode the redirection URL. it's waird that it works if the session is created which under http, but not under https. bug maybe? Nope ... avoidance of a huge security hole. Once a session is accessed via https, it should never ever be allowed to be accessed from http again. The reason for this is that the session id is transmitted in clear text, so anyone who can snoop the network can hijack your session and impersonate the originally authenticated user (even if that user originally authenticated on an encrypted channel). Do not, under any circumstances, design applications that depend on maintaining session state across an https -- http transition. Craig McClanahan -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org -- Your favorite stores, helpful shopping tools and great gift ideas
Re: problem with session tracking and redirection http--- https
Another weird behaviour I just discovered is the following: If a httpsession is created by a servlet processing a request sent under(scheme) http, then redirects to https, the session is available to the servlet processing in https. In other words, it stays put. HOWEVER, if a httpsession is created by a servlet processing a request under https, and then redirects to http, the session is not available. But if one redirects back to https agin, the session is available. Also, if you , after redirecting to http(where no session is to be found) create a new session, and then redirect back to https, the original session is lost and the new session created in http scheme is the current one. In tomcat3.3, session created in either schemes(http or https) stays put when redirecting. I haven't found anything in the servlet specification that mentiones anything about this behaviour. From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Thu, 17 Oct 2002 04:45:21 + ok, I see your point. My approach is that I only use https to scramble the login request itself, so that a login password cannot be read,or sniffed, in clear text(it probably still can, if someone really, really tries). Nothing critical is stored in the http session itself. A lot of websites do something similar, where only the password part is secure, and subsequent pages are insecure. and to change password, the old one has to be entered. I guess I'm a bit of a loss for a better way to do this?? Any well known approaches out there? -Henrik From: Jacob Kjome [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Wed, 16 Oct 2002 23:33:41 -0500 This is the way Tomcat 4.x.x is made to work. The reason for this is security. I think it can be assumed that you were under https for a reason. Maybe you entered your cedit card info and are storing that in the session until the final submit. Now, if you stayed in the same session when moving to http from https, your session id is in plain text. This can be hijacked by anyone sniffing network packets. Once they have your session id, theoreticaly, they have full access to everything you entered in that session including your credit card info. This is a *huge* security issue and Tomcat. Even if Tomcat-3.3.x allows you to do this, you would be wise to dump the session on your own before moving to http for your users' security. Obviously, this requires that you rethink some of your application flow, but Tomcat-4.x.x is doing the right thing here. Jake At 02:28 AM 10/17/2002 +, you wrote: Help! I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also tried 4.0). My problem is that for some reason the httpsession is lost after redirection from https to http. I run apache in front of tomcat to handle static content plus certificate. My webapp depend on the ability to login a user of secure connection then redirect to an unsecure connection. I do the usual res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to http protocol (to the same webapp context) the http session is null. My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat version and of course the tomcat conf. files. I've tried both the Coyote connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am going insane. My server.xml file is close to the default one, I've only added my context(defining docbase and such). For 3.3 this worked like a charm. Anyone?? -Henrik _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org _ Get a speedy connection with MSN Broadband. Join now! http://resourcecenter.msn.com/access/plans/freeactivation.asp -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org
Re: problem with session tracking and redirection http--- https
yeah, I always encode the redirection URL. it's waird that it works if the session is created which under http, but not under https. bug maybe? From: Maninder S Batth [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Fri, 18 Oct 2002 14:13:40 -0700 is the request method changing in redirection, for example post to get ?? if it is, use HttpServletResponse.encodeURL() Henrik Bentel wrote: Another weird behaviour I just discovered is the following: If a httpsession is created by a servlet processing a request sent under(scheme) http, then redirects to https, the session is available to the servlet processing in https. In other words, it stays put. HOWEVER, if a httpsession is created by a servlet processing a request under https, and then redirects to http, the session is not available. But if one redirects back to https agin, the session is available. Also, if you , after redirecting to http(where no session is to be found) create a new session, and then redirect back to https, the original session is lost and the new session created in http scheme is the current one. In tomcat3.3, session created in either schemes(http or https) stays put when redirecting. I haven't found anything in the servlet specification that mentiones anything about this behaviour. From: Henrik Bentel [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Thu, 17 Oct 2002 04:45:21 + ok, I see your point. My approach is that I only use https to scramble the login request itself, so that a login password cannot be read,or sniffed, in clear text(it probably still can, if someone really, really tries). Nothing critical is stored in the http session itself. A lot of websites do something similar, where only the password part is secure, and subsequent pages are insecure. and to change password, the old one has to be entered. I guess I'm a bit of a loss for a better way to do this?? Any well known approaches out there? -Henrik From: Jacob Kjome [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Wed, 16 Oct 2002 23:33:41 -0500 This is the way Tomcat 4.x.x is made to work. The reason for this is security. I think it can be assumed that you were under https for a reason. Maybe you entered your cedit card info and are storing that in the session until the final submit. Now, if you stayed in the same session when moving to http from https, your session id is in plain text. This can be hijacked by anyone sniffing network packets. Once they have your session id, theoreticaly, they have full access to everything you entered in that session including your credit card info. This is a *huge* security issue and Tomcat. Even if Tomcat-3.3.x allows you to do this, you would be wise to dump the session on your own before moving to http for your users' security. Obviously, this requires that you rethink some of your application flow, but Tomcat-4.x.x is doing the right thing here. Jake At 02:28 AM 10/17/2002 +, you wrote: Help! I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also tried 4.0). My problem is that for some reason the httpsession is lost after redirection from https to http. I run apache in front of tomcat to handle static content plus certificate. My webapp depend on the ability to login a user of secure connection then redirect to an unsecure connection. I do the usual res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to http protocol (to the same webapp context) the http session is null. My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat version and of course the tomcat conf. files. I've tried both the Coyote connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am going insane. My server.xml file is close to the default one, I've only added my context(defining docbase and such). For 3.3 this worked like a charm. Anyone?? -Henrik _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail: mailto:tomcat-user-help;jakarta.apache.org _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp -- To unsubscribe, e-mail: mailto:tomcat-user-unsubscribe;jakarta.apache.org For additional commands, e-mail
problem with session tracking and redirection http--- https
Help! I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also tried 4.0). My problem is that for some reason the httpsession is lost after redirection from https to http. I run apache in front of tomcat to handle static content plus certificate. My webapp depend on the ability to login a user of secure connection then redirect to an unsecure connection. I do the usual res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to http protocol (to the same webapp context) the http session is null. My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat version and of course the tomcat conf. files. I've tried both the Coyote connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am going insane. My server.xml file is close to the default one, I've only added my context(defining docbase and such). For 3.3 this worked like a charm. Anyone?? -Henrik _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
Re: problem with session tracking and redirection http--- https
ok, I see your point. My approach is that I only use https to scramble the login request itself, so that a login password cannot be read,or sniffed, in clear text(it probably still can, if someone really, really tries). Nothing critical is stored in the http session itself. A lot of websites do something similar, where only the password part is secure, and subsequent pages are insecure. and to change password, the old one has to be entered. I guess I'm a bit of a loss for a better way to do this?? Any well known approaches out there? -Henrik From: Jacob Kjome [EMAIL PROTECTED] Reply-To: Tomcat Users List [EMAIL PROTECTED] To: Tomcat Users List [EMAIL PROTECTED] Subject: Re: problem with session tracking and redirection http--- https Date: Wed, 16 Oct 2002 23:33:41 -0500 This is the way Tomcat 4.x.x is made to work. The reason for this is security. I think it can be assumed that you were under https for a reason. Maybe you entered your cedit card info and are storing that in the session until the final submit. Now, if you stayed in the same session when moving to http from https, your session id is in plain text. This can be hijacked by anyone sniffing network packets. Once they have your session id, theoreticaly, they have full access to everything you entered in that session including your credit card info. This is a *huge* security issue and Tomcat. Even if Tomcat-3.3.x allows you to do this, you would be wise to dump the session on your own before moving to http for your users' security. Obviously, this requires that you rethink some of your application flow, but Tomcat-4.x.x is doing the right thing here. Jake At 02:28 AM 10/17/2002 +, you wrote: Help! I recently tried to upgrade my version of Tomcat from 3.3 to 4.1(I also tried 4.0). My problem is that for some reason the httpsession is lost after redirection from https to http. I run apache in front of tomcat to handle static content plus certificate. My webapp depend on the ability to login a user of secure connection then redirect to an unsecure connection. I do the usual res.sendRedirect(res.encodeRedirectURL.)). But after redirecting to http protocol (to the same webapp context) the http session is null. My webapp workes fine in Tomcat 3.3. Nothing has changed except tomcat version and of course the tomcat conf. files. I've tried both the Coyote connector and the ajp13 one. mod_jk and mod_jk2(which I couldn't get working) on the apache side. I've tried Apache 1.3 and Apache 2. And I am going insane. My server.xml file is close to the default one, I've only added my context(defining docbase and such). For 3.3 this worked like a charm. Anyone?? -Henrik _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED] _ Unlimited Internet access for only $21.95/month. Try MSN! http://resourcecenter.msn.com/access/plans/2monthsfree.asp -- To unsubscribe, e-mail: mailto:[EMAIL PROTECTED] For additional commands, e-mail: mailto:[EMAIL PROTECTED]
