struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Going from https on /, back to http on index.jsp?
Date Fri, 26 Sep 2003 02:54:31 GMT
Max Cooper wrote:

>Creating an 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 

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 
<user-transport-guarantee> 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

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message