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

Yoav Nir <ynir.ietf@gmail.com> Thu, 12 November 2015 11:39 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3841A1A7C for <pkix@ietfa.amsl.com>; Thu, 12 Nov 2015 03:39:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id koGqkdAeosZL for <pkix@ietfa.amsl.com>; Thu, 12 Nov 2015 03:39:52 -0800 (PST)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 045821A1A7B for <pkix@ietf.org>; Thu, 12 Nov 2015 03:39:52 -0800 (PST)
Received: by wmec201 with SMTP id c201so28439556wme.0 for <pkix@ietf.org>; Thu, 12 Nov 2015 03:39:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dVUJIapVWFaoyWB4e87F0rDIo37lpdw65kyJwEsYRX8=; b=biqNdqB6WO6l3VCQibDPi52bRtvLDD4C7oeRByDlJFGw3HBT4LeyI7UOjBiXA5l2GC vH4aPuyylqRfh72RvZGTMH/qegOFimstFXotFpJdcM0Sz+W0bT9n74lSYmh6KfZyErqg bb8NrRGO/rNWzvDhPGgtZ81CmUZC6L080jUXVfh7Hp6YRh12MnlY62FhElXIplBIB0ZB R8Fa5gSwqSKxdtf7oqLGsLsWkZNNpmsSugL87mqrSuykMOE3/mZaW+iqWfuXVUBa2o5o l2636V0fE6xBI3hMXRz/Gvq1MiFTCNLt0JVSCuqrGXEJS9EeaDvtWdD3CvGN5adAolL0 XUtQ==
X-Received: by 10.28.6.12 with SMTP id 12mr41754681wmg.99.1447328390627; Thu, 12 Nov 2015 03:39:50 -0800 (PST)
Received: from [172.24.249.179] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id t126sm14557453wmd.23.2015.11.12.03.39.49 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Nov 2015 03:39:50 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CAH8yC8nw-7nZfxv=UhzGxfGfYfDKDJFQUp0pNQ8auEFzdby5BA@mail.gmail.com>
Date: Thu, 12 Nov 2015 13:39:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <575EB331-EBC2-429D-A030-8620FB64106C@gmail.com>
References: <CAH8yC8=7YP-p=fEL4nFdemiiqU7wm=y7Um=PGgR0=ZbH=mNemQ@mail.gmail.com> <B5236D74-4492-4B9E-9A0D-EBC48EA12A0D@gmail.com> <CAH8yC8nw-7nZfxv=UhzGxfGfYfDKDJFQUp0pNQ8auEFzdby5BA@mail.gmail.com>
To: noloader@gmail.com
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/SAyOGHNcvZZRFva8rNFhE-lqjBs>
Cc: PKIX <pkix@ietf.org>
Subject: Re: [pkix] How do we differentiate authentic servers from proxies performing TLS interception?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2015 11:39:54 -0000

> On 12 Nov 2015, at 12:47 PM, Jeffrey Walton <noloader@gmail.com> wrote:
> 
>>> I've been through RFC 5280 and 6125 looking for a treatment of the
>>> subject matter, but I could not find it. I would expect it to show up
>>> somewhere, like KU or EKU, but the bits appear to be missing.
>>> 
>>> How do we differentiate authentic servers from proxies performing TLS
>>> interception?
>> 
>> There is no way to mark a certificate as an “interception" (or “proxy” or “fake”) certificate. Attempts to mark either the certificate or the TLS handshake were not successful in the IETF, because we do not facilitate interception in protocols, lawful or otherwise.
> 
> Thanks Yoav, that's interesting. I thought that too until RFC 7469
> came along and got approved with the overrides.

But as you note, the overrides are obscured.

> Now that the IETF has provided a standard with the overrides, maybe
> its time to revisit the previous decision. There are a few reasons:
> 
> * The dominate RFC 7469 players claim "interception is a valid use
> case" (citing the W3C's Priority of Constituencies)

“consider users over authors over implementors over specifiers over theoretical purity.”
But what are the interests of the users? Many would claim that not having their traffic intercepted is a higher priority. Unfortunately the users don’t participate in either W3C or IETF, so we have others make claims on their behalf.

> * Its a real-life problem, and not a theoretical one. It can't be
> ignored as if it does not exist.

But what is the problem? That proxying is possible? That proxying is not visible to the user? That proxying is not visible to the server?  Modifying the certificate does not solve that last one anyway.

> * Reusing key bits for both server authentication and
> proxying/interception violates secure design and architecture. Its a
> deep, fundamental flaw.
> 
> I'm particular bothered by the third item. Reusing the KU/EKU bits
> violates at least three of the secure design principals outlined by
> Saltzer and Schroeder's "The Protection of Information in Computer
> Systems". More informed readers (like you, DKG, Guttman, etc), can
> probably find more violations.

Perhaps, but they all boil down to your subject line, that the browser/client cannot tell that the proxy is there without heuristics.

>> The heuristic employed by some browsers and alluded to in section 2.6 of RFC 7469 is to treat certificates that chain to a trust anchor that did not come pre-installed with the operating system or browser as interception certificates, but this heuristic is only valid in the context of key pinning - it would generate too many false positives in general use.
> 
> It almost sounds like they are trying to get half pregnant...
> 
> Regarding false positives, I've found the opposite. We have
> implemented Guttman's security diversification techniques in a few
> libraries and products, and they are almost always spot-on. The trick
> is we need a secure distribution channel to keep a handful of security
> parameters up-to-date. All the App stores claim to have one, so we are
> in a good position (and side-loading is trivially secure because it
> provides a location limited channel).

What I meant by false positives is that some organizations (corporate, educational or government networks as well as others) deploy their own CA, add this CA to the trust anchor store of devices, and use certificates from this CA for internal servers. A heuristic that marks all certificates not from the public web PKI as “proxied” will inevitably misidentify such internal servers as proxied. 

> Why was the word "override" removed from RFC's 7469 Draft 21? It
> appears the effect was to make the interception more obscure. I would
> have expected it to go the other way - make it more pronounced to
> ensure the risk is noted by architects evaluating the standard.
> Putting the word "override" in the title seemed like a more
> appropriate action because it has such a negative effect on the
> security of the system.
> 
> Jeff