Allow HTTP/3 by default in 901163/920430

[rsomme...@cloudflare.com]

Hi everyone,

I was looking at rule 901163, which sets a default list of HTTP versions later checked against REQUEST_PROTOCOL by 920430:

https://github.com/coreruleset/coreruleset/blob/v3.4/dev/rules/REQUEST-901-INITIALIZATION.conf#L203

This list doesn't include HTTP/3. Would a PR to add that be accepted?

I'm thinking about this in the context of this Chromium post and increasing amounts of HTTP/3 traffic:
https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html

I suppose this depends on what platform the defaults are optimized for.
If it's Apache then this change wouldn't make sense given it doesn't support HTTP/3.
However, if defaults should also cater to NGINX, it might be worth adding as it's on the milestones for support in the next 5 months:

https://trac.nginx.org/nginx/milestone/nginx-1.19

And there are already branches/patches available to add support:

https://quic.nginx.org/
https://github.com/cloudflare/quiche/tree/master/extras/nginx

Let me know your thoughts!

Richard Sommerville

[Barry Pollard]

Possibly a little early to have this by default because we don't know what values will be used by implementations.

You'd hope it would be nice and simple and "HTTP/3" but in the past Apache started with HTTP/2.0 and then changed to HTTP/2 - which is why both were added to the default config. Ideally we'd avoid this duplication this time and only add what's needed. It could be HTTP/3, h3, QUIC or some other thing!

Also these are just the default set up values - they are expected to be changed to the particular environment they are run in - the default should just be what works for most and I don't think most will be running HTTP/3 and the CRS just yet. CDNs are rolling this out - but have the expertise to tweak this even if they are using the CRS, and they will likely have back end connections as HTTP/2 (or even HTTP/1.1) for a while where CRS might be used by individual implementers. Apache and IIS have no plans on this so no rush there. Nginx is further ahead on this so will be interesting to see what they pass through to ModSecurity as the protocol.

So I'd say hold off for now. Saying that I wouldn't object to adding HTTP/3 if someone really wanted to.

Thanks,

Barry

[Christian Folini]

On Tue, Oct 13, 2020 at 04:52:46AM -0700, 'Barry Pollard' via ModSecurity Core Rule Set project wrote:
> So I'd say hold off for now. Saying that I wouldn't object to adding HTTP/3
> if someone really wanted to.

I agree with Barry. Besides, the next CRS major release is many moons away.
So there is time to wait and see.

Best,

Christian

>
> Thanks,
> Barry
> On Tuesday, 13 October 2020 at 12:20:41 UTC+1 rsomme...@cloudflare.com
> wrote:
>
> > Hi everyone,
> >
> > I was looking at rule 901163, which sets a default list of HTTP versions
> > later checked against REQUEST_PROTOCOL by 920430:
> >
> > https://github.com/coreruleset/coreruleset/blob/v3.4/dev/rules/REQUEST-901-INITIALIZATION.conf#L203
> >
> > This list doesn't include HTTP/3. Would a PR to add that be accepted?
> >
> > I'm thinking about this in the context of this Chromium post and
> > increasing amounts of HTTP/3 traffic:
> >
> > https://blog.chromium.org/2020/10/chrome-is-deploying-http3-and-ietf-quic.html
> >
> > I suppose this depends on what platform the defaults are optimized for.
> > If it's Apache then this change wouldn't make sense given it doesn't
> > support HTTP/3.
> > However, if defaults should also cater to NGINX, it might be worth adding
> > as it's on the milestones for support in the next 5 months:
> > https://trac.nginx.org/nginx/milestone/nginx-1.19
> > And there are already branches/patches available to add support:
> > https://quic.nginx.org/
> > https://github.com/cloudflare/quiche/tree/master/extras/nginx
> >
> > Let me know your thoughts!
> >
> > Richard Sommerville
> >
>

> --
> You received this message because you are subscribed to the Google Groups "ModSecurity Core Rule Set project" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to modsecurity-core-rule-...@owasp.org.
> To view this discussion on the web visit https://groups.google.com/a/owasp.org/d/msgid/modsecurity-core-rule-set-project/7f7acd3c-6478-4eb0-b615-36c1c47e48b5n%40owasp.org.