RE: Going from https on /member.do, back to http on index.jsp?
> -Original Message- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > Sent: Friday, September 26, 2003 9:38 PM > To: Struts Users Mailing List > Subject: Re: Going from https on /member.do, back to http on > index.jsp? > > > Jayaraman Dorai wrote: > > > > > > >>-Original Message- > >>From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > >>Sent: Thursday, September 25, 2003 10:55 PM > >>To: Struts Users Mailing List > >>Subject: Re: Going from https on /member.do, back to http on > >>index.jsp? > >> > >> > >>Max Cooper wrote: > >> > >> > >> > >>>Creating an index.do is one option. If it is not marked as > >>> > >>> > >>secure, sslext > >> > >> > >>>will write an absolute URL back to http:// for it. Many > Struts users > >>>advocate that all requests should be served by Actions, even > >>> > >>> > >>if the action > >> > >> > >>>merely forwards to a JSP. > >>> > >>> > >>> > >>> > >>I actually have a more important concern about doing this > -- exposing > >>information to people who can listen in on the packets that > >>go back and > >>forth. > >> > >>Many people would like, for example, to have the login form > >>be secure so > >>that your password is not sent across the wire encrypted, > but then go > >>back to http for the rest of the session for the better > performance. > >>The seemingly ideal solution is to have the destination of > the login > >>submit require SSL, and then switch back. Using a > >> security constraint, you can > even let the > >>container worry about the http->https transition for you. > >>Or, you can > >>use things like SSLext that is nicely integrated into Struts. > >> > >>However, the servlet spec offers no help in switching back to http, > >>because it is not a recommended practice. Why? Consider the > >>fact that > >>you now trust subsequent transactions from the same user, and are > >>typically using the session that was established earlier > (whether the > >>session was originally created in http or https turns out not to > >>matter). But the session id is no longer encrypted (it's > either in a > >>cookie or in rewritten URLs), so it can be easily forged by > >>anyone with > >>a network snooper between you and the server. How do you > >>guarantee that > >>an after-login request on that session is not being sent by > >>someone who > >>is forging the session id because they snooped it? > >> > >>I'm a conservative on security issues -- if I have an app > >>that needs SSL > >>sometimes, I arrange things to never accept a non-SSL > request on the > >>same session again, once I've switched to SSL (easy to do > >>with a Filter, > >>for example). If you're concerned enough to protect the > >>password, you > >>should be concerned enough to pay the CPU overhead for SSL > >>the remainder > >>of the session. Otherwise, it's likely that encrypting the > >>login form > >>will just give you a false sense of security. > >> > >> > >> > >>>I think you can also use the secure attribute in the sslext > >>> > >>> > >>tags to indicate > >> > >> > >>>whether the target of the link or form should be accessed > >>> > >>> > >>securely. In this > >> > >> > >>>case, you would add secure="false" to the sslext:link tag > >>> > >>> > >>that goes back to > >> > >> > >>>/index.jsp. > >>> > >>>-Max > >>> > >>> > >>> > >>> > >>Craig > >> > >> > > > >Will it be useful for cases like where credit card > information are sent through SSL and hence are secured. They > might snoop the session, if it is switched back to http, but > still the credit card information is not. Similarly, snooper > might steal the sessionId, but the password is not stolen and > is secured. Is that not better than nothing? Am I missing so
Re: Going from https on /member.do, back to http on index.jsp?
Adam, I am not sure what demographic your users are in. However, I consider it HIGHLY unlikely that the "average" surfer will even notice that after they are logged in the site is all ssl. The people who would care are the people who have an idea what ssl is and might actually appreciate that once logged in the entire session IS in ssl. James Adam Hardy wrote: The problem is that the average surfer would probably consider it weird that the whole site runs under SSL. Currently only sites such as PayPal do that. How much that could affect sales is something I will have to consider. Adam - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Going from https on /member.do, back to http on index.jsp?
An elegant solution by Amazon is to require a login everytime the user switches into SSL - even if they are logged in already. Session hijacking still worries me though because the app I am building at the moment is quite data intensive, and the customers of the website who will use it to enter and store their data will obviously hold it in high value. It worries me that some discontented session-hijacker could easily destroy the data belonging to someone else. The problem is that the average surfer would probably consider it weird that the whole site runs under SSL. Currently only sites such as PayPal do that. How much that could affect sales is something I will have to consider. Adam On 09/27/2003 03:38 AM Craig R. McClanahan wrote: Jayaraman Dorai wrote: -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 10:55 PM To: Struts Users Mailing List Subject: Re: Going from https on /member.do, back to http on index.jsp? Max Cooper wrote: Creating an index.do is one option. If it is not marked as secure, sslext will write an absolute URL back to http:// for it. Many Struts users advocate that all requests should be served by Actions, even if the action merely forwards to a JSP. I actually have a more important concern about doing this -- exposing information to people who can listen in on the packets that go back and forth. Many people would like, for example, to have the login form be secure so that your password is not sent across the wire encrypted, but then go back to http for the rest of the session for the better performance. The seemingly ideal solution is to have the destination of the login submit require SSL, and then switch back. Using a security constraint, you can even let the container worry about the http->https transition for you. Or, you can use things like SSLext that is nicely integrated into Struts. However, the servlet spec offers no help in switching back to http, because it is not a recommended practice. Why? Consider the fact that you now trust subsequent transactions from the same user, and are typically using the session that was established earlier (whether the session was originally created in http or https turns out not to matter). But the session id is no longer encrypted (it's either in a cookie or in rewritten URLs), so it can be easily forged by anyone with a network snooper between you and the server. How do you guarantee that an after-login request on that session is not being sent by someone who is forging the session id because they snooped it? I'm a conservative on security issues -- if I have an app that needs SSL sometimes, I arrange things to never accept a non-SSL request on the same session again, once I've switched to SSL (easy to do with a Filter, for example). If you're concerned enough to protect the password, you should be concerned enough to pay the CPU overhead for SSL the remainder of the session. Otherwise, it's likely that encrypting the login form will just give you a false sense of security. I think you can also use the secure attribute in the sslext tags to indicate whether the target of the link or form should be accessed securely. In this case, you would add secure="false" to the sslext:link tag that goes back to /index.jsp. -Max Craig Will it be useful for cases like where credit card information are sent through SSL and hence are secured. They might snoop the session, if it is switched back to http, but still the credit card information is not. Similarly, snooper might steal the sessionId, but the password is not stolen and is secured. Is that not better than nothing? Am I missing something? The credit card information is not going back and forth across the wire unencrypted, but your session identifier is (for servlet based apps, it's normally in a cookie or encoded into the URLs). In at least some ecommerce apps I'm familiar with, the credit card number *is* stored in an HttpSession (or something analogous for non-servlet technologies), so that the customer can go back and buy some more stuff, and do an expedited checkout the second time. If I know that your app works that way, I can snoop the wire until the user goes to https (which I can't read, but can see happening) and then back to http (which I can see). Now, I've got the cleartext version of the session id, assume that the user has gone through the checkout, and can submit false additional purchase transactions to your app based on that session id, without having to resubmit a credit card number. Protecting just the password, but not the remainder of the current session, is *not* better than nothing -- IMHO it is substantially worse because it gives you a *false* sense of security. Craig -- struts 1.1 + tomcat 4.1.27 + java 1.4.2 Linux 2.4.20 RH9 --
Re: Going from https on /member.do, back to http on index.jsp?
Jayaraman Dorai wrote: -Original Message- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] Sent: Thursday, September 25, 2003 10:55 PM To: Struts Users Mailing List Subject: Re: Going from https on /member.do, back to http on index.jsp? Max Cooper wrote: Creating an index.do is one option. If it is not marked as secure, sslext will write an absolute URL back to http:// for it. Many Struts users advocate that all requests should be served by Actions, even if the action merely forwards to a JSP. I actually have a more important concern about doing this -- exposing information to people who can listen in on the packets that go back and forth. Many people would like, for example, to have the login form be secure so that your password is not sent across the wire encrypted, but then go back to http for the rest of the session for the better performance. The seemingly ideal solution is to have the destination of the login submit require SSL, and then switch back. Using a security constraint, you can even let the container worry about the http->https transition for you. Or, you can use things like SSLext that is nicely integrated into Struts. However, the servlet spec offers no help in switching back to http, because it is not a recommended practice. Why? Consider the fact that you now trust subsequent transactions from the same user, and are typically using the session that was established earlier (whether the session was originally created in http or https turns out not to matter). But the session id is no longer encrypted (it's either in a cookie or in rewritten URLs), so it can be easily forged by anyone with a network snooper between you and the server. How do you guarantee that an after-login request on that session is not being sent by someone who is forging the session id because they snooped it? I'm a conservative on security issues -- if I have an app that needs SSL sometimes, I arrange things to never accept a non-SSL request on the same session again, once I've switched to SSL (easy to do with a Filter, for example). If you're concerned enough to protect the password, you should be concerned enough to pay the CPU overhead for SSL the remainder of the session. Otherwise, it's likely that encrypting the login form will just give you a false sense of security. I think you can also use the secure attribute in the sslext tags to indicate whether the target of the link or form should be accessed securely. In this case, you would add secure="false" to the sslext:link tag that goes back to /index.jsp. -Max Craig Will it be useful for cases like where credit card information are sent through SSL and hence are secured. They might snoop the session, if it is switched back to http, but still the credit card information is not. Similarly, snooper might steal the sessionId, but the password is not stolen and is secured. Is that not better than nothing? Am I missing something? The credit card information is not going back and forth across the wire unencrypted, but your session identifier is (for servlet based apps, it's normally in a cookie or encoded into the URLs). In at least some ecommerce apps I'm familiar with, the credit card number *is* stored in an HttpSession (or something analogous for non-servlet technologies), so that the customer can go back and buy some more stuff, and do an expedited checkout the second time. If I know that your app works that way, I can snoop the wire until the user goes to https (which I can't read, but can see happening) and then back to http (which I can see). Now, I've got the cleartext version of the session id, assume that the user has gone through the checkout, and can submit false additional purchase transactions to your app based on that session id, without having to resubmit a credit card number. Protecting just the password, but not the remainder of the current session, is *not* better than nothing -- IMHO it is substantially worse because it gives you a *false* sense of security. Craig
RE: Going from https on /member.do, back to http on index.jsp?
> -Original Message- > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 25, 2003 10:55 PM > To: Struts Users Mailing List > Subject: Re: Going from https on /member.do, back to http on > index.jsp? > > > Max Cooper wrote: > > >Creating an index.do is one option. If it is not marked as > secure, sslext > >will write an absolute URL back to http:// for it. Many Struts users > >advocate that all requests should be served by Actions, even > if the action > >merely forwards to a JSP. > > > > > I actually have a more important concern about doing this -- exposing > information to people who can listen in on the packets that > go back and > forth. > > Many people would like, for example, to have the login form > be secure so > that your password is not sent across the wire encrypted, but then go > back to http for the rest of the session for the better performance. > The seemingly ideal solution is to have the destination of the login > submit require SSL, and then switch back. Using a > security constraint, you can even let the > container worry about the http->https transition for you. > Or, you can > use things like SSLext that is nicely integrated into Struts. > > However, the servlet spec offers no help in switching back to http, > because it is not a recommended practice. Why? Consider the > fact that > you now trust subsequent transactions from the same user, and are > typically using the session that was established earlier (whether the > session was originally created in http or https turns out not to > matter). But the session id is no longer encrypted (it's either in a > cookie or in rewritten URLs), so it can be easily forged by > anyone with > a network snooper between you and the server. How do you > guarantee that > an after-login request on that session is not being sent by > someone who > is forging the session id because they snooped it? > > I'm a conservative on security issues -- if I have an app > that needs SSL > sometimes, I arrange things to never accept a non-SSL request on the > same session again, once I've switched to SSL (easy to do > with a Filter, > for example). If you're concerned enough to protect the > password, you > should be concerned enough to pay the CPU overhead for SSL > the remainder > of the session. Otherwise, it's likely that encrypting the > login form > will just give you a false sense of security. > > >I think you can also use the secure attribute in the sslext > tags to indicate > >whether the target of the link or form should be accessed > securely. In this > >case, you would add secure="false" to the sslext:link tag > that goes back to > >/index.jsp. > > > >-Max > > > > > Craig Will it be useful for cases like where credit card information are sent through SSL and hence are secured. They might snoop the session, if it is switched back to http, but still the credit card information is not. Similarly, snooper might steal the sessionId, but the password is not stolen and is secured. Is that not better than nothing? Am I missing something? > > > > - > 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: Going from https on /member.do, back to http on index.jsp?
Max Cooper wrote: Creating an index.do is one option. If it is not marked as secure, sslext will write an absolute URL back to http:// for it. Many Struts users advocate that all requests should be served by Actions, even if the action merely forwards to a JSP. I actually have a more important concern about doing this -- exposing information to people who can listen in on the packets that go back and forth. Many people would like, for example, to have the login form be secure so that your password is not sent across the wire encrypted, but then go back to http for the rest of the session for the better performance. The seemingly ideal solution is to have the destination of the login submit require SSL, and then switch back. Using a security constraint, you can even let the container worry about the http->https transition for you. Or, you can use things like SSLext that is nicely integrated into Struts. However, the servlet spec offers no help in switching back to http, because it is not a recommended practice. Why? Consider the fact that you now trust subsequent transactions from the same user, and are typically using the session that was established earlier (whether the session was originally created in http or https turns out not to matter). But the session id is no longer encrypted (it's either in a cookie or in rewritten URLs), so it can be easily forged by anyone with a network snooper between you and the server. How do you guarantee that an after-login request on that session is not being sent by someone who is forging the session id because they snooped it? I'm a conservative on security issues -- if I have an app that needs SSL sometimes, I arrange things to never accept a non-SSL request on the same session again, once I've switched to SSL (easy to do with a Filter, for example). If you're concerned enough to protect the password, you should be concerned enough to pay the CPU overhead for SSL the remainder of the session. Otherwise, it's likely that encrypting the login form will just give you a false sense of security. I think you can also use the secure attribute in the sslext tags to indicate whether the target of the link or form should be accessed securely. In this case, you would add secure="false" to the sslext:link tag that goes back to /index.jsp. -Max Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Going from https on /member.do, back to http on index.jsp?
Creating an index.do is one option. If it is not marked as secure, sslext will write an absolute URL back to http:// for it. Many Struts users advocate that all requests should be served by Actions, even if the action merely forwards to a JSP. I think you can also use the secure attribute in the sslext tags to indicate whether the target of the link or form should be accessed securely. In this case, you would add secure="false" to the sslext:link tag that goes back to /index.jsp. -Max - Original Message - From: "Mick Knutson" <[EMAIL PROTECTED]> To: "struts" <[EMAIL PROTECTED]> Sent: Thursday, September 25, 2003 2:50 PM Subject: Going from https on /member.do, back to http on index.jsp? > How do I go from https on /member.do, back to http on index.jsp? > Must I make an /index.do and just eliminate the index.jsp? > > --- > Thanks > Mick Knutson > http://www.baselogic.com > > +001(805) 563-0666 Office > +001 (708) 570-2772 Fax > --- > > - > 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]
Going from https on /member.do, back to http on index.jsp?
How do I go from https on /member.do, back to http on index.jsp? Must I make an /index.do and just eliminate the index.jsp? --- Thanks Mick Knutson http://www.baselogic.com +001(805) 563-0666 Office +001 (708) 570-2772 Fax --- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
