Re: Comments on Explicit/Trusted Proxy

Fabian Keil <> Thu, 02 May 2013 10:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 473D021F9991 for <>; Thu, 2 May 2013 03:24:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lvQ-p09zTX8n for <>; Thu, 2 May 2013 03:24:32 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EBAED21F9910 for <>; Thu, 2 May 2013 03:24:29 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UXqf7-0001yv-4W for; Thu, 02 May 2013 10:22:53 +0000
Resent-Date: Thu, 02 May 2013 10:22:53 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UXqew-0001xC-Gu for; Thu, 02 May 2013 10:22:42 +0000
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UXqev-00005W-2Z for; Thu, 02 May 2013 10:22:42 +0000
Received: from [] ( by with esmtpsa (SSLv3:AES128-SHA:128) (Exim 4.68) (envelope-from <>) id 1UXqeZ-00064p-CT for; Thu, 02 May 2013 12:22:19 +0200
Date: Thu, 2 May 2013 12:19:13 +0200
From: Fabian Keil <>
Message-ID: <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/7tv1Tqke=_m6lBEoda=wpwR"; protocol="application/pgp-signature"
X-Df-Sender: Nzc1MDY3
Received-SPF: none client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-3.5
X-W3C-Hub-Spam-Report: AWL=-3.450, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001
X-W3C-Scan-Sig: 1UXqev-00005W-2Z 722a0280f3ab6368a9dce8e767f1f4d8
Subject: Re: Comments on Explicit/Trusted Proxy
Archived-At: <>
X-Mailing-List: <> archive/latest/17777
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Yoav Nir <> wrote:

> Here's one (I'm a co-author)
> One reason this was rejected is that MitM proxies are used for corporate firewalls and national firewalls, so the use case seems to be "Alice wants to post to Twitter trashing president Assad. Mallory who works for the secret police would like to catch her, so he installs a proxy."  The feedback said that if whoever wants the inspection (call them Mallory for now) can configure trust on Alice's client, they might as well install spyware instead. Another idea that was floated was to have the client send the keys to the trusted proxy. That way, the client could send just the encryption key (but not the hash key) so the proxy would be able to decrypt, but not forge. I didn't like that, but I did try to write a draft describing it:
> I still think this solution is unwieldy.
> Anyway, the TLS WG can re-consider things. NPN was suggested several times. If there is a use case that is not "Mallory wants to see what Alice is telling Bob", a request from this WG would go a long way, regardless of which mechanism is preferred for enabling a trusted proxy.

Another use case is Alice operating both the client(s) and
the trusted proxy.

In this use case the trusted proxy should be able to MITM some,
but not all, requests and the client(s) should be able to verify
and signal this to Alice.

Mallory should not be able to silently MITM anything and
Alice obviously doesn't want to install spyware instead of
configuring a trust relationship, even though she could.

Having a standard for this would be useful for proxies like Privoxy.