On Fri, 9 Aug 2002, Drinkwater, GJ (Glen) wrote:
> Date: Fri, 9 Aug 2002 14:51:32 +0100
> From: "Drinkwater, GJ (Glen)" <[EMAIL PROTECTED]>
> Reply-To: Tomcat Users List <[EMAIL PROTECTED]>
> To: 'Tomcat Users List' <[EMAIL PROTECTED]>
> Subject: RE: SSL just for a login page
>
> Hi
>
> I am not am expert in the security of the web at the moment.
> Could you explain to me why this would open such a big secuirty hole from
> swapping from https to https.
>
Switching from "http" to "https" is not the problem. Switching back is.
> I was suggesting this because it read this i a 'professional j2ee' book?!!
>
> The problem i have is that i need the username and password to be encrypted
> but i have heard that ssl hits performance quite badly!! I dont think that
> i could handle filtering, so what do you suggest for the security??
>
> What is the 'norm' for these such problems.
>
On an "http" connection, anyone who has access to the physical network can
snoop packets and see what is going on. That's why you're trying to
encrypt the username and password in the first place, right?
The problem is that username/password is not the only sensitive
information going back and forth -- the session identifier is also passed
up to the server on each request, either in a cookie or as part of the
URLs. This is how the server knows that a subsequent request belongs to
the logged-in user. Anyone who knows the session id can impersonate the
logged on user, and do anything that user is allowed to do.
If you switch back to "http" after logging in, that means the session id
will get transmitted in cleartext (and, no, there's nothing you can do to
encrypt *just* that). Therefore, any snooper on the network can see this
session id and start submitting their own requests with that session id.
The server thinks that you've already authenticated, so it lets you do
whatever you want.
All the snooper has to do is wait for someone to log on, observe their
next submit to the server, and snarf the session id ...
The bottom line is that using SSL only for the username/password is a
total waste of time from a security perspective. If you're not going to
encrypt the entire conversation (which includes the session ids), don't
even bother trying -- you will only get the illusion (or should I say,
*delusion*) of being more secure. In reality, you'd accomplish
nothing useful.
A more general statement of the principle: once you switch a session from
"http" to "https", you should never again accept a non-https request for
that same session. Applications that don't obey this rule are hopelessly
insecure, and should be avoided like the plague.
> Thanks Glen.
>
Craig McClanahan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
