Re: Caching 412 responses

Mark Nottingham <mnot@mnot.net> Mon, 20 May 2013 01:46 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 D966821F84AF for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 19 May 2013 18:46:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.209
X-Spam-Level:
X-Spam-Status: No, score=-9.209 tagged_above=-999 required=5 tests=[AWL=1.390, 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 YlBeh6XABC1L for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 19 May 2013 18:46:54 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) by ietfa.amsl.com (Postfix) with ESMTP id EF5B221F8532 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 19 May 2013 18:46:53 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1UeFAp-0002h3-TW for ietf-http-wg-dist@listhub.w3.org; Mon, 20 May 2013 01:46:03 +0000
Resent-Date: Mon, 20 May 2013 01:46:03 +0000
Resent-Message-Id: <E1UeFAp-0002h3-TW@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UeFAe-0002gK-Fx for ietf-http-wg@listhub.w3.org; Mon, 20 May 2013 01:45:52 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <mnot@mnot.net>) id 1UeFAd-0007e2-J7 for ietf-http-wg@w3.org; Mon, 20 May 2013 01:45:52 +0000
Received: from [192.168.1.80] (unknown [118.209.105.214]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 8F22A22E257; Sun, 19 May 2013 21:45:28 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <006D3C4B-6BBB-4172-A642-BD81AC85686F@mnot.net>
Date: Mon, 20 May 2013 11:45:25 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <3797752C-7299-425D-941E-6FF08F8EC904@mnot.net>
References: <FAC047C9-0DD2-4159-8FF9-760BE3160B49@niven-jenkins.co.uk> <006D3C4B-6BBB-4172-A642-BD81AC85686F@mnot.net>
To: Ben Niven-Jenkins <ben@niven-jenkins.co.uk>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.389, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001
X-W3C-Scan-Sig: maggie.w3.org 1UeFAd-0007e2-J7 5696c1dae85e191d6e78dc490be79d77
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Caching 412 responses
Archived-At: <http://www.w3.org/mid/3797752C-7299-425D-941E-6FF08F8EC904@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/18033
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>

I'm closing this issue; if you still have a concern, please bring it up and we'll reopen.

Regards,


On 17/05/2013, at 1:26 PM, Mark Nottingham <mnot@mnot.net> wrote:

> Hi Ben,
> 
> In the current model, the server *has* to make a 412 explicitly cacheable (e.g, with CC: max-age, as you do below) or otherwise usable (e.g., with CC: public) for an intermediary to store it, so I don't see how this is exploitable; the server shouldn't make those responses cacheable (and indeed, AFAICT none do).
> 
> The same could be said about 413 (Request Entity Too Large), 415 (Unsupported Media Type), 416 (Requested Range Not Satisfiable), 428 (Precondition Required), and probably a few more. If someone wants to make these responses cacheable, they need to do the work to make them properly cacheable (by including Vary).
> 
> Make sense?
> 
> Regards,
> 
> 
> 
> On 16/02/2013, at 9:57 PM, Ben Niven-Jenkins <ben@niven-jenkins.co.uk> wrote:
> 
>> Colleagues,
>> 
>> RFC2616 and the HTTPbis drafts allow an intermediary to cache a 412 response to a request with an If-Match header, if the response contains appropriate Cache-Control headers.
>> 
>> My understanding of the specifications is that the intermediary is then within its right to serve the cached 412 response in response to subsequent GET requests that do not contain an If-Match header (see bottom of this mail for an example set of requests/responses that illustrate what I'm trying to describe).
>> 
>> This seems problematic because if an attacker knows an origin returns cacheable 412 responses, the attacker could fill the cache with 412 responses for a set of URLs (from that origin) by making spurious If-Match requests it knows will return 412 responses, and those 412 responses would subsequently be served up to other clients instead of the 'real' response the origin would have given if the 412 was not cacheable or if the attacker had not poisoned the intermediary's cache with 412s.
>> 
>> I was wondering whether this is a gap in the spec and cacheable 412 responses should have an explicit (or implicit?) Vary: If-Match semantic associated with them?
>> 
>> Or, whether it is purposely the way it is and is a case of providing the rope and letting people hang themselves if they so choose (Origin servers can always add the Vary: header if they care about cache poisoning, intermediaries can always not cache 412 responses, etc.).
>> 
>> An example (with only the relevant Headers included for compactness) of what I am talking about would be:
>> 
>> First request:
>> GET /foo HTTP/1.1
>> Host: example.com
>> If-Match: "thisisnotanetag"
>> 
>> HTTP/1.1 412 Precondition Failed
>> Cache-Control: max-age=900
>> ...rest of response...
>> 
>> 
>> Subsequent request:
>> GET /foo HTTP/1.1
>> Host: example.com
>> 
>> HTTP/1.1 412 Precondition Failed
>> Age: 10
>> Cache-Control: max-age=900
>> ...rest of response...
>> 
>> Thanks
>> Ben
>> 
>> 
> 
> --
> Mark Nottingham   http://www.mnot.net/
> 
> 
> 
> 

--
Mark Nottingham   http://www.mnot.net/