On Mon, Nov 15, 2004 at 05:13:21PM -0300, Paulo Alvim wrote:
> I have a similar problem: I'd like to use https only with the
> login.jsp page and come back to http after that. Could you explain
> why it isn't possible?
It's not possible because it's not _proper_ from a security
perspective, so they built tomcat to not enable it.
I can sorta understand why people want to do it, myself, but you
should understand that it's not secure, and be very much aware of the
risks you're taking. Still, I can understand some of the motivation
behind the request, and I think there's a solution. The key is to
realize you're trying to solve the wrong problem. See my explanation
at the end for what the right problem is, and how to solve it.
To illustrate this properly, imagine that your account has two
usernames and two passwords that you can use to access it, the
permanent username/password and a temporary username/password.
When you login, you first have to send the permanent username and
first password over the net.
At that point, the server then sets your temporary username and
second password to some random value, temporarily, and then sends
those back to you.
The temporary username/password will last until your user session
times out, or until you explicitly log out.
Your browser then sends a copy of that temporary username and
temporary password along with _every_ _single_ _request_ to the
server.
Just because you make sure the first communication, where you
sent the permanent username/password, is secure, doesn't keep somebody
from sniffing the temporary username and password and using those to
do all sorts of damage to your account during that window of
opportunity.
To bring this back to reality, the JSESSIONID cookie is the
temporary username/password. This explains why it is not secure to
use the same session for both HTTP and HTTPS connections.
Thinking about it, I can certainly see why people would want some
happy medium between the two. SSL consumes resources* and often
you're not worried about securing the entire series of user
interactions, just a critical subset. For example, you don't need to
SSL-protect the user browsing your catalog, but you do need to
SSL-protect the payment authorization.
(* Last I heard, the SSL server takes up about 40% extra
resources, though that info is years old and may be way out of date.)
However, the important point is _not_ that you want to share the
session data across secure and unsecure apps, but that you want to
avoid making the user log in twice. Here's how I'd approach this.
You need two distinct sets of security credentials, "serious" and
"trivial". The serious credential is necessary for the SSL-protected
portion, the trivial credential is necessary for the non-SSL portion.
Then, when the user logs in via SSL, it also creates a trivial
security credential, and sets that on a _different_ cookie than
JSESSIONID. It's been ages since I've worked with cookies, but you
can mark a cookie as "Secure", meaning it only gets sent back to the
secure server, or not. The tomcat SSL-created JSESSIONID is set
secure, for example. Here's what one looks like:
Set-Cookie: JSESSIONID=202E506FAD4A9ADB5F062DB3A3310E89; Path=/xyzzy; Secure
This is further documented at:
http://www.ietf.org/rfc/rfc2109.txt
However, you can also set a second cookie, _without_ the secure
option, from the SSL response. The browser will then include that
cookie value in further requests to the non-secure site at the same
domain. You would have to customize the non-secure site's security so
that it checks for this cookie and automatically logs the user in to
the non-secure site without prompting.
One thing you'll have to watch out for is the timeout of the SSL
session, since it might get left alone for many hours. You have two
choices there:
1) either include an SSL-protected icon on every page, which will keep
your SSL session from timing out. This can have some slight
complications, since most browsers use some visual cue to indicated
SSL traffic.
2) or just set the SSL app's session timeout to a fairly long time.
--
Steven J. Owens
[EMAIL PROTECTED]
"I'm going to make broad, sweeping generalizations and strong,
declarative statements, because otherwise I'll be here all night and
this document will be four times longer and much less fun to read.
Take it all with a grain of salt." - http://darksleep.com/notablog
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
