Re: https -- http session problem
On 11/19/2003 03:58 AM Henrik Bentel wrote: 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. This is my main requirement. Ideally what I would like to see in the servlet spec is something stating that another login is required if you want to change to a higher level of security. i.e. you can downgrade from https to http no problem, but if logged-in users want to go from http to https, they have to login again. 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]
Re: https -- http session problem
Hello On 11/17/2003 06:32 AM Andrew Mottaz wrote: Option 1 is unacceptable -- the overhead of having all of these connections encrypted is not a viable option. What are the 'overheads' in using SSL? How much harder does the server have to work, and - in practice - what sort of performance impact does this have? Many thanks Harry Mantheakis London, UK - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: https -- http session problem
On 11/18/2003 07:45 AM Bill Barker wrote: You'll have to go back at least two years to get the tomcat-dev discussion ;-). I had another search for it but can't find anything. Ploughing thro the whole list of threads doesn't fit in my schedule unfortunately. I guess I'm just going to have sit on it. At the moment, the Tomcat-Developer's don't believe that there is anything to discuss :). That's a problem. 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. If you have the decision to make again, make things configurable and give them the safer option as default. 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]
Re: https -- http session problem
Harry, Option 1 is unacceptable -- the overhead of having all of these connections encrypted is not a viable option. What are the 'overheads' in using SSL? How much harder does the server have to work, and - in practice - what sort of performance impact does this have? I don't have any numbers, but... SSL is encrypted, so the decryption has to take place on the server to make sense of the data. There's also the key negotiation that takes place at the beginnign of the SSL session. This load is pretty hard on the machine. Lots of apps have installed SSL acceleration boards into their servers to speed things up -- the h/w is faster than the software. Other use huge servers as proxies that decrypt everything so that the app servers don't have to do the work. (The data is not encrypted near the servers, but this is generally behind a firewall, anyway). I've seen performance numbers with SSL on and off, and the difference is suprising. I think we were using some type of Sun boxes (can't remember what type) and I think all of them had SSL accelerators in them. They were dedicateed web servers and did the SSL on behalf of the app servers. For even simple pages (actually, the time difference gets worse with simple, static content), the response times were doubled or worse. There's another effect with HTTPS that's unfortunate, which is that most browsers will not cache anything that comes down over SSL (including images!), which means that everything on your page will get re-loaded every time you show it (even images). That sucks because you now have estra requests to the server, and they all take longer. :( -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: https -- http session problem
Hello Chris Thank you so much for the feed-back. It is a very useful insight, and much appreciated! Kind regards Harry Mantheakis London, UK Harry, Option 1 is unacceptable -- the overhead of having all of these connections encrypted is not a viable option. What are the 'overheads' in using SSL? How much harder does the server have to work, and - in practice - what sort of performance impact does this have? I don't have any numbers, but... SSL is encrypted, so the decryption has to take place on the server to make sense of the data. There's also the key negotiation that takes place at the beginnign of the SSL session. This load is pretty hard on the machine. Lots of apps have installed SSL acceleration boards into their servers to speed things up -- the h/w is faster than the software. Other use huge servers as proxies that decrypt everything so that the app servers don't have to do the work. (The data is not encrypted near the servers, but this is generally behind a firewall, anyway). I've seen performance numbers with SSL on and off, and the difference is suprising. I think we were using some type of Sun boxes (can't remember what type) and I think all of them had SSL accelerators in them. They were dedicateed web servers and did the SSL on behalf of the app servers. For even simple pages (actually, the time difference gets worse with simple, static content), the response times were doubled or worse. There's another effect with HTTPS that's unfortunate, which is that most browsers will not cache anything that comes down over SSL (including images!), which means that everything on your page will get re-loaded every time you show it (even images). That sucks because you now have estra requests to the server, and they all take longer. :( -chris - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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]
Re: https -- http session problem
On 11/17/2003 06:32 AM Andrew Mottaz wrote: http://nagoya.apache.org/bugzilla. However, there aren't very many developers who like the idea of allowing you to hang yourself :). Thanks much for the tip -- I have to disagree about this not being a necessary change. There are plenty of apps where people browse without a secure connection, but have to log in to perform some functions. Users like to bookmark pages -- why should I force them to bookmark only non-secure pages? Giving a developer control over how session cookies function is better than forcing a hack where you have to always redirect to a non-secure page to establish the session. If you are writing an application where the session data is so sensitive that you have to protect against session hijacking, you should know about the difference between secure and non-secure cookies. I've got no problem if the default behavior uses secure cookies when ever possible, but change the Session uses cookie parameter to have a flag that allows session cookies to always be non-secure. Andrew, what reason is there for preventing users from bookmarking secure pages? I don't follow you there. 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? 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]
RE: https -- http session problem
Andrew, Couldn't agree more - I've just been round this circle myself. I don't care if someone gets a session hijacked in my application, but I don't want passwords transferred over plain text, because people tend to use the same passwords in multiple applications. This application may not need to be completely bulletproof, but you can bet your bottom dollar that some users are using the same paswords as for stuff that does need to be bulletproof. Don't anyone say well they shouldn't, because they do! :-) Andy -Original Message- From: Andrew Mottaz [mailto:[EMAIL PROTECTED] Sent: 17 November 2003 05:32 To: Tomcat Users List Subject: Re: https -- http session problem http://nagoya.apache.org/bugzilla. However, there aren't very many developers who like the idea of allowing you to hang yourself :). Thanks much for the tip -- I have to disagree about this not being a necessary change. There are plenty of apps where people browse without a secure connection, but have to log in to perform some functions. Users like to bookmark pages -- why should I force them to bookmark only non-secure pages? Giving a developer control over how session cookies function is better than forcing a hack where you have to always redirect to a non-secure page to establish the session. If you are writing an application where the session data is so sensitive that you have to protect against session hijacking, you should know about the difference between secure and non-secure cookies. I've got no problem if the default behavior uses secure cookies when ever possible, but change the Session uses cookie parameter to have a flag that allows session cookies to always be non-secure. Just my two-cent rant :) Andrew - 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: https -- http session problem
On 11/17/2003 06:32 AM Andrew Mottaz wrote: http://nagoya.apache.org/bugzilla. However, there aren't very many developers who like the idea of allowing you to hang yourself :). Thanks much for the tip -- I have to disagree about this not being a necessary change. There are plenty of apps where people browse without a secure connection, but have to log in to perform some functions. Users like to bookmark pages -- why should I force them to bookmark only non-secure pages? Giving a developer control over how session cookies function is better than forcing a hack where you have to always redirect to a non-secure page to establish the session. If you are writing an application where the session data is so sensitive that you have to protect against session hijacking, you should know about the difference between secure and non-secure cookies. I've got no problem if the default behavior uses secure cookies when ever possible, but change the Session uses cookie parameter to have a flag that allows session cookies to always be non-secure. Andrew, what reason is there for preventing users from bookmarking secure pages? I don't follow you there. 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? Adam Hi Adam, If a user bookmarks a secure page, and then tries to browse a non-secure page, the session is lost. The decision to keep a session secure iff the FIRST access is secure does not make sense to me. 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. Now -- I have a web site with hundreds of pages of product data, and thousands of users. Many of these users bookmark the page https://www.example.com/jsp/login.jsp So -- if I want to allow users to bookmark this page, they will create a secure session. When they then browse the pages, I have two options: 1) Keep all of the links secure 2) Redirect them to a non-secure page (To establish a non-secure session), and then send them back to the secure log-in page. Option 1 is unacceptable -- the overhead of having all of these connections encrypted is not a viable option. Option 2 is a hacky workaround -- cookies have a Secure=yes flag so that it can be set and un-set as appropriate. 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. Finally -- I know that ASP used to have the OPPOSITE implementation -- session cookies were always non-secure. This is worse than Tomcat, but both are wrong. The developer needs to make the decision about what is appropriate. 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. Thanks, Andrew -- Andrew Mottaz Site 9 :: Internet Business Solutions 116 W. Illinois, Ste 6E Chicago, Illinois 60610 312.670.8469 www.site9.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: https -- http session problem
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. 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]
Re: https -- http session problem
I read this post and have a question...and maybe I'm not understanding https correctly, but why is your login PAGE secure? I wouldn't care if someone sees an empty page with a prompt for the username and password. The post should be secure though... In other words... can't you have a page http://www.example.com/login.jsp post to something like https://www.example.com/login.do (this would be the url in the form tag) with the actual login action being secure? My understanding is that on the post, a secure session will be established and THEN the username and password will be posted. Then users would bookmark the log-in page as a non-secure page, and still be able to login without any funky work-around. If this understanding is correct, then if someone bookmars a secure page, they should get redirected to the login page anyway since they need to login first. Thanks, Kevin Williams On Mon, 2003-11-17 at 08:15, Andrew Mottaz wrote: On 11/17/2003 06:32 AM Andrew Mottaz wrote: http://nagoya.apache.org/bugzilla. However, there aren't very many developers who like the idea of allowing you to hang yourself :). Thanks much for the tip -- I have to disagree about this not being a necessary change. There are plenty of apps where people browse without a secure connection, but have to log in to perform some functions. Users like to bookmark pages -- why should I force them to bookmark only non-secure pages? Giving a developer control over how session cookies function is better than forcing a hack where you have to always redirect to a non-secure page to establish the session. If you are writing an application where the session data is so sensitive that you have to protect against session hijacking, you should know about the difference between secure and non-secure cookies. I've got no problem if the default behavior uses secure cookies when ever possible, but change the Session uses cookie parameter to have a flag that allows session cookies to always be non-secure. Andrew, what reason is there for preventing users from bookmarking secure pages? I don't follow you there. 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? Adam Hi Adam, If a user bookmarks a secure page, and then tries to browse a non-secure page, the session is lost. The decision to keep a session secure iff the FIRST access is secure does not make sense to me. 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. Now -- I have a web site with hundreds of pages of product data, and thousands of users. Many of these users bookmark the page https://www.example.com/jsp/login.jsp So -- if I want to allow users to bookmark this page, they will create a secure session. When they then browse the pages, I have two options: 1) Keep all of the links secure 2) Redirect them to a non-secure page (To establish a non-secure session), and then send them back to the secure log-in page. Option 1 is unacceptable -- the overhead of having all of these connections encrypted is not a viable option. Option 2 is a hacky workaround -- cookies have a Secure=yes flag so that it can be set and un-set as appropriate. 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. Finally -- I know that ASP used to have the OPPOSITE implementation -- session cookies were always non-secure. This is worse than Tomcat, but both are wrong. The developer needs to make the decision about what is appropriate. 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. Thanks, Andrew -- Andrew Mottaz Site 9 :: Internet Business Solutions 116 W. Illinois, Ste 6E Chicago, Illinois 60610 312.670.8469 www.site9.net - 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: https -- http session problem
You are correct -- it is a user perception issue -- that makes my argument a bit less persuasive -- but -- I still say give the developer control. Andrew I read this post and have a question...and maybe I'm not understanding https correctly, but why is your login PAGE secure? I wouldn't care if someone sees an empty page with a prompt for the username and password. The post should be secure though... In other words... can't you have a page http://www.example.com/login.jsp post to something like https://www.example.com/login.do (this would be the url in the form tag) with the actual login action being secure? My understanding is that on the post, a secure session will be established and THEN the username and password will be posted. Then users would bookmark the log-in page as a non-secure page, and still be able to login without any funky work-around. If this understanding is correct, then if someone bookmars a secure page, they should get redirected to the login page anyway since they need to login first. Thanks, Kevin Williams On Mon, 2003-11-17 at 08:15, Andrew Mottaz wrote: On 11/17/2003 06:32 AM Andrew Mottaz wrote: http://nagoya.apache.org/bugzilla. However, there aren't very many developers who like the idea of allowing you to hang yourself :). Thanks much for the tip -- I have to disagree about this not being a necessary change. There are plenty of apps where people browse without a secure connection, but have to log in to perform some functions. Users like to bookmark pages -- why should I force them to bookmark only non-secure pages? Giving a developer control over how session cookies function is better than forcing a hack where you have to always redirect to a non-secure page to establish the session. If you are writing an application where the session data is so sensitive that you have to protect against session hijacking, you should know about the difference between secure and non-secure cookies. I've got no problem if the default behavior uses secure cookies when ever possible, but change the Session uses cookie parameter to have a flag that allows session cookies to always be non-secure. Andrew, what reason is there for preventing users from bookmarking secure pages? I don't follow you there. 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? Adam Hi Adam, If a user bookmarks a secure page, and then tries to browse a non-secure page, the session is lost. The decision to keep a session secure iff the FIRST access is secure does not make sense to me. 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. Now -- I have a web site with hundreds of pages of product data, and thousands of users. Many of these users bookmark the page https://www.example.com/jsp/login.jsp So -- if I want to allow users to bookmark this page, they will create a secure session. When they then browse the pages, I have two options: 1) Keep all of the links secure 2) Redirect them to a non-secure page (To establish a non-secure session), and then send them back to the secure log-in page. Option 1 is unacceptable -- the overhead of having all of these connections encrypted is not a viable option. Option 2 is a hacky workaround -- cookies have a Secure=yes flag so that it can be set and un-set as appropriate. 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. Finally -- I know that ASP used to have the OPPOSITE implementation -- session cookies were always non-secure. This is worse than Tomcat, but both are wrong. The developer needs to make the decision about what is appropriate. 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. Thanks, Andrew -- Andrew Mottaz Site 9 :: Internet Business Solutions 116 W. Illinois, Ste 6E Chicago, Illinois 60610 312.670.8469 www.site9.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: https -- http session problem
On 11/17/2003 11:58 PM Kevin Williams wrote: I read this post and have a question...and maybe I'm not understanding https correctly, but why is your login PAGE secure? I wouldn't care if someone sees an empty page with a prompt for the username and password. The post should be secure though... In other words... can't you have a page http://www.example.com/login.jsp post to something like https://www.example.com/login.do [snipped...] I'm talking about container-managed security where the form submit is to j_security_check, as per the servlet spec. There isn't much flexibility there. For a secure login, you must post to https://mydomain/myapp/j_security_check and for a non-secure post, to http://mydomain/myapp/j_security_check. You can't mix and match. 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]
Re: https -- http session problem
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]
Re: https -- http session problem
Why is this the case, and where does one put in an enhancement request? I can see the argument for wanting the OPTION of forcing secure connections or losing your session, but to not even have the option of having the session cookie be insecure doesn't make much sense. I understand the potential for session hijacking, but given what is being secured, that is an acceptable risk, compared to sending passwords in plain text which is not an acceptable risk. Thanks for the answer, anyway (even though it's not what I wanted to hear :) Andrew Andrew Mottaz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've run into the problem where a session cookie gets lost when you start on http and move to https. The reason seems to be that 'secure=true' is set on the session cookie when you start on https, preventing the cookie from being passed to the http page. I found the following in the archives: You can maintain your session going http-https. You can't maintain your session https-http (unless you previously did a http-https). Is there any way to change the configuration to always use non-secure session cookies? You can in 3.3.2 (since it is a +0.0.1 release change). In all higher versions of Tomcat, no. If there is not, is there a standard workaround? I hate the hack of redirecting to make sure that first access is not secure. Start hating ;-). Thanks much, Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Mottaz Site 9 :: Internet Business Solutions 116 W. Illinois, Ste 6E Chicago, Illinois 60610 312.670.8469 www.site9.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: https -- http session problem
Andrew Mottaz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Why is this the case, and where does one put in an enhancement request? I can see the argument for wanting the OPTION of forcing secure connections or losing your session, but to not even have the option of having the session cookie be insecure doesn't make much sense. http://nagoya.apache.org/bugzilla. However, there aren't very many developers who like the idea of allowing you to hang yourself :). I understand the potential for session hijacking, but given what is being secured, that is an acceptable risk, compared to sending passwords in plain text which is not an acceptable risk. Thanks for the answer, anyway (even though it's not what I wanted to hear :) Andrew Andrew Mottaz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've run into the problem where a session cookie gets lost when you start on http and move to https. The reason seems to be that 'secure=true' is set on the session cookie when you start on https, preventing the cookie from being passed to the http page. I found the following in the archives: You can maintain your session going http-https. You can't maintain your session https-http (unless you previously did a http-https). Is there any way to change the configuration to always use non-secure session cookies? You can in 3.3.2 (since it is a +0.0.1 release change). In all higher versions of Tomcat, no. If there is not, is there a standard workaround? I hate the hack of redirecting to make sure that first access is not secure. Start hating ;-). Thanks much, Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Andrew Mottaz Site 9 :: Internet Business Solutions 116 W. Illinois, Ste 6E Chicago, Illinois 60610 312.670.8469 www.site9.net - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: https -- http session problem
http://nagoya.apache.org/bugzilla. However, there aren't very many developers who like the idea of allowing you to hang yourself :). Thanks much for the tip -- I have to disagree about this not being a necessary change. There are plenty of apps where people browse without a secure connection, but have to log in to perform some functions. Users like to bookmark pages -- why should I force them to bookmark only non-secure pages? Giving a developer control over how session cookies function is better than forcing a hack where you have to always redirect to a non-secure page to establish the session. If you are writing an application where the session data is so sensitive that you have to protect against session hijacking, you should know about the difference between secure and non-secure cookies. I've got no problem if the default behavior uses secure cookies when ever possible, but change the Session uses cookie parameter to have a flag that allows session cookies to always be non-secure. Just my two-cent rant :) Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: https -- http session problem
Andrew Mottaz [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've run into the problem where a session cookie gets lost when you start on http and move to https. The reason seems to be that 'secure=true' is set on the session cookie when you start on https, preventing the cookie from being passed to the http page. I found the following in the archives: You can maintain your session going http-https. You can't maintain your session https-http (unless you previously did a http-https). Is there any way to change the configuration to always use non-secure session cookies? You can in 3.3.2 (since it is a +0.0.1 release change). In all higher versions of Tomcat, no. If there is not, is there a standard workaround? I hate the hack of redirecting to make sure that first access is not secure. Start hating ;-). Thanks much, Andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
https -- http session problem
I've run into the problem where a session cookie gets lost when you start on http and move to https. The reason seems to be that 'secure=true' is set on the session cookie when you start on https, preventing the cookie from being passed to the http page. I found the following in the archives: You can maintain your session going http-https. You can't maintain your session https-http (unless you previously did a http-https). Is there any way to change the configuration to always use non-secure session cookies? If there is not, is there a standard workaround? I hate the hack of redirecting to make sure that first access is not secure. Thanks much, Andrew
