Good point Chuck. I agree with you, the webapp wouldn't be all secured. But there are 2 different things here:
* the issue with the plain password * the issue with session hijacking The first one first gives the hacker a private information about the user (which can even the used by the user somewhere else). The hacker will have the actual user's credentials, and will be able to login at will. The second one doesn't necessarily exposes user's informations. The hacker can pretend to be the user, but only for the time of the session. Even tho there are tricks to keep the session alive [almos] forever, this is essentially different from having the user's credential. I see them at different levels of security. Using the same logic, one can say that there's no point in using DIGEST authentication if there's still room for session hijacking. Much like BASIC / DIGEST or CONFIDENTIAL / INTEGRAL provides different levels of security, I think the two cases mentioned also do.Giving these kind of options to the webapp can make NFR (like performance) easier to meet and infrastructure easier to configure (like rewriting on Apache). What do you think? On Jun 20, 2011 6:50 PM, "Caldarale, Charles R" <chuck.caldar...@unisys.com> wrote: >> From: Rafael Liu [mailto:rafael...@gmail.com] >> Subject: Setting SSL for login pages > >> I think it would be natural something like this: > >> <security-constraint> >> <web-resource-collection> >> <web-resource-name>SSL login</web-resource-name> >> <url-pattern>/login/*</url-pattern> >> </web-resource-collection> >> <user-data-constraint> >> <transport-guarantee>CONFIDENTIAL</transport-guarantee> >> </user-data-constraint> >> </security-constraint> > > The login pages are usually not specified in the <url-pattern>; only the pages to be protected. Login pages are not normally directly accessed by a user, but are only presented when the user attempts to access a protected page. > >> As I see, the way it is, all authenticated pages must be set >> to CONFIDENTIAL also > > Not also, instead. > >> But if the user IS authenticated he is forced to use HTTPS >> too, and that I was trying to avoid. > > Think about it: if the secure traffic is only for the login page, anyone could access the not-really-protected pages by sniffing the sessionid used on the unsecure connection - you would have no security. > > - Chuck > > > THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY MATERIAL and is thus for use only by the intended recipient. If you received this in error, please contact the sender and delete the e-mail and its attachments from all computers. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
