Subject: Invalid HTTP2 preface handling?

From: Greg Wilkins <[email-masked]>
Date: Wed, 11 Feb 2015 10:48:51 +1100

Section 3.5 says:

   Clients and servers MUST treat an invalid connection preface as a
   connection error (Section 5.4.1
<http://tools.ietf.org/html/draft-ietf-httpbis-http2-16#section-5.4.1>)
of type PROTOCOL_ERROR.  A GOAWAY
   frame (Section 6.8
<http://tools.ietf.org/html/draft-ietf-httpbis-http2-16#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?

regards

-- 
Greg Wilkins <[email-masked]>  @  Webtide - *an Intalio subsidiary*
http://eclipse.org/jetty HTTP, SPDY, Websocket server and client that scales
http://www.webtide.com  advice and support for jetty and cometd.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Feb 2015 11:03:09 +1100

> On 11 Feb 2015, at 10:48 am, Greg Wilkins <[email-masked]> wrote:
> 
> 
> Section 3.5 says:
> 
> ) of type PROTOCOL_ERROR.  A GOAWAY
>    frame (
> Section 6.8
> ) MAY be omitted in this case, since an invalid
> 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/

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 11 Feb 2015 13:34:44 +1300

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:
>>

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

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 11 Feb 2015 12:27:41 +1100

Amos,

that is a good way of doing it - more or less like an upgrade, but without
the complexity of having to inject the settings frame and HTTP/1 request
into the server.      While I hear what Mark says about caution, I really
don't see a great risk here and thus will look at supporting it also.

cheers

On 11 February 2015 at 11:34, Amos Jeffries <[email-masked]> wrote:

> >> 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...
> >
>
>

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 11 Feb 2015 15:31:46 +1300

> don't see a great risk here and thus will look at supporting it also.

I agree with Mark completely about the 2.0 -> 1.1 transition being
dangerous. 1.1 has a scary amount of legacy tolerances and gaps where
nastiness can squeeze through.

Beyond safety is the other issue of promoting 2.0 at every opportunity
while remaining compatible with a deprecated 1.x.

Amos

---

From: Michael Sweet <[email-masked]>
Date: Tue, 10 Feb 2015 22:14:18 -0500

Um, with all due respect HTTP/1.1 is a Proposed Standard with a lot of years of deployment, while HTTP/2.0 is *almost* a Draft Standard.  Why are we talking about "a deprecated 1.x"?

> On Feb 10, 2015, at 9:31 PM, Amos Jeffries <[email-masked]> wrote:
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: Greg Wilkins <[email-masked]>
Date: Wed, 11 Feb 2015 15:15:38 +1100

> nastiness can squeeze through.

I'm not really sure I see the difference between a 1.1 port being able to
opportunistically upgrade to 2.0 if it see a preface vs a 2.0 port doing a
downgrade if it sees as non-preface.    Both look the same to clients
regardless if they speak HTTP/1 or HTTP/2

Anyway, I've got my answer.  There is no specific threat, just a preference
to not allow such a simple upgrade/downgrade for the sake of prudence.    I
can accept that and while I'm still considering supporting a preface based
version switch, it will be a use-at-own-risk private feature.

cheers

---

From: Martin Thomson <[email-masked]>
Date: Wed, 11 Feb 2015 16:01:18 +1100

> Um, with all due respect HTTP/1.1 is a Proposed Standard with a lot of years of deployment, while HTTP/2.0 is *almost* a Draft Standard.  Why are we talking about "a deprecated 1.x"?

Well... We're headed for "Proposed Standard", which is the same status
as HTTP/1.1, so from a process standpoint they will be on equal
footing.  But there is no question that HTTP/1.1 is far more mature
and interoperable.

My interpretation is that 1.1 hasn't advanced to Draft or Full
Standard is some combination of conservatism and a general
unwillingness to do the necessary busywork, but I'm sure that Julian
would have a more precise answer since I always tune out during those
conversations.

You are probably reading too much into the language people use though.
Many of us here simply want to use HTTP/2 for all the reasons that we
decided to work on it and implement it.

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 11 Feb 2015 07:08:11 +0100

Hi Greg,

> version switch, it will be a use-at-own-risk private feature.

In fact, we all want to be strict on this in order to ensure that no lazy
implementer would notice it works well without the preface and decides not
to emit it. That's where the trouble could start.

Cheers,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 11 Feb 2015 08:49:07 +0100

> footing.  But there is no question that HTTP/1.1 is far more mature

Well, HTTP/2 integrates most of HTTP/1.1. It's basically just a new wire 
format.

> would have a more precise answer since I always tune out during those

RFC 2616 *was* a "draft" standard. That category has been removed, so 
the rewrite of the specs ended up as "proposed" again.

Once we're done with HTTP/2 + satellite specs, I'd vote for applying 
errata to RFC 723* and to move them to full standard.

> ...

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Wed, 11 Feb 2015 08:01:55 +0000

--------
In message <CAH_y2NE5Sa625XEec5WXJ7LdjK+h1b4M=[email-masked]>
, Greg Wilkins writes:

>proceed on that basis?

If by "proceed" you mean "Send back a HTTP/1 response that will
help people at the far end diagnose the problem and then close",
you'll be fine.  Anything more ambitious is on shaky ground.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 11 Feb 2015 22:45:48 +1100

> On 11 Feb 2015, at 7:01 pm, Poul-Henning Kamp <[email-masked]> wrote:
> 

Makes sense — and sounds like a perfect use of 505 HTTP Version Not Supported.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 12 Feb 2015 11:03:53 +1100

> to emit it. That's where the trouble could start.

Willy,

definitely not proposing to allow HTTP2 without the prefix.   I'm saying
that if you want HTTP2, then you must follow the standard exactly -
including the preface.

However, if a HTTP/21 client does connect to a HTTP/2 server, the server
will be able to detect this by the lack of preface.  Standard calls for
that to be a connection failure and I agree that is the prudent action for
the specification to require.     However, I have a use case for which I am
considering a non standard extension that would allow the HTTP/1 connection
to proceed (on the shaky ground as PHK says) and I just wanted to know if
there was a specific threat that would expose, or just a general
would-be-better-if-we-didn't-risk-it type of thing.

cheers