Re: p1: additional security considerations

Willy Tarreau <w@1wt.eu> Tue, 23 April 2013 06:16 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B61CB21F965F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 22 Apr 2013 23:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.149
X-Spam-Level:
X-Spam-Status: No, score=-10.149 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qw8kTvPnTRkM for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 22 Apr 2013 23:16:34 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id 26F3921F9601 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 22 Apr 2013 23:16:34 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUWVr-0000R1-N8 for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Apr 2013 06:15:35 +0000
Resent-Date: Tue, 23 Apr 2013 06:15:35 +0000
Resent-Message-Id: <E1UUWVr-0000R1-N8@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UUWVo-0000Q9-4C for ietf-http-wg@listhub.w3.org; Tue, 23 Apr 2013 06:15:32 +0000
Received: from 1wt.eu ([62.212.114.60]) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <w@1wt.eu>) id 1UUWVm-0005KG-Kk for ietf-http-wg@w3.org; Tue, 23 Apr 2013 06:15:31 +0000
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id r3N6F6cB010537; Tue, 23 Apr 2013 08:15:06 +0200
Date: Tue, 23 Apr 2013 08:15:06 +0200
From: Willy Tarreau <w@1wt.eu>
To: Mark Nottingham <mnot@mnot.net>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Message-ID: <20130423061506.GB8496@1wt.eu>
References: <43ED2599-CE89-4C0C-8EEF-E3A6200E8662@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <43ED2599-CE89-4C0C-8EEF-E3A6200E8662@mnot.net>
User-Agent: Mutt/1.4.2.3i
Received-SPF: pass client-ip=62.212.114.60; envelope-from=w@1wt.eu; helo=1wt.eu
X-W3C-Hub-Spam-Status: No, score=-3.0
X-W3C-Hub-Spam-Report: AWL=-3.015, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UUWVm-0005KG-Kk 69bf1bdaf83be811bc64e055d538b15b
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: additional security considerations
Archived-At: <http://www.w3.org/mid/20130423061506.GB8496@1wt.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17483
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On Tue, Apr 23, 2013 at 04:02:22PM +1000, Mark Nottingham wrote:
> Just wondering if we need to explicitly point out the security considerations
> around the following:
> 
> * Message routing -- it's somewhat common AIUI for intermediaries to only
> route on the Host header, for performance reasons; i.e., they do not
> reconstruct the effective request URI (as required by p1 5.5). I know there's
> a theoretical risk here, but is there a real-world risk that we should point
> out?

I see no particular risk since the Host header field is mandatory. Also in
practice, intermediaries which "route" requests tend to be very close to
the servers, at places where the security considerations are very specific
to the environment and explicitly covered in this intermediary's configuration.

Maybe we should point one thing though, which is not related to intermediaries
but all recipients in general : recipients of a request message which consider
the Host header field to decide about what content to serve must ensure of its
unicity before serving the request. Otherwise the risk is that an intermediary
could use a first instance to route the request and that a server would use the
last one for example.

> * Message delimitation - the consequences for getting message delimitation
> wrong (whether it's regarding multiple content-length headers, processing 1xx
> responses correctly, etc.) are now well-understood. Should we point it out
> explicitly in SC?

Yes I think that's important to add something about this, especially since
I discovered a few weeks ago a "security" product which was able to "fix"
badly chunked data ! It was quite scary to imagine that an improperly chunked
content which could possibly contain whatever is needed to embed different
contents could be converted to whatever this component considered valid by
skipping undesired data before chunk lengths and recomposing new valid ones!
It looks like some developers don't understand the security implications of
their choices.

Cheers,
Willy