tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Liu <>
Subject Re: Setting SSL for login pages
Date Tue, 21 Jun 2011 17:40:05 GMT
Well, if it's the spec I guess there's no much to argue. Maybe turn it into
an option, but I already got the feeling of the community. I won't insist as
this is my specific requirement and may not be of use to a wide range of the

Mark, there could be a MIM attack but that's yet another security issue. I
guess you are missing my point. The way it's being discussed (point all
security flaws), it's like we should also constraint the use of BASIC/DIGEST
auth to be used only with CONFIDENTIAL transport, enforce CLIENT-CERT, etc.
The point is not making the system all secure, is having the ability to
CHOOSE what to secure (which Servlet/JSP spec already allows, I'm bringing
to discussion just another degree).

Actually this MIM attack is introduced by the workaround, I agree it would
be better to specify the login page in the security constraints and that's
actually the reason for this email.

On Tue, Jun 21, 2011 at 1:25 PM, Mark Thomas <> wrote:

> 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
> > 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.
> Mark
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Rafael Liu
+55 61 9608-7722

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message