[websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert
"websec issue tracker" <trac+websec@trac.tools.ietf.org> Sun, 15 January 2012 02:52 UTC
Return-Path: <trac+websec@trac.tools.ietf.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87C1621F84AF for <websec@ietfa.amsl.com>; Sat, 14 Jan 2012 18:52:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 RMC8fDyJsBFa for <websec@ietfa.amsl.com>; Sat, 14 Jan 2012 18:52:50 -0800 (PST)
Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id A9B2C21F84AA for <websec@ietf.org>; Sat, 14 Jan 2012 18:52:50 -0800 (PST)
Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from <trac+websec@trac.tools.ietf.org>) id 1RmGCh-0000qO-W8; Sat, 14 Jan 2012 21:52:20 -0500
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: websec issue tracker <trac+websec@trac.tools.ietf.org>
X-Trac-Version: 0.12.2
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.12.2, by Edgewall Software
To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com
X-Trac-Project: websec
Date: Sun, 15 Jan 2012 02:52:19 -0000
X-URL: http://tools.ietf.org/websec/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/websec/trac/ticket/34
Message-ID: <070.daef625ac2bff2b5e11ec0521f0bc368@trac.tools.ietf.org>
X-Trac-Ticket-ID: 34
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: draft-ietf-websec-strict-transport-sec@tools.ietf.org, jeff.hodges@kingsmountain.com, websec@ietf.org
X-SA-Exim-Mail-From: trac+websec@trac.tools.ietf.org
X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false
Resent-To:
Resent-Message-Id: <20120115025250.A9B2C21F84AA@ietfa.amsl.com>
Resent-Date: Sat, 14 Jan 2012 18:52:50 -0800
Resent-From: trac+websec@trac.tools.ietf.org
Cc: websec@ietf.org
Subject: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 15 Jan 2012 02:52:51 -0000
#34: HSTS cache manipulation and misuse by server enabled by wildcard cert See.. The Double-Edged Sword of HSTS Persistence and Privacy -- by Mikhail Davidov http://haxsys.net/2011/04/the-double-edged-sword-of-hsts-persistence-and- privacy/ summary: This technique allows a web app on one domain to surreptitiously send a message to another web app on another domain via manipulation of the HSTS cache... If server wields a wildcard cert, eg for "*.example.com", then example.com can create any number of subdomains of example.com, with any subdomain name, and then direct user agents to fetch resources from these subdomains. If HSTS Policy is returned for each of these subdomains, and includeSubDomains is not used, then any number of entries will be created in in the user agent's HSTS store. E.g., an web page like the below would accomplish this.. [img]https://charcount-5.example.com/setbit.png[/img] -- this stores the char count of the msg [img]https://0-H.example.com/setbit.png[/img] [img]https://1-E.example.com/setbit.png[/img] [img]https://2-L.example.com/setbit.png[/img] [img]https://3-L.example.com/setbit.png[/img] [img]https://4-O.example.com/setbit.png[/img] These entries can be read back by some other web application under some other domain name by causing the user agent to send HTTP requests to example.com in order to brute-force the character count subdomain name -- the server responds whether the name is available over just http -- which means it is a miss, or over HTTPS, which is a hit.. http://charcount-1.trackingexampledomain.com/getbit.png [ Server: HTTP ] http://charcount-2.trackingexampledomain.com/getbit.png [ Server: HTTP ] http://charcount-3.trackingexampledomain.com/getbit.png [ Server: HTTP ] http://charcount-4.trackingexampledomain.com/getbit.png [ Server: HTTP ] http://charcount-5.trackingexampledomain.com/getbit.png [ Server: HTTPS! ] -- msg char count is 5 Then the web app can brute force each character of the message in a similar fashion. the original message-sending domain web app can clear the cached message by causing the user agent to re-request resources from the same dubdomains and returning a HSTS header for each with max-age=0. For a resolution, Mikhail suggests.. "My proposal is to amend the draft to force the includeSubDomains flag on wildcard certificates. This would limit them to only one entry in the browsers HSTS database and make the technique above prohibitively expensive to non-CA owners as a separate signed SSL certificate would be needed for every bit of information stored and limit encoding options." -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-websec-strict-transport- jeff.hodges@… | sec@… Type: defect | Status: new Priority: major | Milestone: Component: strict- | Version: transport-sec | Keywords: Severity: Active WG | Document | -------------------------+------------------------------------------------- Ticket URL: <http://trac.tools.ietf.org/wg/websec/trac/ticket/34> websec <http://tools.ietf.org/websec/>
- [websec] #34: HSTS cache manipulation and misuse … websec issue tracker
- Re: [websec] #34: HSTS cache manipulation and mis… Yoav Nir
- Re: [websec] #34: HSTS cache manipulation and mis… Adam Barth
- Re: [websec] #34: HSTS cache manipulation and mis… =JeffH
- Re: [websec] #34: HSTS cache manipulation and mis… websec issue tracker