W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: I revised the pro/contra document

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>
Message-Id: <emb2f18a31-7c25-4cba-9f95-85473d0e0058@bodybag>

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


Received on Sunday, 24 November 2013 20:10:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC