Re: Invalid HTTP2 preface handling?

On 11/02/2015 1:03 p.m., Mark Nottingham wrote:
>> On 11 Feb 2015, at 10:48 am, Greg Wilkins wrote:
>>
>>
>> Section 3.5 says:
>>
>>    Clients and servers MUST treat an invalid connection preface as a
>>    connection error (
>> Section 5.4.1
>> ) of type PROTOCOL_ERROR.  A GOAWAY
>>    frame (
>> Section 6.8
>> ) MAY be omitted in this case, since an invalid
>>    preface indicates that the peer is not using HTTP/2.
>>
>> I'm wondering what would be the problem if on an invalid preface, the server check if it is actually a valid HTTP/1 request and if so, then to proceed on that basis?     This would allow a server to converse a HTTP/1 client that is pointed at a HTTP/2 port - it could be application specific if that conversation was an error message or just a normal HTTP/1 conversation.
>>
>> Is there some attack we would be enabling if we allowed such behaviour in our server?  Anything else undesirable about doing this?
> 
> The client and server have a different idea of what protocol they're talking (however they got there); using a heuristic ("that looks like HTTP/1") is asking for trouble; we've had a history of attacks tricking protocol stacks into thinking they're in a different state...
> 


FWIW I am doing it the other way around in Squid. With a one-way upgrade
from HTTP/1 to HTTP/2 raising both the capabilities and processing
strictness. If at any time a request-line matches the full HTTP/2 magic
prefix it completes outstanding transactions then switches the
connection irrevocably to talking HTTP/2. Treating the connection as if
it had just been opened with native HTTP/2.

Due to HTTP/2's stricter compliance requirements there seem to be no
security issues over what would happen anyway for Upgrade: requests -
and the simpler operation also means less potential bugs.

Amos

Received on Wednesday, 11 February 2015 00:35:34 UTC