- From: Yoav Nir <synp71@live.com>
- Date: Thu, 12 Dec 2013 10:52:32 +0200
- To: Adrien de Croy <adrien@qbik.com>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <DUB124-W296EF93702BBE714390F5CB1DC0@phx.gbl>
> And also for the record. > > Most of my customers would have a big problem with the proposal that > connections to the ("trusted") proxy should be over TLS. It's a must for a decrypting proxy that will do "GET https://"; less so for a proxy that does "CONNECT". > For many of them the proxy is already working the hardware quite hard > (either old hardware or high-end). To reduce capacity by 75% or more > just by making everything TLS would mean they would all need to go get > new or extra hardware for their proxy. I foresee a lot of resistance to > this. Capacity reduction depends on what the proxy is doing. Malware scanning is so onerous, that the TLS part will be lost in the noise, because handshakes will be rare. Caching or simple URL filetering is lighter, so the capacity may be reduced by as much as you say. MitM proxies already do that much work, except that they also sign fake certificates. Their load might even decrease. > I don't see why the client needs to auth the proxy inside a private > network. Because people bring all kinds of stuff to the private network. That's a direct result of making computers smaller than this:http://www.tcf.ua.edu/Classes/Jbutler/T389/RailroadComputer1967.jpg If someone (or some bot) fools your computer to use it as a proxy, it gets access to all your HTTP content, and all your HTTPS meta-data, even without being a decrypting proxy. That is why authentication is needed. Yoav
Received on Thursday, 12 December 2013 08:52:59 UTC