Re: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert
Yoav Nir <ynir@checkpoint.com> Sun, 15 January 2012 07:13 UTC
Return-Path: <ynir@checkpoint.com>
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 556E821F847F for <websec@ietfa.amsl.com>; Sat, 14 Jan 2012 23:13:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.461
X-Spam-Level:
X-Spam-Status: No, score=-10.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 OB6JejiThNq3 for <websec@ietfa.amsl.com>; Sat, 14 Jan 2012 23:13:43 -0800 (PST)
Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id BF5A121F847C for <websec@ietf.org>; Sat, 14 Jan 2012 23:13:42 -0800 (PST)
X-CheckPoint: {4F1279FF-0-1B221DC2-1FFFF}
Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q0F7DePc002090 for <websec@ietf.org>; Sun, 15 Jan 2012 09:13:40 +0200
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 15 Jan 2012 09:13:40 +0200
From: Yoav Nir <ynir@checkpoint.com>
To: IETF WebSec WG <websec@ietf.org>
Date: Sun, 15 Jan 2012 09:13:23 +0200
Thread-Topic: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert
Thread-Index: AczTVTUfiP0VnLRwRq+hT01unfbUEw==
Message-ID: <124D1609-2615-48DC-B130-31C644BA9F74@checkpoint.com>
References: <070.daef625ac2bff2b5e11ec0521f0bc368@trac.tools.ietf.org>
In-Reply-To: <070.daef625ac2bff2b5e11ec0521f0bc368@trac.tools.ietf.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [websec] #34: HSTS cache manipulation and misuse by server enabled by wildcard cert
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
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: Sun, 15 Jan 2012 07:13:44 -0000
Interesting. But I don't see how subdomains help. If I have a website called charcount-5.example.com, and I use a wildcard *.example.com certificate, the HSTS entry is still written for charcount-5.example.com. Adding subdomains would affect *.charcount-5.example.com, not 0-H.example.com. I wouldn't want to force the includeSubdomains, as there may be valid reasons to have a subdomain of example.com that is HTTP, whereas the decision on buying a wildcard certificate is a matter of cost and convenience. Yoav On Jan 15, 2012, at 4:52 AM, websec issue tracker wrote: > #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 mailing list > websec@ietf.org > https://www.ietf.org/mailman/listinfo/websec > IƧ��[�(^rC�{S�֥I�.�+r�^��
- [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