|
On Nov 6, 2013, at 2:12 PM, Roberto Peon <grmocg@xxxxxxxxx> wrote:
In the context of the IETF, that has to mean encryption with authentication and no authorized or explicit middleboxes.
As soon as you have authorized middleboxes (full disclosure, I was a co-author of a TLS proxy draft [1] that got shot down in the TLS WG), you run into the messy question of "authorized by whom?"
If I install Fiddler to analyze https traffic, that's a trusted proxy. If a government agent installs such a proxy on my computer or on my home router, it's still authorized, but not by me. It's hard to create a slot in the protocol to insert an authorized
intermediary that only the user would be able to authorize. The browser vendor, the OS vendor, the employer, the ISP, the malware developer and the national government are all likely to authorize such a middlebox.
There is a flip side. By refusing to specify an authorized middlebox for the protocol, we end up with all middleboxes being treated as equal. As an example, TLS proxies have no standing in the protocol - they work by signing a certificate on behalf of
the server's domain name. Key pinning ([2]) detects this middlebox and breaks the connection. But there are legitimate proxies, so using a simple heuristic, browsers detect that a proxy exists, and disable the key pinning protection. If there was a way in
the protocol for the proxy to identify itself, clients could then apply a policy that determined whether this was the authorized middlebox (corporate firewall) or some other middlebox. As it is, there are only two things that HPKP can prescribe: disconnect
when faced with any proxy, or allow when faced with any proxy.
Yoav
|