Re: HTTP/2 DoS Vulnerability (Was: HTTP/2 response completed before its request)

On Tue, Jul 1, 2014 at 4:48 PM, Poul-Henning Kamp <phk@phk.freebsd.dk>
wrote:

> In message <CAP+FsNdAmQbzSnNE9CHM8i1j6oyJ194HnVVm=
> UxZRT1AhpGUAw@mail.gmail.com>, Roberto Peon writes:
>
>
> >It would have been good to have had you sit in while the group involved in
> >creating HTTP2 discussed DoS considerations, which have been brought up
> >consistently over the course of the development of the protocol.
>
> Yeah, well, sorry for not having a budget to spend on HTTP/2...
>

You've effectively stated that you don't believe in it and would have
nothing to do with it in the past.
I'm guessing this had little to do with budget.

In any case, you would be more productive in engaging with the group by
asking neutrally-biased questions and positing scenarios instead of making
statements-of-fact which may not be correct. This is true regardless of how
smart or wise one is, so long as it requires a group of folks to create
change.



>
> That said: If DoS has been brought up consistently, it seems to have
> have very little to show for it.
>

You have yet to prove that, though it is another an interesting theatrical
statement.


>
> >If we see widespread deployment of HTTP2 in the clear, it would end up
> >being no worse than HTTP1 in terms of DoS potential, which is acceptable
> >(if not optimal) today.
>
> I disagree, defending non-TLS HTTP/2 against DoS attacks is going to be
> (much) harder than defending HTTP/1
>

Howso?
I've told you how to do it. Tell me how it doesn't work, or deploy and find
out for yourself, as we are doing.


>
> >In any case, your example is only useful for servers or clients which are
> >not deploying over TLS.
>
> ... because TLS provides the mechanism for "proof of work" for you which
> plaintext HTTP/2 lack.
>
> >Regardless of choosing to deploy with/without TLS, when under DoS attack,
> >one sets the various SETTINGS to conservative values thus,
>
> There is no setting for "I'm going to service only this many reqyests
> so don't send any more until I increase it"
>

Factually incorrect.
SETTINGS_MAX_CONCURRENT_STREAMS does exactly that.



>
> There is no setting for "I'm not accepting HEADERS longer than..."
>

No, you send the data to /dev/null after processing the HPACK stuff (which
is cheap), then return with a 413.
The problem of large headers is not unique to HTTP2, and is arguably worse
in HTTP1 with its many more connections.


>
> There is no setting for "I'm not accepting CONTINUATION at all..."
>

Yes, because that is orthogonal and has zero to do with DoS, and zero to do
with header size as written today regardless of how many times you attempt
to state that the naked emperor is wearing clothes.


>
> So sorry, but no cigar...
>
>
>The question that should be asked is:
> >How is HTTP2 worse than HTTP1 in terms of DoS?
> >With HTTP2 servers can:
> >  - specify a truly tiny max-state size.
> >  - reduce the number of connections accepted
>
> ... but they can not limit the amount of work per connection.
>
> >Given the ability in HTTP2 to set the amount of memory one is willing to
> >consume for any connection, and that the minimum state per connection can
> >be counted in a small number of ints, I think your concern doesn't have a
> >lot of merit.
>
> I'd say you're not thinking creatively enough.
>
>
In a debate, the onus of finding an unworkable scenario depends on the
other party (that'd be you).


> But here's an idea:
>
> 1.  Set up a HTTP/2 server.
>
> 2.  Announce on Defcon that it is more resistant to DoS than a HTTP/1
> server.
>
> 3.  Pop-Corn!
>

The statement can still be true, even while eating popcorn and watching the
server melt down.

'more resistant' != 'impervious'.
Nothing is completely impervious to a large enough DoS attack.

-=R


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