tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Brunnsberg <>
Subject RE: Setting SSL for login pages
Date Tue, 21 Jun 2011 07:02:39 GMT
But if the user has the session then he or she can change the user
credentials (of course only for this site unless the password is shown in
the system, which would be really bad) or if the user has enough rights
add a new user which can be used by the hacker.
Remember how easy it is to hijack cookie files under normal HTTP with the
Firesheep extension for Firefox.

-----Original Message-----
From: Rafael Liu []
Sent: den 21 juni 2011 03:12
To: Tomcat Users List
Subject: RE: Setting SSL for login pages

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"
>> From: Rafael Liu []
>> 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
>> As I see, the way it is, all authenticated pages must be set to
> 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
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:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message