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

Re: Framing and control-frame continuations

From: Amos Jeffries <squid3@treenet.co.nz>
Date: Thu, 07 Feb 2013 18:47:01 +1300
Message-ID: <51133FD5.8020200@treenet.co.nz>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
CC: ietf-http-wg@w3.org
On 7/02/2013 5:27 p.m., Ilari Liusvaara wrote:
> On Thu, Feb 07, 2013 at 03:50:12PM +1300, Amos Jeffries wrote:
>> On 7/02/2013 3:23 p.m., Ilari Liusvaara wrote:
>>> Assuming the following:
>>> - Implicit upgrade to TLS mid-connection is not needed. And
>>> - There is overall connection magic (to break HTTP/1.x).
>> Yes. I assume the same. This magic is the first octets of a
>> connection and cannot be used elsewhere safely.
>> Once some other protocol has been started we must use that protocols
>> defined Upgrade mechanism to change to HTTP/2 explicitly.
> Er, what?
>
> - I see no reason to avoid connection magic from occuring elsewhere

Your example of the uselessness of upgrading WebSockets -> HTTP/2 is a 
good one to answer that.
The framing magic only works if we are guaranteed to be looking at the 
first octets of the new traffic flow. Allowing the magics to be done 
inside an exsting WebSockets connection (and probably TLS as well) risks 
security problems from the old protocol tricking the server into 
thinking it has to perform the magics. All the issues around SSL 
re-negotiation, SNMP tunneling over HTTP/1 etc demonstrate that 
implementation flaws are easily created which open them to being 
tricked. This magic is a risky procedure at best and allowing it to be 
performed on arbitrary octets mid-way down a connection is asking for 
trouble.

> - Websockets needs confirmation that the server is of the right
>    type for security reasons.

Yes. That is my understanding also. Which reinforces my understanding of 
why the RSV bits are always 0 on first packet, with fixed format for the 
first two octets. As part of that security systems server-side input 
validation to trigger the correct server reponse.

> Now if HTTP2 contained built-in websocket-like functionality, then
> confirming HTTP2 server would be enough (this would be enough even
> if such functionality was optional).

I predict that HTTP/2 will have similar security requirements on some 
traffic. Thus my investigation of the magics and how they can/could/will 
interact with other protocols expected to arrive at server ports.


>
>> Intentional. So that HTTP/2 can be defined as an extension to
>> WebSockets and clients Upgrade: to it from inside WebSockets cleanly
>> - broken WebSockets implementations mishandling the WS Upgrade frame
>> will see the HTTP/2 initial handshake as a 0-length frame with FIN
>> set.
> Upgrade: from inside websockets? That makes absolutely no sense
> to me. AFAIK, there is no Upgrade: in websockets (it only uses
> one to switch HTTP -> Websockets).

Indeed yes.  The point was that *if* one did for any reason want to do 
an upgrade from WebSockets->HTTP/2 we should be using a WebSockets 
mechanism to do so, not these magics, for the reasons above. Anyone 
wanting to do an upgrade from WebSockets would be required to justify 
that upgrade and define a process in WebSockets for doing it. We have 
one for HTTP/1 and work is underway for TLS NPN etc.

Amos
Received on Thursday, 7 February 2013 05:47:31 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 7 February 2013 05:47:33 GMT