Re: Yet another trusted proxy suggestion

I don't see any point in using a CONNECT style of approach if you trust 
the proxy.  What sort of connection is that? If TLS, then why not just 
use a GET https:// approach.

As for using a mandatory proxy on the server end, I don't really see a 
requirement for that.  People use reverse proxies for sure, but they 
just appear from the outside to be a server.  I think if we allowed 
assertion of mandatory proxy use outside a trusted environment (e.g. the 
user's LAN) then we would have major problems getting it accepted.

As for whether this is a MITM.  I believe it is not, but not for the 
reasons given (in a prev response to this).

It's not MITM, because in this case the proxy is not pretending to be 
the server.  It's not spoofing any certs, it's just accepting a 
connection and making one on behalf.  The only real difference is the 
proxy took on the job of TLS to the server.

Adrien


------ Original Message ------
From: "Yoav Nir" <synp71@live.com>
To: "HTTP Group" <ietf-http-wg@w3.org>
Sent: 27/11/2013 1:16:25 a.m.
Subject: Yet another trusted proxy suggestion
>So after several threads, both here and and in private, I get a feeling 
>that the opposition is more to breaking TLS than to having an HTTP(S) 
>proxy.
>
>Given that, I would like to lay out a a proposal for the flow of proxy 
>detection and usage, without getting too low-level.
>
>As an example, we'll assume there's a user, alice@example.com, who uses 
>her computer to download something from https://download.adobe.com. 
>There are two proxies involved in this:
>  - one is a next-generation firewall: sslproxy.example.com
>  - one is a CDN server called a1953.d.cdn.net
>
>Note that under this scenario, a1953.d.cdn.net resolves to the same IP 
>address (192.0.2.5) as download.adobe.com. Maybe this can be improved, 
>but that's how CDNs work for now.
>
>Another thing to note is that there are actually two entities in the 
>first part. There's the proxy, which deals in HTTP(S), and then there's 
>the firewall which prevents E2E communications. They may be co-located, 
>but then don't have to be.
>
>Step #1
>=======
>The browser resolves download.adobe.com, and opens a connection to 
>192.0.2.5 port 443. The firewall blocks this. I'm not sure it it's 
>preferable to block this with some ICMP or with a new TLS alert (so the 
>firewall completes the 3-way TCP handshake, receives the ClientHello 
>and only then sends the error), but I'm tending towards the latter. The 
>new TLS alert is called "mandatory proxy" and contains the URL of that 
>proxy: https://sslproxy.example.com:443
>
>
>Step #2
>=======
>The browser consults local policy about whether such a proxy might be 
>acceptable, and if so, opens a new TLS connection to the proxy and 
>verifies the certificate. This allows adding some clever UX that shows 
>the user what device is on-path, and also allows pre-configuring the 
>trusted proxy based on name.
>
>Step #3
>=======
>The browser sends a CONNECT command to the proxy (maybe that has to be 
>enhanced as well?) to connect to https://download.adobe.com. The proxy 
>tries to connect, and then either of two things happens:
>  1. a1953.d.cdn.net has a certificate for download.adobe.com - that is 
>what we do today.
>  2. a1953.d.cdn.net has a certificate for a1953.d.cdn.net, and issues a 
>"mandatory proxy" alert with its name.
>In the former case, things will work as today. In the latter case, I'm 
>not sure how the proxy (or browser for that matter) can know that 
>a1953.d.cdn.net is a trusted proxy for download.adobe.com. Having the 
>private key is a good indication, but I think we want to get away from 
>that.
>Either way, the connection is established
>
>Step #4
>=======
>If there is some personalized information, the CDN server can open a 
>connection to the real server. This time there is a pre-arrangement, so 
>the names in the certificate may be different.
>
>Step #5
>=======
>Requests and responses go through the series of nodes. We should note 
>that things like flow control are hop-by-hop, so the SETTINGS frame is 
>not forwarded, but is hop-by-hop. We would also like to have some 
>information for both client and server. Here's my suggestion for this:
>ClientInfo structure:
>  - certificate chain sent by the client (if any)
>  - ciphersuite used
>  - this)proxy certificate chain.
>  - subject (or SKID) of received server (or next proxy) certificate
>
>ServerInfo structure:
>  - certificate chain sent by the server (or another proxy)
>  - ciphersuite used
>  - subject (or SKID) or (this) proxy certificate
>
>Each proxy sends a ClientInfo structure to the server. This could be 
>done as a POST to a /.well-known URI or as a new special frame. I 
>prefer the latter, but I don't know how well that will sit with several 
>proxies trying to push the same resource to the server.
>Each proxy also sends a ServerInfo structure to the client. Again, this 
>could be a pushed resource or a special frame. Same concern applies.
>
>Step #6
>=======
>At the end of this, both client and server can construct the chain of 
>certificate chains and the ciphersuite used in each leg of the trip.
>
>TLS is not changed by this, but HTTPS is.
>
>I'd love to hear comments on this. If there's interest I could write it 
>up in a draft, but having been burned twice, I'd like to know there's 
>interest first.
>
>Yoav
>

Received on Tuesday, 26 November 2013 20:09:37 UTC