- From: Adrien de Croy <adrien@qbik.com>
- Date: Sun, 24 Nov 2013 20:10:55 +0000
- To: "Stephen Farrell" <stephen.farrell@cs.tcd.ie>, "Mike Belshe" <mike@belshe.com>
- Cc: "Yoav Nir" <synp71@live.com>, "Tim Bray" <tbray@textuality.com>, "Mike Bishop" <Michael.Bishop@microsoft.com>, "Alexandre Anzala-Yamajako" <anzalaya@gmail.com>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
------ Original Message ------ From: "Stephen Farrell" <stephen.farrell@cs.tcd.ie> > > >On 11/24/2013 07:15 PM, Mike Belshe wrote: >> >>> > But starting from an approach that assumes you can break TLS to >>> > solve an HTTP problem would be sheer folly. Its been tried and >>> > failed. If its tried again it'll fail again. >>> > >> You're not being practical. If we don't make it work explicitly, >>companies >> are going to roll it out with MITM anyway. They care more about IP >> protection than the additional risk they take on by breaking the TLS >>stream. > >Please see my earlier mail on how many other things would >be broken should we stupidly break TLS for this. [1] And >then go ask all those other folks who depend on TLS what >they think is practical. > >As I've said, doing HTTP scanning or filtering *in* HTTP >seems reasonable in some cases. Breaking TLS to meet that >requirement does not. And breaking TLS is just not needed >if real work on proxies gets done, but I don't know if the >WG will do that or not. I think the HTTP needs to do a lot better job wrt proxying. Support for proxies in http/1.x is pretty half-arsed sorry to be blunt. A couple of headers. And the thing we all rely on (using GET http://authority.... vs GET /something) only works because no browser actually uses the fully qualified form of the request URI which is specified in 2616 except when talking to a proxy (thank goodness). We're designing a protocol here, everything should be deterministic. We shouldn't need to do guessing about what is the target for some proxy credentials, or whether a client thinks it's talking to a proxy or not. In HTTP/2.0 I'd like to see explicit support in the protocol for interactions between client and a proxy. And it would be useful to handle chained proxies. We occasionally get requests where people want to pass creds through to an upstream proxy of their proxy. And even though this has been raised and dumped before, I think it's foolhardy to continue to ignore the existence of intercepted connections. Until we get some decent mechanism to force a client to use a proxy, we're going to get interception. Adrien > >S. > >[1] >http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0906.html >
Received on Sunday, 24 November 2013 20:10:32 UTC