Thanks for the schooling, now it's all clear! I realy appreciate it.
On Tue, 2002-12-03 at 23:41, Craig R. McClanahan wrote: > > > On 3 Dec 2002, Alexander Wallace wrote: > > > Date: 03 Dec 2002 21:42:54 +0100 > > From: Alexander Wallace <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: Tomcat Users List <[EMAIL PROTECTED]> > > 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 <[EMAIL PROTECTED]> > > > > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > > > > To: Tomcat Users List <[EMAIL PROTECTED]> > > > > > 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:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > > > > -- > > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
