Re: [TLS] TLS Proxy Server Extension
Marsh Ray <marsh@extendedsubset.com> Fri, 29 July 2011 15:22 UTC
Return-Path: <marsh@extendedsubset.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 97E6F11E807A for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 08:22:33 -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 Ccu+Qe-fnxis for <tls@ietfa.amsl.com>; Fri, 29 Jul 2011 08:22:33 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-04-ewr.mailhop.org [204.13.248.74]) by ietfa.amsl.com (Postfix) with ESMTP id D3A8511E8072 for <tls@ietf.org>; Fri, 29 Jul 2011 08:22:32 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from <marsh@extendedsubset.com>) id 1QmotT-000Flc-67; Fri, 29 Jul 2011 15:22:31 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id F34816070; Fri, 29 Jul 2011 15:22:28 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+wK8bt1ljTB+3H0tr7a4PKWgnQkooaCq8=
Message-ID: <4E32D033.7020601@extendedsubset.com>
Date: Fri, 29 Jul 2011 10:22:27 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: David McGrew <mcgrew@cisco.com>
References: <E210EEE3-1855-4513-87E3-C315E611AB5E@cisco.com>
In-Reply-To: <E210EEE3-1855-4513-87E3-C315E611AB5E@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Philip Gladstone <pgladstone@cisco.com>, 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: Fri, 29 Jul 2011 15:22:33 -0000
On 07/26/2011 10:01 AM, David McGrew wrote: > > http://tools.ietf.org/html/draft-mcgrew-tls-proxy-server-00 > The ProxyInfo extension only provides information about proxies to > the client; it does not provide any information to the server about > either the client or other proxies on the path. This is acceptable > when there are no client certificates in use, which is (regrettably) > common in practice. It would be possible to generalize the ideas in > this note to also provide information to the server about the client > and other proxies on the path. Nonetheless, that goal is out of > scope for this note. It's good that the draft is explicit about what is not being provided to to the server. But, please, won't somebody think of the poor servers? As someone who works on the security of an authentication service delivered through TLS, I feel the need to oppose the standardization of functionality with the potential to undermine the security of our service. It was once said that the driving purpose of the design of SSL was to make users *feel* secure enough to be comfortable entering their credit card number on the web and I've seen little or no evidence to refute that claim. In this model, all the paranoia is expected to reside with the user. One of the unfortunate artifacts of the resulting design is that the server has no way to prove the nonexistence of a MitM, he can only hope that the client will do a good job of this. We all know how well this works when put to the test by an active attacker. Client certificates are currently the only tool available for server admins to participate in preventing this important class of attacks. The authors of this draft seem to feel the relative infrequency of client certificate usage is "regrettable", yet they propose standardizing a scheme which will break them entirely! Consider, for example, the scenario which was described to me by someone in the retail sector. She was responsible for auditing security policies for a retail credit card website. They interpreted the relevant laws and industry regulations to mean that they were obligated to intercept employee web browser usage to monitor for and block various forms of undesired content. However, employees may also have personal credit cards with the same issuer, the statements of which they might sometimes access from their desk at work. But the organization considered itself forbidden from snooping on that traffic. I don't know if or how they got it sorted out, my point being only that there are several parties involved here and it's not clear at all the circumstances under which one party may have an absolute right to impersonate, decrypt, or MitM the traffic even between its own clients and servers. If you operate a financial or government site, you may be under various legal obligations to ensure that certain information is transmitted only to the intended recipient. Today this is commonly done (weakly) with non-client certificate HTTPS websites. If or when MitM interception becomes standardized and widespread it will obligate the use of client certificates to satisfy this requirement while at the same time breaking their functionality entirely. Any standardization of MitM or interception functionality must take into account the requirements of the server operators as an equal party and stakeholder in the security of the connection. - Marsh
- [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Yngve N. Pettersen
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Adam Langley
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Adam Langley
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Matt McCutchen
- [TLS] Certificate pins vs. MITM proxies Matt McCutchen
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Matt McCutchen
- Re: [TLS] TLS Proxy Server Extension Matt McCutchen
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Marsh Ray
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Anders Rundgren
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Ken Peirce
- Re: [TLS] TLS Proxy Server Extension Peter Gutmann
- Re: [TLS] TLS Proxy Server Extension Matt McCutchen
- Re: [TLS] TLS Proxy Server Extension Martin Rex
- Re: [TLS] TLS Proxy Server Extension Joshua Davies
- Re: [TLS] TLS Proxy Server Extension Yoav Nir
- Re: [TLS] TLS Proxy Server Extension Ken Peirce
- Re: [TLS] TLS Proxy Server Extension Philip Gladstone
- Re: [TLS] TLS Proxy Server Extension Kemp, David P.
- Re: [TLS] TLS Proxy Server Extension David McGrew
- Re: [TLS] TLS Proxy Server Extension Ralph Holz