Juan Pablo Tosso 12:01:45 UTC
Hello and welcome to our monthly meeting !
Juan Pablo Tosso 12:04:10 UTC
Juan Pablo Tosso 12:07:27 UTC
So for the project status:
Juan Pablo Tosso 12:07:46 UTC
We must set some milestones for the release, but it seems we are stable enough to make it work
Juan Pablo Tosso 12:08:18 UTC
There have been many issues regarding Coreruleset, CRS V3 branch is not compatible with Coraza and V4 is not versioned yet so we cannot guarantee regression compatibility
Juan Pablo Tosso 12:10:58 UTC
A lot of bugfixes and performance issues had been fixed, more than 30 PRs merged in the last 30 days with great enhancements
JC 12:11:41 UTC
There are two main focus on those PRs: 1. performance and 2. compatibility with CRS
↳ JC 12:20:17 UTC
Coraza is a library that should not impact critically in the performance of the application itself despite the intensive work. More so when we talk about envoy environments where the latency added is critical.
↳ JC 12:20:37 UTC
On the other hand, CRS is our main goal in proxy-wasm as it goes in the line of zero-trust.
Juan Pablo Tosso 12:13:26 UTC
That’s an important topic, as CRS are fixing a lot of vulnerabilities and bypasses, it’s been a race to keep track of the changes and maintain compatibility. We are doing our best effort and we expect we should reach a stable compatibility soon
Juan Pablo Tosso 12:14:45 UTC
Also an important announcement, Tetrate has donated https://github.com/corazawaf/coraza-proxy-wasm to Coraza. Special thanks to the tetrate team, @Anuraag Agrawal, @Matteo Pace and @JC This greatly enhances our coverage, as now we support Envoy proxy 😄 and well, any WASM-proxy compatible system
Juan Pablo Tosso 12:15:58 UTC
congratulations on the great work
Juan Pablo Tosso 12:16:38 UTC
has led an incredible bug bounty program in the past months and a lot of vulnerabilities were discovered
Juan Pablo Tosso 12:17:28 UTC
Most of them were patched by CRS rules but there were two vulnerabilities that required engine changes
Juan Pablo Tosso 12:18:09 UTC
This PR corazawaf/coraza#470 changes the default regex for the JSON request body processor mime type
Juan Pablo Tosso 12:18:37 UTC
And this PR corazawaf/coraza#452 adds support for the MULTIPART_PART_HEADERS variable, extending Coraza capabilities to handle multipart bodies
Juan Pablo Tosso 12:20:40 UTC
We have migrated to an immutable pattern, special thanks to @Anuraag Agrawal. It provides a simple and safe mechanism to invoke coraza and handle transactions. It also helps us to write major changes without updating the public API and maintaining compatibility
Juan Pablo Tosso 12:23:29 UTC
And finally, from my part, the latest V3 topics to solve:
JC 12:29:03 UTC
From coraza-proxy-wasm side: we are focused on CRS now as we reach stability in terms of performance with latest changes in GC done by @Anuraag Agrawal
JC 12:29:38 UTC
And CRS includes a set of things, notably response body processing.
JC 12:30:10 UTC
Other than tat the API is stable enough and we don’t expect that much of changes in coraza v3
Juan Pablo Tosso 12:31:01 UTC
thanks JC for the update, we are really excited about coraza-proxy-wasm
Juan Pablo Tosso 12:31:39 UTC
The only topic I would like to review is controlling headers from coraza directives
Juan Pablo Tosso 12:32:09 UTC
If we add a function like tx.AddRequestHeaders(headers http.Header), we could actually control headers
↳ JC 12:53:07 UTC
Please create an issue for htis.
Juan Pablo Tosso 12:32:17 UTC
but it would only apply to implementations using http.Requests
Juan Pablo Tosso 12:32:45 UTC
Would that generate confusion?
JC 12:34:05 UTC
I’d rather not add a function just for http package. Can we use a map[string][]string which is kind of the standard? e.g. grpc uses that
Juan Pablo Tosso 12:34:24 UTC
we can cast http.Header into that, right?
JC 12:34:47 UTC
Yes.
Juan Pablo Tosso 12:35:13 UTC
sure, I mean, having a type defined makes it easier, but we can also do that
JC 12:35:24 UTC
https://pkg.go.dev/net/http#Header
Juan Pablo Tosso 12:36:43 UTC
also, that would only affect coraza implementations assuming coraza is a proxy. If coraza doesn’t run in the edge, then users should be aware it won’t work
Juan Pablo Tosso 12:37:01 UTC
that’s a separation we haven’t made so far
JC 12:37:41 UTC
uhmm
Juan Pablo Tosso 12:38:18 UTC
maybe we should add a function to make connectors announce themself, like modsecurity does
Juan Pablo Tosso 12:38:32 UTC
and the connector should declare if it supports some features
Juan Pablo Tosso 12:39:04 UTC
like coraza.RegisterConnector(“coraza-caddy”, “v1.0", FEATURES_FLAGS)
JC 12:39:11 UTC
Well the library won’t do that ifself. I guess if we add such method then we will need to expose a way to retrieve those headers isn’t and apply the changes in https://github.com/corazawaf/coraza/blob/v3/dev/http/interceptor.go#L26
Juan Pablo Tosso 12:40:13 UTC
exactly
JC 12:40:27 UTC
So it is fine, we don’t need to do any separation.
Juan Pablo Tosso 12:40:50 UTC
cool, so I don’t have any more topics, anything else to discuss?
JC 12:41:57 UTC
not from my side.
Matteo Pace 12:44:11 UTC
Nothing important, but just to do not keep things pending: can I close corazawaf/coraza#438 (comment) after the summary I wrote? Are we all on the same page about this behaviour? (Maybe I was the only one that he was not ahah)
Juan Pablo Tosso 12:54:37 UTC
Can we keep an internal discussion on this? @fzipitria opinion is very important
fzipitria 12:54:55 UTC
Hey! 👋
fzipitria 12:55:25 UTC
Sorry, too many things happening at the same time 🙂
Matteo Pace 12:56:05 UTC
Can we keep an internal discussion on this?Of course, no rush!
fzipitria 12:56:25 UTC
ModSecurity v3 is broken, so we should choose what is best for us.
Juan Pablo Tosso 12:57:01 UTC
Exactly, and we should also know that changing the behavior will break crs tests
fzipitria 12:57:41 UTC
Will it?
fzipitria 12:58:35 UTC
The only problem I recall was with text/plain
Juan Pablo Tosso 12:59:05 UTC
So we should look for the safest and more effective approach, not modsecurity’s
↳ fzipitria 13:00:05 UTC
This could be the law for us.
fzipitria 12:59:19 UTC
This ☝️
fzipitria 12:59:42 UTC
Honestly, ModSecurity’s implementation is a guidance, not a law.
Juan Pablo Tosso 13:00:35 UTC
Great, so we have an agreement on that ?
fzipitria 13:01:43 UTC
BTW, the CRS team is going to work hard on getting the v4 out next week. So the versioning problem might dissapear.
Juan Pablo Tosso 13:02:10 UTC
That would be awesome, we should also add some info to the readme
Juan Pablo Tosso 13:02:34 UTC
@fzipitria is it possible to release a minor crs 3.3 version with re2 compatibility ?
fzipitria 13:04:06 UTC
No, sorry.
Juan Pablo Tosso 13:04:55 UTC
:( ok so we should disclose that we are only compatible with crs 4+
fzipitria 13:05:07 UTC
Yes.
fzipitria 13:05:27 UTC
re2 compatibility in v3 would need to backport a lot, and is not worth it
Juan Pablo Tosso 13:05:37 UTC
Good to know
Juan Pablo Tosso 13:05:46 UTC
Great, any other topic ?
fzipitria 13:07:15 UTC
Not from my side. Expect additional news on CRS by next meeting! 😄
Juan Pablo Tosso 13:07:48 UTC
Ok thank you everyone for participating ! See you on GitHub
Matteo Pace 13:08:24 UTC
Thanks, see you!
fzipitria 13:08:49 UTC
👋