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

"Miller, Timothy J." <> Tue, 17 November 2015 04:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 646EC1AD04E for <>; Mon, 16 Nov 2015 20:33:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.785
X-Spam-Status: No, score=-4.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.585] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id L0kCCZpzk8_o for <>; Mon, 16 Nov 2015 20:33:13 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D06C51AD049 for <>; Mon, 16 Nov 2015 20:33:12 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 216116C0750; Mon, 16 Nov 2015 23:33:12 -0500 (EST)
Received: from imshyb01.MITRE.ORG ( []) by (Postfix) with ESMTP id 131F06C06BB; Mon, 16 Nov 2015 23:33:12 -0500 (EST)
Received: from imshyb01.MITRE.ORG ( by imshyb01.MITRE.ORG ( with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 16 Nov 2015 23:33:11 -0500
Received: from ( by imshyb01.MITRE.ORG ( with Microsoft SMTP Server (TLS) id 15.0.1130.7 via Frontend Transport; Mon, 16 Nov 2015 23:33:11 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.1.325.17; Tue, 17 Nov 2015 04:33:09 +0000
Received: from ([]) by ([]) with mapi id 15.01.0318.003; Tue, 17 Nov 2015 04:33:09 +0000
From: "Miller, Timothy J." <>
To: "" <>
Thread-Topic: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?
Date: Tue, 17 Nov 2015 04:33:08 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results: spf=none (sender IP is );
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: []
x-microsoft-exchange-diagnostics: 1; BY2PR09MB111; 5:F6IF1A3e60Mc0k89aT8w5VPidBNTwHNyaRgmGJ6SwKFw3LwJunF/EvgGBUqQyCWc+kXFyhM4E9t3jTIV/h4ACOgcxpJBDiSLF5oCZtcpWNMnb8nH8uUx2XO1jQaNmy5qf+5C+UDvMed2QD843xfrBA==; 24:kcxnj5V9J3uEpVnVwzGMz5gdhLVtVJvfCfjFu2RU2u28Ptctcd9A/wEzM1kMWz/pQqM4JHX9RdxuCgfMoaWImXpK5HHElM6efVGCrARhpsQ=; 20:RrcpY89CIBQKwobJ3oxxW1I6Xhermja+mItVo4AkksVryenGBubP1ArYbXmJSdtCrEKFaYEJP5PGJSifejl7pQ==
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR09MB111;
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(520078)(5005006)(3002001)(10201501046); SRVR:BY2PR09MB111; BCL:0; PCL:0; RULEID:; SRVR:BY2PR09MB111;
x-forefront-prvs: 07630F72AD
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(199003)(189002)(76176999)(99286002)(189998001)(2900100001)(2950100001)(106116001)(5007970100001)(40100003)(5008740100001)(66066001)(50986999)(586003)(2501003)(122556002)(11100500001)(5004730100002)(106356001)(36756003)(5002640100001)(105586002)(82746002)(1411001)(86362001)(2351001)(87936001)(33656002)(54356999)(92566002)(110136002)(101416001)(77096005)(81156007)(5001920100001)(83716003)(93886004)(102836002)(97736004)(5001960100002)(10400500002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR09MB111;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2015 04:33:08.6491 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: c620dc48-1d50-4952-8b39-df4d54d74d82
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR09MB111
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: Tue, 17 Nov 2015 04:33:14 -0000

> 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.

That would be a user agent problem, solved by user agent configuration.  

E.g., Microsoft has an extensive set of permissions associated with each trust anchor (in the certificates mmc snap-in, drill down to a root cert, right-click Properties, and you'll see them on the General tab).  "Trusted MitM" could be added to that set.  

Should I point out the obvious here--that list is MUCH longer than the list of KUs and EKUs put together, yet MS doesn't come looking for a new extension every time they want to restrict use.

I also find it odd that advocates for this extension are uncomfortable with the idea of any active MitM, but are perfectly OK with a commercial issuer controlling whether or not your client accepts a cert they issue for active MitM purposes.

If you're going to require UA configuration to accept the active MitM, then it's far easier to mark the user agent's trust store than it is to add an optional extension to the certificate *AND* require the user agent to process, track, and add a UI for the user when it's found.

Take the path of least resistance (and smallest code change), people.

-- T