Re: comprehensive TLS is not the solution, it's a bug ... (was 2 questions)

Maybe I missed out that and abused Server header, but the gist is still there: in the first request if cached information is not available, which is plain HTTP/1.1, the server advertises its availability of HTTP/2 capabilities; and on the second request or if a previous successful HTTP/2 session is still in cache HTTP/2 traffic is started by sending a HTTP/1.1 Upgrade request which is responded with a HTTP/2 response.

This non-symmetric behavior would throw off some of that MITM attempt (as an unwanted HTTP/1.1 response to this particular request is ignored.)

Sent from my iPhone

> On Apr 1, 2015, at 05:49, Mike Bishop <Michael.Bishop@microsoft.com> wrote:
> 
> The fact that one major Internet company has a bad habit of returning 400 when they see Upgrade: Anything-other-than-WebSockets on a request.
>  
> But that’s a server bug, and we shouldn’t mandate protocol behavior to work around a single implementation’s bug – all the necessary pieces are already in HTTP/1.1.  You don’t need to abuse the Host header – the Upgrade header in a response is already defined to mean exactly that.  It’s a hint of protocols the server would be willing to upgrade to, if the client supports it.  A cautious client can wait for the server to advertise willingness to upgrade, then actually perform the upgrade on the next request.  (And presumably cache the fact for future savings of the RTT.)
>  
> From: phluid61@gmail.com [mailto:phluid61@gmail.com] On Behalf Of Matthew Kerwin
> Sent: Tuesday, March 31, 2015 2:17 PM
> To: Maxthon Chan
> Cc: Walter H.; ietf-http-wg@w3.org
> Subject: Re: comprehensive TLS is not the solution, it's a bug ... (was 2 questions)
>  
> On 1 April 2015 at 05:11, Maxthon Chan <xcvista@me.com> wrote:
> Sorry for my not being aware of that as I am new to this list.
> ​
> ​
>  
> ​
> ​
>  
> ​The archives are at https://lists.w3.org/Archives/Public/ietf-http-wg/
>  
> A lot of ground has been covered there.​
>  
>  
> ​
>  
> ​​
> Any form of HTTP/1.1-based HTTP/2 protocol negotiation must allow a client to ignore hints of HTTP/2 availability and keep speaking HTTP/1.1.
> 
> How about this two-request protocol negotiation:
> 
> The first request is normal HTTP/1.1, and the server announces its HTTP/2 availability by including the string “HTTP/2” at the end of its Server header. This hint will be blissfully ignored by all older browsers that does not support HTTP/2, but it will be picked up by browsers supporting it.
> 
> The second request starts off with a HTTP/1.1 protocol upgrade to HTTP/2 and the server responds to the HTTP/1.1 protocol upgrade request with a HTTP/2 response, which will break non-HTTP/2 browsers (which is intentional here)
> 
> The browser can cache the HTTP/2 availability and all further communication, even a new session, can start with a HTTP/1.1 protocol upgrade and then full-blown HTTP/2 traffic.
>  
>  
> ​How is that any better than the client just sending Upgrade:h2c (or h2) with the first request?​
> 
>  
> --
>   Matthew Kerwin
>   http://matthew.kerwin.net.au/