Re: p1: additional security considerations

Amos Jeffries <> Tue, 23 April 2013 13:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 66AC721F96AA for <>; Tue, 23 Apr 2013 06:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.491
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ykWPXjApkpXx for <>; Tue, 23 Apr 2013 06:41:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CB18421F96A6 for <>; Tue, 23 Apr 2013 06:41:22 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UUdSu-0004HF-4m for; Tue, 23 Apr 2013 13:41:00 +0000
Resent-Date: Tue, 23 Apr 2013 13:41:00 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UUdSp-0004Ep-W9 for; Tue, 23 Apr 2013 13:40:56 +0000
Received: from ([] by with esmtp (Exim 4.72) (envelope-from <>) id 1UUdSo-0003b9-4s for; Tue, 23 Apr 2013 13:40:55 +0000
Received: from [] ( []) by (Postfix) with ESMTP id 31A87E6F39 for <>; Wed, 24 Apr 2013 01:40:30 +1200 (NZST)
Message-ID: <>
Date: Wed, 24 Apr 2013 01:40:27 +1200
From: Amos Jeffries <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=;;
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: 1UUdSo-0003b9-4s 0e7dc2e93df98886989aa4a4c1b28d0a
Subject: Re: p1: additional security considerations
Archived-At: <>
X-Mailing-List: <> archive/latest/17501
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-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 

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.