Re: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?

Yoav Nir <> Mon, 16 November 2015 05:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 4AA5D1B2CE0 for <>; Sun, 15 Nov 2015 21:25:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_34=0.6, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JXxYWPXWYHpF for <>; Sun, 15 Nov 2015 21:25:39 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E71151B2CDE for <>; Sun, 15 Nov 2015 21:25:38 -0800 (PST)
Received: by wmec201 with SMTP id c201so103359762wme.1 for <>; Sun, 15 Nov 2015 21:25:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=A0f2r9sWkzb/99A8YJ+p69J+9t5adjMDk4nfNe6us84=; b=FPob/RxSheSyGJH0rAeB7rj6zqctD7WUM7OWeN1bNlgcQvY7vz7DDwf5382xLligej 0TmO1afM4w6pMBMLoHkrcut+aEFJKgP9Y50YsDrMobVCMzje2HAry8jTgb++WWo3b8H8 EYKFRq38fFaVYr3JUlfbxd/CuccQE9gioPr5teB8GD6yvBcwHF34JJbTEh0doyAanDHQ Vs70gbJFJr7TrCxisQj4DCf8cOKOLXDiVoj6tkiXShE4FHp5+0nxnTLwbqhSQIEpZURq B0rEI8fB+PYobhtge2JUgXZE33eK8iee4e3fQvfkvimNH+IHSmDxifbjdKGJ4z7OUXWn NEgw==
X-Received: by with SMTP id oy1mr14138932wjb.137.1447651537460; Sun, 15 Nov 2015 21:25:37 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id t194sm16594808wmt.11.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 15 Nov 2015 21:25:36 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 16 Nov 2015 07:25:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <>
Cc: PKIX <>
Subject: Re: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Nov 2015 05:25:40 -0000

> On 16 Nov 2015, at 5:54 AM, Jeffrey Walton <> wrote:
>> No certificate marking is needed, though.  Clients could invoke alternative certificate processing when a certificate name match fails but the certificate chains to a trust anchor marked as "trusted for proxy."
> You will have to forgive my ignorance... For user agents and other
> software that conforms to RFC 7469 and provides the overrides, how are
> they supposed to know when to break a known good pinset if its not
> signaled? That is, how do they differentiate between the "good" bad
> guys and the "bad" bad guys.
> Examples:
>  Corporate DLP - ACME, LLC sets Proxy key usage for subordinate
>      and server certificate. User agent allows an override to the Pinset
>      in accordance with RFC 7469 because they declared the intent and
>      confirmed with the user.
>  Diginotar - Bad guy starts minting server certificates. Proxy is
>      not set in subordinate CA or server certificate. The user agent
>      refuses to break the known good pinset according to RFC 7469.
> And RFC's 7469 {SHOULD NOT|MUST NOT} logging requirement can be lifted
> or refined so the failures can be reported instead of making user
> agents complicit in the cover-up.
> RFC 7469's overrides opened a can of worms, but its probably best in
> the big picture. This stuff has always been going on and allowed to
> fester behind the scenes in a "don't ask don't tell" fashion. Now that
> its been brought to the fore-front, it can be dealt with accordingly.

Before RFC 7469 (pins in HTTP) there were pre-loaded pins for a select group of servers. The policy of Chrome at the time was to allow “wrong” keys whenever the root of trust was not part of the default set that comes with the operating system. This allowed for trust anchors installed specifically for proxy to sign certificates for The unfortunate side-effect was that it allowed any corporate CA to also sign such certificates, which it shouldn’t. 

It would be nice if a trust anchor could be marked as “for proxy” vs “just another CA”, but no OS or browser provides that distinction.