tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Setting SSL for login pages
Date Tue, 21 Jun 2011 16:25:28 GMT
On 21/06/2011 17:05, Rafael Liu wrote:
> Hey Chris,
> as you said, each problem compromise different kinds of things: account vs
> credentials. And I think they have different kind of consequences and can
> be, each one , dangerous its own way. I brought the discussion into the list
> because I thought it was relevant.
> Looking at the code, a fix would be quite simple: replacing the forward() by
> a send(). To have the same behaviour as today to the end user, a few more
> things should be done, because we would be changing from a POST to a GET,
> but AFAIK it's a matter of saving the target URL as a request parameter.
> Back button, bookmark and normal login should work.

The spec requires that POST is used.

> I agree it's kind of a philosophical question but I see some real
> implications. Anyway, for the record, as a quick and dirty fix I set the
> full URL with https schema in /form@action. But the hosting page isn't HTTPS
> and the user may feel unsecure..

And rightly so. If the login page is not delivered over SSL that opens
the way for various MITM middle attacks.

> On Tue, Jun 21, 2011 at 11:46 AM, Christopher Schultz <
>> wrote:
> Rafael,
> On 6/20/2011 8:12 PM, Rafael Liu wrote:
>>>> 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
> This does become somewhat of a philosophical question. I agree that
> credentials should always be secured. If the service itself is not
> particularly sensitive, I think it's acceptable to use SSL only during
> authentication.

That is very much the minority view. I find it very hard to imagine any
scenario where a user needs to be authenticated (and hence the password
needs to be protected) but it is OK for the session to be compromised
without that being considered a security breach.


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

View raw message