Re: p1: additional security considerations

Amos Jeffries <squid3@treenet.co.nz> Tue, 23 April 2013 13:41 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 66AC721F96AA for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 06:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.491
X-Spam-Level:
X-Spam-Status: No, score=-10.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 ykWPXjApkpXx for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 23 Apr 2013 06:41:22 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id CB18421F96A6 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 23 Apr 2013 06:41:22 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UUdSu-0004HF-4m for ietf-http-wg-dist@listhub.w3.org; Tue, 23 Apr 2013 13:41:00 +0000
Resent-Date: Tue, 23 Apr 2013 13:41:00 +0000
Resent-Message-Id: <E1UUdSu-0004HF-4m@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1UUdSp-0004Ep-W9 for ietf-http-wg@listhub.w3.org; Tue, 23 Apr 2013 13:40:56 +0000
Received: from ip-58-28-153-233.static-xdsl.xnet.co.nz ([58.28.153.233] helo=treenet.co.nz) by lisa.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1UUdSo-0003b9-4s for ietf-http-wg@w3.org; Tue, 23 Apr 2013 13:40:55 +0000
Received: from [192.168.2.7] (103-9-43-128.flip.co.nz [103.9.43.128]) by treenet.co.nz (Postfix) with ESMTP id 31A87E6F39 for <ietf-http-wg@w3.org>; Wed, 24 Apr 2013 01:40:30 +1200 (NZST)
Message-ID: <51768F4B.8050505@treenet.co.nz>
Date: Wed, 24 Apr 2013 01:40:27 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <43ED2599-CE89-4C0C-8EEF-E3A6200E8662@mnot.net>
In-Reply-To: <43ED2599-CE89-4C0C-8EEF-E3A6200E8662@mnot.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=58.28.153.233; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-0.0
X-W3C-Hub-Spam-Report: SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: lisa.w3.org 1UUdSo-0003b9-4s 0e7dc2e93df98886989aa4a4c1b28d0a
X-Original-To: ietf-http-wg@w3.org
Subject: Re: p1: additional security considerations
Archived-At: <http://www.w3.org/mid/51768F4B.8050505@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/17501
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 23/04/2013 6:02 p.m., 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?

CVE-2009-0801 has active naties out there in the wild. At least two than 
I'm personally aware of today. I know that CVE is centered around 
interceptors which you like to avoid mentioning, but regular proxies and 
gateways can be used by an unsafe interceptor and become vulnerable 
themselves as a result. Some of the early attempts at a fix replaced the 
Host with raw-IP from the TCP connection and left the URL with hijacked 
domain name for example.

The take-home risk that should be pointed out is that a malicious client 
can poison the cache of a regular intermediary by presenting conflicting 
Host and URL information unless the intermediary utilizes the 
absolute-URL to protects itself from a mismatch (ie ignore the Host and 
use the absolute-URL given).

Intermediaries that purely do routing are not at risk of this, and if 
the pathway includes a later caching proxy it somewhat self-heals by 
whatever mechanism the cache uses to protect itself on receiving the 
garbage.



If you meant security risks when only routing intermediaries are used. 
I'm not aware of anything current other than the part they play in the 
above and related problems.


Amos