IETF Logo Mail Archive

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

Yoav Nir <ynir.ietf@gmail.com> Thu, 12 November 2015 10:12 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 197EB1B2E1E for <pkix@ietfa.amsl.com>; Thu, 12 Nov 2015 02:12:51 -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 x_yBTf2rwYs6 for <pkix@ietfa.amsl.com>; Thu, 12 Nov 2015 02:12:50 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 94C341B2E1D for <pkix@ietf.org>; Thu, 12 Nov 2015 02:12:49 -0800 (PST)
Received: by wmvv187 with SMTP id v187so24890261wmv.1 for <pkix@ietf.org>; Thu, 12 Nov 2015 02:12:48 -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=jzJPnmdUWa4WOADreGd3XvHhtCu68NUJDvaTJXQXSX0=; b=lZ1WJtf52ZTt+2pwJDTMgfjJugkj12QLHI6/OdHGXyq8bBv6Pvs8Z3EyQx7TIFryhj aJFPerbif47bFglgAOZgWbo7ETy3NmNJZeuSKzrWjEAZgv9G5YyLIGocapY2eXRS5bnV AyEl3m4uhUVBvgDxD/KIbtnpDx1Z+F3rnKgm/i49gYkbINtvGyCXcA1mj/iNqgFTrl6e XpaUFBinQh6n5YV47zdwKQNoXGXYRo1M+9WSGlJRFUCPXwslf1WAyGQxp6TpA2sVHA10 GwQr/0ksGZ+4c+PDRTMhBVvOM5jVd2M2uQymIVc/IilsFRAtgpYHImxDGMwH+mjnNeHl VJxw==
X-Received: by 10.28.30.208 with SMTP id e199mr27174691wme.22.1447323168204; Thu, 12 Nov 2015 02:12:48 -0800 (PST)
Received: from [172.24.249.179] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id b12sm29892480wma.6.2015.11.12.02.12.47 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 12 Nov 2015 02:12:47 -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: <CAH8yC8=7YP-p=fEL4nFdemiiqU7wm=y7Um=PGgR0=ZbH=mNemQ@mail.gmail.com>
Date: Thu, 12 Nov 2015 12:12:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <B5236D74-4492-4B9E-9A0D-EBC48EA12A0D@gmail.com>
References: <CAH8yC8=7YP-p=fEL4nFdemiiqU7wm=y7Um=PGgR0=ZbH=mNemQ@mail.gmail.com>
To: noloader@gmail.com
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/pkix/SKOUThko5T3-oJoPQmArC9HEluM>
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 10:12:51 -0000

> On 12 Nov 2015, at 10:43 AM, Jeffrey Walton <noloader@gmail.com> wrote:
> 
> Hi Everyone,
> 
> 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?
> 
> Thanks in advance.

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.

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.

Yoav

v2.19.0 | Report a Bug | By Email