Resent-Date: Wed, 11 Feb 2015 01:28:17 +0000
Resent-Message-Id: <E1YLM6D-000680-Lz@frink.w3.org>
MIME-Version: 1.0
In-Reply-To: <54DAA3A4.8060608@treenet.co.nz>
References: <CAH_y2NE5Sa625XEec5WXJ7LdjK+h1b4M=Fc-_iGj2ZQKa1q_jg@mail.gmail.com>
 <5C91DE2C-BC82-4142-B292-815EED3627EC@mnot.net>
 <54DAA3A4.8060608@treenet.co.nz>
Date: Wed, 11 Feb 2015 12:27:41 +1100
Message-ID: <CAH_y2NG0_Y9nnDjLd2Fc_5wBessfy0DOfKBfkH8NiKjyzAiRVg@mail.gmail.com>
From: Greg Wilkins <gregw@intalio.com>
To: Amos Jeffries <squid3@treenet.co.nz>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary=001a11c36724e1e09a050ec5e824
Received-SPF: permerror client-ip=209.85.215.47;
 envelope-from=gregw@intalio.com; helo=mail-la0-f47.google.com
Subject: Re: Invalid HTTP2 preface handling?
Archived-At: <http://www.w3.org/mid/CAH_y2NG0_Y9nnDjLd2Fc_5wBessfy0DOfKBfkH8NiKjyzAiRVg@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list

--001a11c36724e1e09a050ec5e824
Content-Type: text/plain; charset=UTF-8

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 <squid3@treenet.co.nz> wrote:

> 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
>
>
>


-- 
Greg Wilkins <gregw@intalio.com>  @  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.

--001a11c36724e1e09a050ec5e824
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><br>Amos,<br></div><br>that is a good way of doi=
ng 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.=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 While I hear what Mark says about caution, I really d=
on&#39;t see a great risk here and thus will look at supporting it also.<br=
><br>cheers<br></div><div><br></div><div><br></div></div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On 11 February 2015 at 11:34, Amos =
Jeffries <span dir=3D"ltr">&lt;<a href=3D"mailto:squid3@treenet.co.nz" targ=
et=3D"_blank">squid3@treenet.co.nz</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">On 11/02/2015 1:03 p.m., Mark Nottingham wrote:<br>
<div><div class=3D"h5">&gt;&gt; On 11 Feb 2015, at 10:48 am, Greg Wilkins w=
rote:<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Section 3.5 says:<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0 Clients and servers MUST treat an invalid connection =
preface as a<br>
&gt;&gt;=C2=A0 =C2=A0 connection error (<br>
&gt;&gt; Section 5.4.1<br>
&gt;&gt; ) of type PROTOCOL_ERROR.=C2=A0 A GOAWAY<br>
&gt;&gt;=C2=A0 =C2=A0 frame (<br>
&gt;&gt; Section 6.8<br>
&gt;&gt; ) MAY be omitted in this case, since an invalid<br>
&gt;&gt;=C2=A0 =C2=A0 preface indicates that the peer is not using HTTP/2.<=
br>
&gt;&gt;<br>
&gt;&gt; I&#39;m wondering what would be the problem if on an invalid prefa=
ce, the server check if it is actually a valid HTTP/1 request and if so, th=
en to proceed on that basis?=C2=A0 =C2=A0 =C2=A0This would allow a server t=
o converse a HTTP/1 client that is pointed at a HTTP/2 port - it could be a=
pplication specific if that conversation was an error message or just a nor=
mal HTTP/1 conversation.<br>
&gt;&gt;<br>
&gt;&gt; Is there some attack we would be enabling if we allowed such behav=
iour in our server?=C2=A0 Anything else undesirable about doing this?<br>
&gt;<br>
&gt; The client and server have a different idea of what protocol they&#39;=
re talking (however they got there); using a heuristic (&quot;that looks li=
ke HTTP/1&quot;) is asking for trouble; we&#39;ve had a history of attacks =
tricking protocol stacks into thinking they&#39;re in a different state...<=
br>
&gt;<br>
<br>
<br>
</div></div>FWIW I am doing it the other way around in Squid. With a one-wa=
y upgrade<br>
from HTTP/1 to HTTP/2 raising both the capabilities and processing<br>
strictness. If at any time a request-line matches the full HTTP/2 magic<br>
prefix it completes outstanding transactions then switches the<br>
connection irrevocably to talking HTTP/2. Treating the connection as if<br>
it had just been opened with native HTTP/2.<br>
<br>
Due to HTTP/2&#39;s stricter compliance requirements there seem to be no<br=
>
security issues over what would happen anyway for Upgrade: requests -<br>
and the simpler operation also means less potential bugs.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
Amos<br>
<br>
<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas=
s=3D"gmail_signature"><div dir=3D"ltr">Greg Wilkins &lt;<a href=3D"mailto:g=
regw@intalio.com" target=3D"_blank">gregw@intalio.com</a>&gt;=C2=A0 @=C2=A0=
 Webtide - <em>an Intalio subsidiary</em><br><a href=3D"http://eclipse.org/=
jetty" target=3D"_blank">http://eclipse.org/jetty</a> HTTP, SPDY, Websocket=
 server and client that scales<br><a href=3D"http://www.webtide.com" target=
=3D"_blank">http://www.webtide.com</a>=C2=A0 advice and support for jetty a=
nd cometd.<span style=3D"font-family:arial,sans-serif;font-size:13px"></spa=
n></div></div>
</div>

--001a11c36724e1e09a050ec5e824--