Re: [websec] Certificate Pinning via HSTS (.txt version)

Marsh Ray <> Tue, 13 September 2011 22:28 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 88CA621F8CAE for <>; Tue, 13 Sep 2011 15:28:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0EHV9BCW4RQO for <>; Tue, 13 Sep 2011 15:28:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7136E21F8CA5 for <>; Tue, 13 Sep 2011 15:28:07 -0700 (PDT)
Received: from ([]) by with esmtpa (Exim 4.72) (envelope-from <>) id 1R3bUa-000I9T-W3; Tue, 13 Sep 2011 22:30:13 +0000
Received: from [] (localhost []) by (Postfix) with ESMTP id A13376067; Tue, 13 Sep 2011 22:30:11 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Report-Abuse-To: (see for abuse reporting information)
X-MHO-User: U2FsdGVkX1+Z/9pm0yhs22lMX4VrPlT5s6dS7r4ZSfM=
Message-ID: <>
Date: Tue, 13 Sep 2011 17:30:13 -0500
From: Marsh Ray <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IETF WebSec WG <>
Subject: Re: [websec] Certificate Pinning via HSTS (.txt version)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Sep 2011 22:28:17 -0000

On 09/13/2011 04:24 PM, wrote:
> On 13 Sep 2011, at 21:35, Chris Palmer wrote:
>> <snip>
>> sites; small sites may have to choose no pinning or potentially
>> bricking their site (up to the maxAge window). This is not worse than
>> the status quo."""
> What about sites which don't currently use https at all? The DNS records
> for <> were redirected the
> other week. An attacker who could do that could redirect to https, then
> set a very long max-age pin. At that point, they'd be dependent on the
> browser vendor unpinning affected users, right?

Wouldn't they have to acquire a valid cert first? Not saying that's out 
of the realm of possibility, but...

I think you have a point. The whole premise of this is that there are 
circumstances under which some attacker can obtain such a cert. If this 
feature translates to a risk of perma-DoS for the (100.0 - epsilon)% of 
sites that don't adopt it immediately then it may be more dangerous than 
it's worth.

Consider an adversarial country like, say, Bananastan. They have an ISP 
or three, their own CA, and of course, no sense of humor.

They may one day be subject to some criticisms in the online press which 
they perceive as unfair. Or maybe something on a video sharing site is 
contrary to their customs and traditions.

So their local judge orders their local ISP to block the offending media 
provider. The ISP does this by advertising more specific BGP routes for 
the video site's netblocks(1).

Being mostly streaming data of little consequence, the video site has 
not yet set up HSTS or even has full support for HTTPS (2).

The ISP also sets the country's DNS resolvers to reply to name requests 
for the site with an IP address of a webserver where citizens can 
receive educational information(3).

To be sure they get everybody, they do something I didn't know could be 
done with DNS (4).

In order to save the the misguided users that accidentally used a 
subversive https: bookmark, the court orders the local CA to "do what it 
takes to make it work"(5).

And just to be sure the message sticks, they set a long term HSTS pin on 
this cert and/or their CA (6).

Hilarity ensues.

- Marsh

1. YouTube - Pakistan - 2008



4. China - 2010

5. [...]

6. Why wouldn't this attack work?