Jacob Kjome wrote:
I'll bite on this one. But first I'll say that I agree mostly with
It is my understanding that if Tomcat allowed you use the same session and the session was created under https for a particular user, then once it gets to http the session id is now in clear text. This is what, I believe, Craig is talking about when he says that using SSL in this manner only creates the appearance of security, not true security. All I'd have to do to wreak some serious havoc is sniff packets, hijack the session, and browse back into the secure sections of the site under the guise of the user whose session I hijacked. How is that security?
your and Craig's position on this because in general most people aren't
experienced enough with security to make good decisions about what
is going on. However this particular issues that has been raised
can make use of the HTTPS->HTTP switch securely but with fairly
"bogus" user experience. (My opinion on the user experience, nothing more)
Security is made of a number of components, these are generally:
Authentication, Access Control,Data Integrity and Confidentiality.
Rather than boring people about this,the two important parts to this
discussion are essentially Authentication and Confidentiality.
We want to use Authentication to allow the right person to access the
data and we want to use Confidentiality to make sure that bad people
can't see things in transit.
_Normally_ authentication is handled once and then confidentiality is
used to ensure the tokens remain private. However this is not the only
way to do it.
Here's an example scenario which I believe matches the desired result
and why HTTPS->HTTP _is desirable and secure in this instance_.
1. There are 2 areas of the website, secret stuff and public stuff.
2. Requests and responses from secret stuff is handled by HTTPS
3. Requests and responses from public stuff is handled by HTTP
4. To access the secret stuff, each and every time you try to access
the secret stuff from the public stuff you are forced to authenticate.
5. The authentication mechanism uses confidentiality to protect the tokens
and any transfer of secret stuff
6. There is nothing in the public stuff that matters if a session is
hijacked.
This is desirable under the circumstances where you might wish to
initially authenticate under HTTPS to protect the tokens _only_, switch
to HTTP and keep the session "valid" either for tracking purposes or
merely to display the user name on the page.
Given that it is possible to force re-presentation of the authentication
tokens each time then I cannot see the security related problem with this
scenario. (User experience problems, however) I am happy to have
people poke holes in the scenario and tell me what I've done wrong, but
it seems correct to me.
Would I build it this way ? Probably not, but I generally don't like to
double-guess the constraints or problems my customers might have.
I could see that this might be useful if there is an enormous user base
that accesses a lot of public content and very, very occasionally needs
to access very secret information. If 99.9% of the traffic doesn't need
to be secured, _and your user base is huge_ and you want the results of
the authentication to be available in the public area then this seems like
a reasonable request.
I will stress however that I feel that providing HTTPS->HTTP session migration within Tomcat is a highly dangerous thing as it will be
utilised in the single authentication continued session approach by
most people because they will not be able to understand why it's a
bad thing.
After having said all that, I'm sure it can't be hard to write a
SessionMigration object that can contain the data you want to "throw
over the wall" store it in the web application context and pass a
parameter through the URL redirection so it can be recovered on
"the other side". Maybe that's the workaround that's required in
this situation.
Cheers,
-- jon
JakeAt 08:17 PM 1/9/2003 -0800, you wrote:I'm aware of that. The tomcat-specific issue is that it won't let you make the transition from https to http on the same session. That's frustrating.
-- Jon Eaves <[EMAIL PROTECTED]> http://www.eaves.org/jon/ -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
