Re: Yet another trusted proxy suggestion

WPAD is frankly not up to the task.

There are too many places where something can go wrong.  DNS lookup 
issues, DHCP issues, deployment of correct PAC script etc etc etc.

Ideally it would be great if a client could be told it was intercepted 
by a proxy, so change behaviour accordingly.

One of the biggest problems with intercepting to a proxy is the client 
thinks it's talking direct to the origin server.  This creates problems 
for auth to proxy, number of connections opened, and other things.

But many customers want to intercept to the proxy because there are no 
bulletproof ways to get ALL clients to specifically use the proxy.

Adrien

------ Original Message ------
From: "Peter Lepeska" <bizzbyster@gmail.com>
To: "Yoav Nir" <synp71@live.com>
Cc: "HTTP Group" <ietf-http-wg@w3.org>
Sent: 3/12/2013 9:11:43 a.m.
Subject: Re: Yet another trusted proxy suggestion
>Step #1 - Where the browser detects the proxy
>=============================================
>[If everything is pre-configured, this step may be skipped, but that 
>makes moving to another network where that particular proxy is not 
>present more difficult.]
>The browser resolves download.adobe.com, and opens a connection to 
>download.adobe.com 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
>
>Yoav,
>
>Why not consider extending WPAD for proxy detection?
>
>Thanks,
>
>Peter
>
>
>On Thu, Nov 28, 2013 at 2:51 AM, Yoav Nir <synp71@live.com> wrote:
>>Hi,
>>
>>After receiving some feedback, I'm revising this proposal by removing 
>>the CDN and CONNECT.
>>
>>
>>Assume there's a user, alice@example.com, who uses her computer at 
>>work to download something from https://download.adobe.com. Her 
>>company hasa next-generation firewall called sslproxy.example.com. 
>>Alice is aware of this proxy, but has been told that the proxy is only 
>>used for detecting malware and blocking time wasters like Farmville 
>>and OKBridge. Specifically the IT people and her bosses do not have 
>>access to the plaintext. This is not enforced in any technical way - 
>>but Alice trusts the IT department to keep their word.
>>
>>Another thing to note is that there are actually two components to the 
>>mandatory proxy. 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 - Where the browser detects the proxy
>>=============================================
>>[If everything is pre-configured, this step may be skipped, but that 
>>makes moving to another network where that particular proxy is not 
>>present more difficult.]
>>The browser resolves download.adobe.com, and opens a connection to 
>>download.adobe.com 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 - Connecting to the proxy
>>=================================
>>
>>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.
>>I realize that this is where security will be made or broken. It's 
>>tempting to solve this with some message like this:
>>+-----------------------------------------------------------------------+
>>| Warning: an HTTPS proxy was detected on the path to                  
>>  |
>>| download.adobe.com.  The proxy is identified as 
>>_sslproxy.example.com_ |
>>| |
>>| This proxy will be able to read all traffic, including any 
>>passwords, |
>>| credit card numbers, and personal information. Do not proceed unless 
>>  |
>>| you trust this proxy.                                                
>>  |
>>| |
>>|  +-----------------------+  +--------------------------+ +--------+  
>>|
>>|  | Trust this proxy once |  | Trust this proxy forever |  | Cancel | 
>>  |
>>|  +-----------------------+  +--------------------------+ +--------+  
>>|
>>+-----------------------------------------------------------------------+
>>
>>In its favor, it's more clear-cut than certificate warnings that are 
>>always vague because most certificate errors are misconfiguration 
>>rather than a real attack. OTOH that "Trust this proxy forever" button 
>>is really tempting, because it makes the Internet work, as opposed to 
>>it being blocked. You can send the users off to the browser settings 
>>with a complex task to perform. This will both give the user time to 
>>think if it's really OK, and will make wifi providers for places like 
>>restaurants and airports think twice before deploying this kind of 
>>thing.
>>
>>
>>Step #3 - Connecting to the real server
>>=======================================
>>The browser sends requests through the proxy (in HTTP/1 notation: "GET 
>>https://download.adobe.com"). The proxy tries to connects and does 
>>whatever verification it is configured to do. We might need some HTTP 
>>error status codes to indicate SSL failure.
>>
>>
>>Step #4 - Path information
>>==========================
>>As there may be multiple proxies on path, 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 #5 - Conclusion
>>=====================
>>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. 
>>This allows each of them to make policy decisions about whether the 
>>certificates on the path are all trusted, and whether the ciphersuites 
>>are good enough. It also allows the user to show some nifty UI that 
>>shows the series of proxies on the way.
>>
>>An advantage for proxy vendors is that this allows the removal of two 
>>limitations that MitM proxies currently have:
>>
>>1. The missing EV indications - by sending the actual certificate 
>>chain
>>    to the user, the browser could verify that an EV indication is
>>    appropriate (subject to browser policy). It would be strange to 
>>have
>>    both an indication of extended validation and an indication of an
>>    HTTPS proxy, but sometimes weird things make sense.
>>2. Missing support for client authentication - by sending the client
>>    certificate from the client-side proxy to the server, the server 
>>can
>>    (at an application level) assign a user identity to the session. It
>>    should be noted that this requires the server to trust the proxy 
>>for
>>    this to work. It might be enough that the client trusts the proxy,
>>    but it might not be.
>>
>>
>>TLS is not changed by this proposal except for the alert, but HTTPS 
>>is.
>>
>>I'd love to hear more 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
>>
>