IETF Logo Mail Archive

[TLS] Certificate pins vs. MITM proxies

Matt McCutchen <matt@mattmccutchen.net> Wed, 27 July 2011 03:07 UTC

Return-Path: <matt@mattmccutchen.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6183011E80DE for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 20:07:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lipynjknt4Yw for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 20:07:20 -0700 (PDT)
Received: from homiemail-a2.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id 9A50D11E80CB for <tls@ietf.org>; Tue, 26 Jul 2011 20:07:20 -0700 (PDT)
Received: from homiemail-a2.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTP id 57356280071; Tue, 26 Jul 2011 20:07:20 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=qi5Tg5YRVAw+S9+ehQzt/IKauakU3fBOYgwtfX3k+r5 15OXiY/NXi4G9ldRy6yQ2VCmr18YHsHhSh36BOaUyhC5Y2qt7vUf0v5rbg3jfm8I G5ExGOHfb4YLmSCX536Z1vbykiiO4QoTmvCGI+8Ai+fu2A4Pdz1BEGgAJFR9XBV8 =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=qv0NF0zrlkNdVtgEmcaRJ7r6nIM=; b=Q2MbPQta55 /UeAinWusxsj7eKFHEhEYZWsrJRYNHdSmEH1y4KEqz5tvybmJq759WP4qXNeCEGR 6FlQieaPOwnIrWfLWGoCk6zizkCHL6C1YhGGA77P4/BzEqh/Abpx0/xjfDHvKR2f 6m+IOdkspl/XyaZD9efILUz+xUlFZAx4g=
Received: from [192.168.1.39] (pool-74-96-44-194.washdc.east.verizon.net [74.96.44.194]) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a2.g.dreamhost.com (Postfix) with ESMTPSA id CD88E280069; Tue, 26 Jul 2011 20:07:19 -0700 (PDT)
From: Matt McCutchen <matt@mattmccutchen.net>
To: Adam Langley <agl@google.com>
In-Reply-To: <CAL9PXLyDdeA4FcWGZF3fUxPoJY=1q1QMvJ=y7Q_Oc8Txj4ofvg@mail.gmail.com>
References: <E210EEE3-1855-4513-87E3-C315E611AB5E@cisco.com> <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com> <CAL9PXLwXqssrwDM4HytB_eNBT-LFK5fRAOVQ-ehd1XwhH6-8Ag@mail.gmail.com> <FCA03B83-11E6-4AA6-9ACD-42CDAD14FC46@checkpoint.com> <CAL9PXLyDdeA4FcWGZF3fUxPoJY=1q1QMvJ=y7Q_Oc8Txj4ofvg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 26 Jul 2011 23:07:17 -0400
Message-ID: <1311736037.7071.81.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: [TLS] Certificate pins vs. MITM proxies
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jul 2011 03:07:21 -0000

On Tue, 2011-07-26 at 17:51 -0400, Adam Langley wrote:
> On Tue, Jul 26, 2011 at 5:41 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> > Really?  I thought Chrome used the operating system TA store. How can it tell the difference between a trust anchor that was installed by Microsoft and one that was installed by the user?
> 
> Not in any very clean way I'm afraid:
> 
> http://src.chromium.org/viewvc/chrome/trunk/src/net/base/x509_certificate_known_roots_win.h?revision=80765&view=markup

Yeah, that approach ensures that the pins you ship by default do not
break MITM proxies (since public CAs are bound not to support MITM
proxies, or at least we have no sympathy for them if they do), but it
also (arguably) negates their promised benefits in environments with
custom CAs, a superset of those with MITM proxies.  That choice of
trade-off is understandable but pretty disappointing.  Power users will
want to designate MITM-proxy CAs explicitly.  I guess I could file an
enhancement request...

-- 
Matt

v2.23.0 | Report a Bug | By Email