Re: [TLS] TLS Proxy Server Extension

Yoav Nir <> Wed, 03 August 2011 06:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8286C11E80C9 for <>; Tue, 2 Aug 2011 23:24:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.502
X-Spam-Status: No, score=-10.502 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S1Pv4It6QuT9 for <>; Tue, 2 Aug 2011 23:24:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 88CCE11E8070 for <>; Tue, 2 Aug 2011 23:24:08 -0700 (PDT)
X-CheckPoint: {4E38F706-0-1B221DC2-FFFF}
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id p736O0NI014895; Wed, 3 Aug 2011 09:24:00 +0300
Received: from ([]) by ([]) with mapi; Wed, 3 Aug 2011 09:23:59 +0300
From: Yoav Nir <>
To: Joshua Davies <>
Date: Wed, 3 Aug 2011 09:23:57 +0300
Thread-Topic: [TLS] TLS Proxy Server Extension
Thread-Index: AcxRpe2jDEp0wl1qQimD/3RWBjkQMw==
Message-ID: <>
References: <1312302676.2174.31.camel@localhost> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
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: Wed, 03 Aug 2011 06:24:09 -0000

On Aug 3, 2011, at 1:27 AM, Joshua Davies wrote:

> > 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.

A TLS proxy is just a piece of technology, much like a microphone and a tape recorder. Legality depends on the use, not on technology.

The use-case that interests me is deep firewall inspection. HTTP connections are routinely inspected by firewalls for downloaded malware, cross-site scripting, and various other attacks. Without a TLS proxy, HTTPS connections can either slip under the radar or get blocked entirely. That would have been fine a few years ago, when SSL was only used for shopping and banking sites (you could defer your shopping and banking for when you were home). These days the use of HTTPS is becoming more prevalent, so blocking HTTPS is no longer a good option. A TLS proxy allows an organization to use HTTPS while still applying company policy and defenses.

I'm not saying this is all good. There are some real problems with using a proxy:
- The same technology can be used for wiretapping, and the user cannot tell the difference between a good proxy and an evil one.
- The client does not get to validate the server on its own (the subject draft is an attempt to solve this)
- Client certificates and PSK ciphersuites are broken.

I think with a little modification the draft can solve the first two problems.