Re: [TLS] TLS Proxy Server Extension

Joshua Davies <> Tue, 02 August 2011 22:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96D2811E80CE for <>; Tue, 2 Aug 2011 15:27:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9EmitYZpGuTS for <>; Tue, 2 Aug 2011 15:27:02 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BF72111E80A1 for <>; Tue, 2 Aug 2011 15:27:02 -0700 (PDT)
Received: by pzk6 with SMTP id 6so344422pzk.26 for <>; Tue, 02 Aug 2011 15:27:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t447ynUFbsf2xzU2P6HdcbyQXbD4dPXRIiDuHJHe7S4=; b=ILpESJ++TkrzOzih1+RYU5YqNbITn/s5B07bdDY8to4DkvmNYvmXyAbWEY+JXWyX/3 Ctfq3l75MK+/F/6GDB6pTi4E0S8ZqB+T6sjAY0d5nFiPSsun6n60rnIAQ2GX0MOjpT7G eOVMt8G7pcYZoxNXel3Vi/xeB9/aGDxsJ9sDQ=
MIME-Version: 1.0
Received: by with SMTP id e10mr36070pbh.71.1312324031468; Tue, 02 Aug 2011 15:27:11 -0700 (PDT)
Received: by with HTTP; Tue, 2 Aug 2011 15:27:11 -0700 (PDT)
In-Reply-To: <>
References: <1312302676.2174.31.camel@localhost> <>
Date: Tue, 2 Aug 2011 17:27:11 -0500
Message-ID: <>
From: Joshua Davies <>
Content-Type: multipart/alternative; boundary=bcaec520eb1fb9d3d604a98d3fbd
Subject: Re: [TLS] TLS Proxy Server Extension
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 02 Aug 2011 22:27:03 -0000

> I haven't heard any use cases for the TLS proxy in this discussion
> that are not factually equivalent to wiretapping.

Hm - it may be factually equivalent to wiretapping, but I can think of a
perfectly legitimate use case for a TLS proxy which MITM's a client, with
that client's express consent and knowledge of course - wire-level debugging
of an encrypted session.  I've set something like this up a couple of times
to debug a server that doesn't accept plaintext connections but is still not
behaving correctly; I create a proxy that presents a self-signed certificate
to the client, ignore the security pop-up warning, and then proxy again to
the server (logging everything in between).  In this case, I'm
"wiretapping", but I'm wiretapping myself.

On Tue, Aug 2, 2011 at 12:30 PM, Martin Rex <> wrote:

> Matt McCutchen wrote:
> >
> > A person using a corporate laptop has no expectation of privacy from the
> > company.  The proxy extension just offers a technically more capable
> > solution for that scenario.
> Not everyone is living in totalitarian countries where this might apply.
> As I previously said, our constitution provides fundamental gurantees
> of privacy, and protects against both, government agencies spying
> on citizens as well as employers spying on employees.
> >
> > No one is proposing, per se, that TLS interception be used in any more
> > places than it is now.  Of course, interception may now be used in
> > places where it was always desired but could not be used before due to
> > protocol issues.  However, it's hard to believe that the proxy extension
> > would change the market and/or legal forces that currently restrain ISPs
> > from routinely intercepting customer traffic, if that is what Martin is
> > worried about.
> No, it is primarily about the employer spying on employee case, which
> has been clearly ruled unconstitutional in Germany.  But the stiff penal
> code that might provide sufficient deterrant for ISPs does not universally
> apply to employers, leaving you with civil action an "cease and desist"
> and a number of completely clueless entry courts.
> >
> > The TLS WG may have a personal distaste for the use case addressed by
> > the extension.  But I would reason that the use case is valid, thus the
> > extension is worthy of standardization to get interoperable
> > implementations, and the TLS WG is the best venue available for
> > technical discussion.  As David explained
> > (, the
> > use case does not constitute wiretapping as defined in RFC 2804.
> I haven't heard any use cases for the TLS proxy in this discussion
> that are not factually equivalent to wiretapping.
> -Martin
> _______________________________________________
> TLS mailing list