Re: multiplexing -- don't do it

  

------ Original Message ------
From: "Mike Belshe" <mike@belshe.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: "Amos Jeffries" <squid3@treenet.co.nz>;"ietf-http-wg@w3.org" 
<ietf-http-wg@w3.org>
Sent: 3/04/2012 9:11:26 a.m.
Subject: Re: multiplexing -- don't do it
>
>
>  
> Maybe we need a better way to force a client to use a proxy, and take 
> the pain out of it for administration.  And do it securely (just 
> remembering why 305 was deprecated).
 
 Do proxy pacs or dhcp work for this?
  
I don't know - MS may be able to shed some light there?  I would have 
thought it was considered risky to auto config a proxy outside your LAN.
  
>
>Note that we also need the browsers to honor HSTS end-to-end, even if 
>we turn on "GET https://".
Actually a bigger concern is client certificates.
  
I can't think of a reliable / secure way to get these to work if there 
is an intermediary.  The server would need to trust the intermediary to 
pass on the client cert somehow, and also trust it to not mess with the 
data. I don't see how that sort of trust could be established easily.
  
  
One of the main reasons I'm keen to add GET https:// is to enable 
further locking down of CONNECT.
  
CONNECT is currently a can of worms.  Providing good granular control 
is difficult, since you only have server:port to play with.  I think 
any proposal for GET https:// should also:
  
a) propose a mechanism to bounce a CONNECT request with a status 
telling the client to use GET https:// instead
b) maybe some sort of advertised OPTION in the proxy
c) config on the client to allow this, and therefore also support for 
auto config mechanisms (PAC would need to distinguish between current 
https rules, which result in CONNECT vs some new rule that results in 
GET https://)
  
This would allow our customers to basically lock down CONNECT or turn 
it off completely.
  
  
Adrien