tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: Filters don't affect request dispatcher forward
Date Wed, 04 Dec 2002 05:41:25 GMT


On 3 Dec 2002, Alexander Wallace wrote:

> Date: 03 Dec 2002 21:42:54 +0100
> From: Alexander Wallace <tomcater@rwsoft-online.com>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> Subject: Re: Filters don't affect request dispatcher forward
>
> I have one extra question... Asumming one should not switch from https
> to http for security reasons... How does one handle the situation in
> which a user should login with a password (that one would like to
> encrypt so it can't be sniffed)? Should the whole app be run using
> https? Isn't that too hard on resources?
>

If you switch back, you're just as vulnerable as if you did the login
under non-SSL (in other words, the encryption of the username and
password on the SSL login gives you a *false* sense of security, not
anything real).  So why bother with all the extra effort in the first
place?

If you really care about the security of passwords, run the whole session
in SSL (and buy an extra CPU for your server, for goodness sake, if that
really matters).  If you don't care, life is much simpler if you just run
everything non-SSL.

If you decide to implement switching back to non-SSL on a public internet
app, please let me know where it is so I can avoid it.

> Does this not switching from https to http also apply when you have
> apache handling all the ssl comunication?
>

Yep ... the issue is the exposure of session id information in cleartext,
not the mechanics of how you processed it on your server.

>
> Thanks again in advance.

Craig


>
> On Tue, 2002-12-03 at 18:37, Alexander Wallace wrote:
> > Ok, thankyou for the advice, I will do that then. What i was trying to
> > do is actually what you are telling me i shouldn't.
> >
> > Again, thanks!
> >
> > On Tue, 2002-12-03 at 11:20, Craig R. McClanahan wrote:
> > >
> > >
> > > On 3 Dec 2002, Alexander Wallace wrote:
> > >
> > > > Date: 03 Dec 2002 10:21:19 -0600
> > > > From: Alexander Wallace <tomcater@rwsoft-online.com>
> > > > Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> > > > To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> > > > Subject: Re: Filters don't affect request dispatcher forward
> > > >
> > > > Hey I love that! Thanks, let me try it!
> > > >
> > > > Now, with this solution, I figure i can't fore stuff that doesn't match
> > > > the "to be secured" pattern to go over http and not https if it is
> > > > requested, right? I still can live with that, but it would sure be
> > > > cool..
> > > >
> > >
> > > I'm not sure what you're really asking, but ...
> > >
> > > If you declare a security constraint with a transport guarantee, any URL
> > > that matches the specified pattern(s) can *only* be accessed via SSL.  Any
> > > URL that does not match the pattern can be accessed over *either* SSL or
> > > non-SSL.
> > >
> > > One additional note -- web applications that allow a user to switch from
> > > SSL back to non-SSL on the same session are broken.  What you've just done
> > > is allowed anyone snooping the network to swipe the session id and
> > > impersonate your user (for example, click the "buy" button again using the
> > > credit card number that was entered on a secure page).
> > >
> > > You should program your apps that, once a user switches from non-SSL to
> > > SSL, you never again accept a non-SSL request for that same session id.
> > > If the user needs to go back (for example, after checking out of an
> > > ecommerce site you want to buy some more stuff), start a new session first
> > > (and clear the confidential data you might have captured).
> > >
> > > > Thanks!
> > >
> > > Craig
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> > > For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
> > >
> >
> >
> >
> > --
> > To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> > For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
> >
>
>
>
> --
> To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message