Re: [TLS] TLS Proxy Server Extension

Matt McCutchen <> Fri, 29 July 2011 04:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FC6921F8799 for <>; Thu, 28 Jul 2011 21:51:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WU9NO4nJIlvH for <>; Thu, 28 Jul 2011 21:51:34 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 2FCC721F8797 for <>; Thu, 28 Jul 2011 21:51:33 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id A00C2578071; Thu, 28 Jul 2011 21:51:33 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s=; b=u/kwk2VztOVId/8WD9O2RRY+2QBo2M54xtY5Xf40JrP 4mbE4nSwZmHnakFlKjSl1ckckPVcPMr7Aj6sUEdFx/nHHF3C6mFfSZvqRzMG6Et9 BrvHOahWtRWbqrtphV3NYeik4bSiMHNMHEeTB4fhGHaTUJq4kYmzSCiRYRUx7Q3k =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s=; bh=nRm71EJ9G4LBY/095zRfwIRSEXw=; b=jDMaQSTz43 hO7euqqTC8voGobrpnshXRTZAeakgqqYbtVCoQTajVRAPoP1bIch9mOTNqpd24Us b8Bam5WZP3lIHBpF2qzRjf87RCcVPVfr2rCEK/VQ0ysU6tq4kyLHRNcC7wT2Xyt/ y4RfEKhITApIRo177yUth1wODORvMusl8=
Received: from [] ( []) (using SSLv3 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id BE2E157806C; Thu, 28 Jul 2011 21:51:32 -0700 (PDT)
From: Matt McCutchen <>
In-Reply-To: <>
References: <>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 29 Jul 2011 00:51:30 -0400
Message-ID: <1311915090.2035.36.camel@localhost>
Mime-Version: 1.0
X-Mailer: Evolution 2.32.3
Content-Transfer-Encoding: 7bit
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: Fri, 29 Jul 2011 04:51:36 -0000

On Wed, 2011-07-27 at 20:17 +0200, Martin Rex wrote:
> Only for Web-Browser scenario can I personally see a very limited
> value that does not amount to 100% wiretapping.
> Are you aware of rfc2804 "IETF Policy on Wiretapping"?
> Standardizing MITM attacks on TLS-protected communication
> ("lawful intercept?") seems like an extremely bad idea to me.

This is not wiretapping as defined in that policy.  Not that I would
ever be willing to use a TLS proxy for personal activities, but I see no
reason to block the standardization.  In fact, I am intrigued by the

> Checking whether some data conforms to a certain company policy will
> almost always be illegal in European countries, where we have
> sensible data protection laws.

If you are thinking of corporate networks (the typical current use of
the proxies in question), I don't see how restricting what checks a
company can do on its own property is sensible, but that is off topic...

> > - One approach would be to do a real escrowed TLS where the client
> > negotiates directly with the server but releases the confidentiality key
> > and optionally also the integrity key to the proxy.  This subsumes all
> > of the above concerns but doesn't allow the proxy to manipulate the
> > handshake in any finer way than blocking the connection if it doesn't
> > like the outcome.
> For the purpose of "centralized malware screening", for the incoming
> Web traffic of Web Browsers that are well known to interpret such
> data in arbitrarily stupid ways (such as active content, img src, (i)frame,
> javascript, css), sharing the encryption traffic keys with the Proxy
> would be perfectly sufficient


> and that also enables the clients
> to clearly limit who is able to read the traffic.

Huh?  The proxy's ability to pass decrypted data to someone else is no
different than if it were bridging two TLS connections.

> No super-CA-equivalent
> keys would need to be on the malware-scanning Proxy.

You speak as if that were in a whole different class of badness, but the
actual effect is simply to give up integrity as well as confidentiality
to the proxy.