Re: [websec] cookie injection attack via superdomain of HSTS Host (was: [Technical Errata Reported] RFC6797 (4075)
"Eric Lawrence" <e_lawrence@hotmail.com> Sat, 09 August 2014 17:46 UTC
Return-Path: <e_lawrence@hotmail.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDE9A1A00EF for <websec@ietfa.amsl.com>; Sat, 9 Aug 2014 10:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.132
X-Spam-Level:
X-Spam-Status: No, score=0.132 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sJrg-cSybjai for <websec@ietfa.amsl.com>; Sat, 9 Aug 2014 10:46:51 -0700 (PDT)
Received: from COL004-OMC1S11.hotmail.com (col004-omc1s11.hotmail.com [65.55.34.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F381A00EC for <websec@ietf.org>; Sat, 9 Aug 2014 10:46:50 -0700 (PDT)
Received: from COL131-DS9 ([65.55.34.8]) by COL004-OMC1S11.hotmail.com with Microsoft SMTPSVC(7.5.7601.22712); Sat, 9 Aug 2014 10:46:50 -0700
X-TMN: [sHQpQ3o9yLsQUlgoX1KmwS/2bBiI90B7]
X-Originating-Email: [e_lawrence@hotmail.com]
Message-ID: <COL131-DS9E68224E55DB0534D47F5F0EF0@phx.gbl>
From: Eric Lawrence <e_lawrence@hotmail.com>
To: =JeffH <Jeff.Hodges@KingsMountain.com>
References: <53E572EA.3000301@KingsMountain.com>
In-Reply-To: <53E572EA.3000301@KingsMountain.com>
Date: Sat, 09 Aug 2014 12:46:47 -0500
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="iso-8859-1"; reply-type="response"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
Importance: Normal
X-Mailer: Microsoft Windows Live Mail 16.4.3528.331
X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331
X-OriginalArrivalTime: 09 Aug 2014 17:46:50.0626 (UTC) FILETIME=[E6222620:01CFB3F9]
Archived-At: http://mailarchive.ietf.org/arch/msg/websec/HTRePRgUKBRiKHEH5ZlW5usepZU
X-Mailman-Approved-At: Sat, 09 Aug 2014 13:21:11 -0700
Cc: IETF WebSec WG <websec@ietf.org>
Subject: Re: [websec] cookie injection attack via superdomain of HSTS Host (was: [Technical Errata Reported] RFC6797 (4075)
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec/>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 09 Aug 2014 17:49:40 -0000
Thanks, Jeff-- > I.e., it's poor practice to have an HSTS Host at https://sub.example.com > yet also answer at > https://example.com without also declaring the latter as an HSTS Host. Yes, but even further, sending HSTS at example.com is insufficient, because a user may only ever visit https://www.example.com. That otherwise-protected user would always be at risk from a cookie injection attack mounted by a MITM who injects a reference to http://example.com (or even http://nonexistentpeer.example.com) which he himself would answer. A website can mitigate this threat by always including a resource reference served by the root such that domain-tree-wide HSTS policy is set if any subdomain is ever visited. The best scenario, of course, is if a site's HSTS policy is pre-deployed to the browser, and even better would be if progress is made on convincing TLDs (e.g. *.secure, *.bank, *.trust, etc) to opt-in to UA-enforcement of HSTS for the entire TLD. -Eric -----Original Message----- From: =JeffH Sent: Friday, August 8, 2014 8:01 PM To: Eric Lawrence Cc: IETF WebSec WG Subject: Re: cookie injection attack via superdomain of HSTS Host (was: [Technical Errata Reported] RFC6797 (4075) [ trimming to: and cc: as I think most everyone is on websec@ ] Hi Eric, thanks for submitting this errata. Barry & everyone: actually, this issue is in S 14 "Security Considerations" of RFC6797, and I think Eric is correct that that subsection "14.4. The Need for includeSubDomains" is overlooking this detail, and hence is actually an errata (more or less). However, the text I'd use to correct it would be somewhat different than Eric's proposed text (tho it'd build on it). Overall, I think we discussed this aspect of things during our development of HSTS and rationale/defense overall amounts to.. 1. HSTS Hosts really need to declare HSTS Policy at their top-level domain name whether or not they are reachable at other subdomains thereof and regardless of whether they employ . I.e., it's poor practice to have an HSTS Host at https://sub.example.com yet also answer at https://example.com without also declaring the latter as an HSTS Host. In terms of there being a policy authority boundary between one's HSTS Host and it's immediate superdomain -- eg between example.com. and com. -- that to some degree is presently addressed by language in RFC6265 section 5.3 step 5 --- but nominally I think Eric is overall correct and this "cookie injection attack via superdomain of HSTS Host" isn't properly discussed in RFC6797 and that it would (today) be an issue for example if foo.example.com is a distinct entity from example.com, and example.com _is not_ a "public suffix". Essentially, i think there's a subtle impedance mismatch between HSTS's Storage Model and that of HTTP cookies per RFC6265, and it's arguably a spec bug in rfc6797 that it isn't explicitly called out. Thus Barry is correct that this is treading into "domain boundary" aka "domain policy authority" territory <dbound@ietf.org> -- and thus is another example of why the latter work is important (several of us, along with Andrew Sullivan, are chipping away at it). Also, there's a recent draft academic paper that's been mentioned on other lists that I am going to post a reference to on this list -- it goes into HSTS deployment common mistakes as well as best practices and touches on issues similar to this. ah, I see Eric's proposed best practice in his reply to Yoav, and yeah, that's one way to address this issue, and could ostensibly be included in a spec update -- but the actual errata is the above-noted impedance mismatch between cookies' and HSTS's storage models (and also the lack of cookie's declaring their originating origin). HTH, =JeffH