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 <https://sslproxy.example.com/>

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
>
>