Re: Comments on Explicit/Trusted Proxy

Peter Lepeska <> Thu, 02 May 2013 15:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B7B721F8FF3 for <>; Thu, 2 May 2013 08:33:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.099
X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fld7AlA6iFOD for <>; Thu, 2 May 2013 08:33:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A7B6621F8FF2 for <>; Thu, 2 May 2013 08:33:03 -0700 (PDT)
Received: from lists by with local (Exim 4.72) (envelope-from <>) id 1UXvUr-00053q-Ul for; Thu, 02 May 2013 15:32:38 +0000
Resent-Date: Thu, 02 May 2013 15:32:37 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtp (Exim 4.72) (envelope-from <>) id 1UXvUh-00051J-T2 for; Thu, 02 May 2013 15:32:27 +0000
Received: from ([]) by with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.72) (envelope-from <>) id 1UXvUg-00045K-LJ for; Thu, 02 May 2013 15:32:27 +0000
Received: by with SMTP id x30so563701iaa.41 for <>; Thu, 02 May 2013 08:32:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=zyhPW0KiIzZ9LENMjddM6tMs93W0H+m/pJRqa07RTqE=; b=fEzW8bNXx2dXjXe/BYOdxk7cQkk5aVdqvWJJkTLXsCwn2v7UvsGqfX1B/8vDdBZpcU 4rQ1d70xQUoUYxPmym1dzfDnzKGLKFdYHAeQWOMNkg09BM5476cTdWKEzGmmgNZcLaIq 0jd8xoSzZLZ4/p2XnNpNCakV8TfdwP7FskQzMGLc9SynZfRCW7MwS545BOaVD3MAJ2Sw 2coLvg6WEmMNU6l1FcQiPX/77Q3UxNdGwjUK+07cD3pbSxCkb5lZAK8D9TxzgpcVEx7H kQH0qWLqYeT38+QjgzztyJxSwrMrnkpFpMkUXVSVvhra7ut2iftZp4l5o5BEvY1V7UOS H4YQ==
X-Received: by with SMTP id mb8mr15174634igc.91.1367508720795; Thu, 02 May 2013 08:32:00 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id o10sm9086477igh.2.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 May 2013 08:32:00 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_0FFA8C02-E050-4BEE-B8AE-40B1C547E09F"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Peter Lepeska <>
In-Reply-To: <>
Date: Thu, 2 May 2013 11:32:00 -0400
Cc: HTTP Working Group <>
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Albert Lunde <>
X-Mailer: Apple Mail (2.1503)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-0.8
X-W3C-Hub-Spam-Report: AWL=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001
X-W3C-Scan-Sig: 1UXvUg-00045K-LJ 2e8e87d39c7a83bea4e6aa0b996f5d99
Subject: Re: Comments on Explicit/Trusted Proxy
Archived-At: <>
X-Mailing-List: <> archive/latest/17784
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>


MITM proxy must get its CA installed in the certificate db on the end user device.
MITM forges certs -- effectively impersonating content servers.
MITM performs trust validation for end user -- transitive trust opens up the possibility that users will not be made aware that they are visiting https sites that they do not trust.
Content servers are unaware of SSL proxy.

We could instead have a new section of the certificate database for trusted proxy certs. These certs would need to be issued by trusted CAs. An SSL proxy would need to install this into the end user device so level of security is the same as today.
No forged certs -- the original content server certificate is sent to the browser as described by the mcgrew draft.
Client can decide if it trusts the content server certificate or not -- no transitive trust.
Content servers can be made aware of SSL proxy so that when adopts SPDY it can allow optimization by SSL proxies and it will not become 4x slower over satellite.


On May 2, 2013, at 11:17 AM, Albert Lunde <> wrote:

> On 5/2/2013 9:57 AM, Stephen Farrell wrote:
>> On 05/02/2013 03:53 PM, Peter Lepeska wrote:
>>> It's no different than today. If you have a root CA installed on the end users machine, you can MITM the bank. Under this scheme, there will be some proxies that will elect to not MITM traffic from content providers that explicitly opt-out.
>> Right. All web servers have to trust all the proxies in the universe.
>> Seems like a show-stopper to me.
> >
>>> In general, adding support for an SSL proxy should not decrease the
>>> level of security from MITM attacks that we have today. It just allows
>>> well-behaving ones to A) not have to forge certificates, B) remove the
>>> problem of transitive trust, and C) make content servers aware and give
>> them the ability to opt-out.
>> Standardising that would IMO seriously decrease the level of
>> security we have.
> I'd say it's better to trust a known proxy than to be in the typical captive portal situation where the portal in effect forges certificates to make you think everything is wonderful.
> This is being done widely enough to suggest there is a use case.
> What one would like is something that restricts what the proxy can do and identifies the proxy in a reliable way.
> The other approach that sometimes works is some kind of VPN, but that may be out of scope...
> -- 
>    Albert Lunde
>          (address for personal mail)