Re: [TLS] TLS Proxy Server Extension

Adam Langley <agl@google.com> Tue, 26 July 2011 21:26 UTC

Return-Path: <agl@google.com>
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 7266D21F8A62 for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 14:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.877
X-Spam-Level:
X-Spam-Status: No, score=-105.877 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 bKD2TbYVIP5q for <tls@ietfa.amsl.com>; Tue, 26 Jul 2011 14:26:03 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [74.125.121.67]) by ietfa.amsl.com (Postfix) with ESMTP id B29E121F8A4E for <tls@ietf.org>; Tue, 26 Jul 2011 14:26:02 -0700 (PDT)
Received: from wpaz33.hot.corp.google.com (wpaz33.hot.corp.google.com [172.24.198.97]) by smtp-out.google.com with ESMTP id p6QLQ0Gq020034 for <tls@ietf.org>; Tue, 26 Jul 2011 14:26:01 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1311715561; bh=ygHTqGTXajzVH4yohmrJCq/zlLc=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type:Content-Transfer-Encoding; b=RiSWbbYlJS0y4w3OHzrVDAkbfRqP1mo3GqoIWDbnS+yrmyOaZIb+pRBwuazVzSWZY lkXljVJNxuAJTsG4028Kw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type: content-transfer-encoding:x-system-of-record; b=oFBHYVyCyqZdtI3YsTF/TcoZNHPvE+PIphRE5IXfPehlWkjFjkNvXVus9cQSlSEdM Clqh8rn268f9/GULCxxpQ==
Received: from gxk2 (gxk2.prod.google.com [10.202.11.2]) by wpaz33.hot.corp.google.com with ESMTP id p6QLO2cQ026827 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for <tls@ietf.org>; Tue, 26 Jul 2011 14:25:59 -0700
Received: by gxk2 with SMTP id 2so881617gxk.22 for <tls@ietf.org>; Tue, 26 Jul 2011 14:25:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=IriizJGxntQnMangpykZVHXZyJxu19rzOP+/OVkC35Y=; b=jZB1iR8MAUy5wxDvENlpckqNW9BWCr+wNnVORbY45MmVYctEG1vmJ6U/4RwikYsTtl kkEMVsHxH3serM86jEAg==
MIME-Version: 1.0
Received: by 10.151.7.8 with SMTP id k8mr4162419ybi.34.1311715559626; Tue, 26 Jul 2011 14:25:59 -0700 (PDT)
Received: by 10.151.47.19 with HTTP; Tue, 26 Jul 2011 14:25:59 -0700 (PDT)
In-Reply-To: <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com>
References: <E210EEE3-1855-4513-87E3-C315E611AB5E@cisco.com> <8FEC3C4B-32F9-46AF-A049-BE6FD3C2FE1A@checkpoint.com>
Date: Tue, 26 Jul 2011 17:25:59 -0400
Message-ID: <CAL9PXLwXqssrwDM4HytB_eNBT-LFK5fRAOVQ-ehd1XwhH6-8Ag@mail.gmail.com>
From: Adam Langley <agl@google.com>
To: Yoav Nir <ynir@checkpoint.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: Philip Gladstone <pgladstone@cisco.com>, David McGrew <mcgrew@cisco.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS Proxy Server Extension
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: Tue, 26 Jul 2011 21:26:03 -0000

On Tue, Jul 26, 2011 at 5:17 PM, Yoav Nir <ynir@checkpoint.com>; wrote:
> I don't know if you're following the LockFoo discussion on WebSec, but all of those locks would cause a hard-fail for clients connecting to sites that have specified them. As security people we might think "good!", but that would actually be a bar to implementations of LockFoo more than it would be a bar to deployment of TLS proxies. Giving the client access to the original certificates would allow the browser to overcome this limitation.

At least in Chrome, user installed root CAs can override certificate
pins. Thus MITM proxies aren't broken and nor will they be by any of
the various pinning proposals in websec.


Cheers

AGL