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

Re: Invalid HTTP2 preface handling?

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 11 Feb 2015 11:03:09 +1100
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <5C91DE2C-BC82-4142-B292-815EED3627EC@mnot.net>
To: Greg Wilkins <gregw@intalio.com>
> On 11 Feb 2015, at 10:48 am, Greg Wilkins <gregw@intalio.com> 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...

Cheers,


--
Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 11 February 2015 00:03:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:43 UTC