Re: Yet another trusted proxy suggestion

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