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

Peter Bowen <> Tue, 24 November 2015 20:40 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5855F1A89A7 for <>; Tue, 24 Nov 2015 12:40:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Fb4ETgZYeOQN for <>; Tue, 24 Nov 2015 12:40:55 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c03::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0D8A61A89A1 for <>; Tue, 24 Nov 2015 12:40:55 -0800 (PST)
Received: by padhx2 with SMTP id hx2so32825719pad.1 for <>; Tue, 24 Nov 2015 12:40:54 -0800 (PST)
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=vpkkhcwV/8NX0sKiF1FEoMDNQOauL3CZakbZ/PxPI0E=; b=ObGkTV4kE5u5vNee4j1SEU4JKBW/1tIC6qemMmUhfS95jw06Fb5LqXKHwEVGvSeZRk vbluetHM7zR/Z3RD5EIqz4MNN6codeQLfdlqv2VoNffOTL6msUCF6yn+C6/AEE/GVjo2 16FNxwozy4fXSWcZ55ts6JhSkYsUom+qU8MYgJnYTtKq9mxhorVjLDi288PwmfeoRkE9 bXreneIIzIPezBrAe0nf+YkXLQ/Uam1cGnKRDdP1879cVlrq3liCcD8T94qmLTVDkPYW 4pyjjLbfzad5xFDd8zKWoafzy+/nTZgx3nTB/HIH8DoogXHnigLO0GfyerHVU0RC0t5L FQoA==
MIME-Version: 1.0
X-Received: by with SMTP id 76mr25854030pfo.86.1448397654643; Tue, 24 Nov 2015 12:40:54 -0800 (PST)
Received: by with HTTP; Tue, 24 Nov 2015 12:40:54 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Date: Tue, 24 Nov 2015 12:40:54 -0800
Message-ID: <>
From: Peter Bowen <>
Content-Type: text/plain; charset="UTF-8"
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, 24 Nov 2015 20:40:56 -0000

On Tue, Nov 24, 2015 at 10:04 AM, Jeffrey Walton <> wrote:
>> No, the least disruptive option is to leverage existing standards without modification to implement both the signal and the verification.  Frex., adding a DANE record check to TLS server authN verification.
> OK, thanks Tim.
> So let me wrap this up... What is the IETF and/or PKIX going to
> provide us with to discern between authentic servers and
> proxied/intercepted connections now that Public Key Pinning with
> Overrides is here?
> What do I tell my developers?

I'm a little lost.  What are you trying to achieve?  Assuming your
developers are writing a client app, I see several scenarios:

1) You have a client application relying on a shared trust store.  The
proxy is configured to issue certificates signed by something in the
trust store.  In this case validation works as normal.

2) Validation passes, but there are additional post-validation
constraints validation info (e.g PKP).  The constraints fail. In this
case, you check the trust store to see if the CA signing the cert is a
"system" CA or a "user" CA.  If user, ignore PKP.

3) You have a client app that has its own trust store.  The proxy's
certificate is not signed by a CA in your list.  Validation fails.

4) The proxy is signing with an unknown certificate.  Validation fails.

In none of the scenarios does it help to have a flag for 'this is a
proxy'.   The only place it would help is if you wanted to only allow
overrides where the User CA explicitly indicated it was trying to
override.  However I can't imagine when the CA would not set this.