Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (athena.apache.org: domain of rafaelliu@gmail.com
 designates 209.85.160.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:from:date:message-id:subject:to
         :content-type;
        b=SPmcaXHlIdHZ6wEgxDsBRa4U6A4kxjwaJhCHRf2ylTszdPs/cs6fz6wPfKby3relmH
         PlZHwVfdNEv6QobRVhpyvYl4dIoURqzgNsjc2OmOYzpIbIaHjM8+R4pICJTXhGn4/+9T
         LG7/vkmwxM7vhPfddW1okcmAjI1t9mgaUNdf4=
MIME-Version: 1.0
In-Reply-To: <4E00C5F8.1070609@apache.org>
References: <BANLkTi=yNOCc=TXzRC_pDEwT478dBSttZQ@mail.gmail.com>
 <99C8B2929B39C24493377AC7A121E21FAFF8F14042@USEA-EXCH8.na.uis.unisys.com>
 <BANLkTim5p6mx3AApKMu7Jar54LJFb0Rpcw@mail.gmail.com>
 <4E00AEB0.80206@christopherschultz.net>
 <BANLkTimMdOAp5FV--nG8QJu4btvyMenpoA@mail.gmail.com>
 <4E00C5F8.1070609@apache.org>
From: Rafael Liu <rafaelliu@gmail.com>
Date: Tue, 21 Jun 2011 14:40:05 -0300
Message-ID: <BANLkTi=+QTgf7wP8451A_THkvZbNm14gTw@mail.gmail.com>
Subject: Re: Setting SSL for login pages
To: Tomcat Users List <users@tomcat.apache.org>
Content-Type: multipart/alternative; boundary=20cf303b427bcf936704a63c58ce

--20cf303b427bcf936704a63c58ce
Content-Type: text/plain; charset=ISO-8859-1

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
community.

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 <markt@apache.org> 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
> 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 <
> > chris@christopherschultz.net> 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: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>


-- 
Rafael Liu
+55 61 9608-7722
http://rafaelliu.net

--20cf303b427bcf936704a63c58ce--