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�^��