Re: [websec] Question on Pinning Overrides

Chris Palmer <> Tue, 14 October 2014 16:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D24271A8BBE for <>; Tue, 14 Oct 2014 09:58:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8swnbSHR88dD for <>; Tue, 14 Oct 2014 09:58:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 027F61A8AE4 for <>; Tue, 14 Oct 2014 09:58:13 -0700 (PDT)
Received: by with SMTP id h136so17236568oig.33 for <>; Tue, 14 Oct 2014 09:58:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/uDmFKl/wrdHiSnFZKMJ6l3ljlqa/I8TG+3j9J+T9ZM=; b=XIlvJBm3CUHiiWY4q1aXh/qBFMqudWx3KI8PIqMS9rVpo7ExKFrAwjweXox2IJ1u35 iO9ycvhgH5mTkxdd7KBdvFUUOtLzbwtOr5uYt07uNv/FS4Cl/ihnuTCykGFlDXStAb4i 2tHpBBPC/slB8mjJNkUFZJG7Ckzbw9kYlAZc0jLoM4PU/2Qh77DLjpXuPooHeNRbOjFh IScZPqdAQHQqDAwZVmygUJbnRM+HZ2KwqkUiHFgOOdZLjR92bUCLi3jgNBHjGBLM11Z2 k6lbk5rJEvTj7ChlmGUYKbL227unQIvog/kVnNKr6tgkw3oXJS1B3Peh1HBQc4AjzCg1 Qfxw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/uDmFKl/wrdHiSnFZKMJ6l3ljlqa/I8TG+3j9J+T9ZM=; b=DH8UqIB8bx8HMVoLwC5hr2NLK8nvcQG9usnnZMCRF1jmtJL0CNUfnh+Bin51yKMsdq g+/YhoS0woIVdtHFOWff/ZzmB4om86ZWbajJRBvSkYiFdBbACPY8MDZ9FUWcg2YA7yZI I2t4AHXBHoidNccJD1U/uxB5j77O3by/KZboANYW3Ul6CJ0Eu4Vm5CADNF871s6Ip8sn vqyFEMKOyrimHu3USEzR3f6Yw1AXSysxKIVeXOWZKfLG2g4xzn/Fi6vE7oAF4Rz5b4uH 7u/wqojYzt+6BYkYVf4Gs17dXdtn7HpFfH8/ps6JNsE4q5sLStoDW1WfPkuD8+FQVuoc 8y6A==
X-Gm-Message-State: ALoCoQle+TDGosSMmxJlA3sl+QgFOTx1vtp6VWlbfm4hdRjDWyxM7lB5xRfVPMhBQIAyYLSWagcA
MIME-Version: 1.0
X-Received: by with SMTP id cg2mr5715776obc.21.1413305893373; Tue, 14 Oct 2014 09:58:13 -0700 (PDT)
Received: by with HTTP; Tue, 14 Oct 2014 09:58:13 -0700 (PDT)
In-Reply-To: <>
References: <>
Date: Tue, 14 Oct 2014 09:58:13 -0700
Message-ID: <>
From: Chris Palmer <>
Content-Type: text/plain; charset="UTF-8"
Cc: IETF WebSec WG <>
Subject: Re: [websec] Question on Pinning Overrides
X-Mailman-Version: 2.1.15
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, 14 Oct 2014 16:58:16 -0000

On Tue, Oct 14, 2014 at 9:33 AM, Jeffrey Walton <> wrote:

> Section 2.7 states:
>    UAs MAY choose to implement additional sources of pinning
>    information, such as through built-in lists of pinning information.
>    Such UAs should allow users to override such additional sources,
>    including disabling them from consideration.

This is so that, for example, there is at least a chance people can
recover from stale built-in pin sets. (Chrome currently handles this
by skipping Pin Validation for built-in pin sets if Chrome detects
that it was built 10 weeks or more in the past.)

> >From section 2.7, I understand a _user_ can provide an override to a
> _preloaded_ pinset. But I don't see where a user is provided the
> authority to override a non-preloaded pinset. And I don't see where an
> external entity is provided authority to override a preloaded or
> non-preloaded pinset.
> Is this correct?
> If correct, shouldn't the user be allowed to override both preloaded
> and non-preloaded pinsets?
> If correct, won't that break Chrome with respect to
> (see section
> "What about MITM proxies, Fiddler etc?")?

Section 2.6:

""" For example, a UA may disable Pin Validation for Pinned Hosts
whose validated certificate chain terminates at a user-defined trust
anchor, rather than a trust anchor built-in to the UA (or underlying

So that's how you make Fiddler work, among other things.