[Bot detection] Add a second kind of fingerprint collection

[Dryusdan]

What would you like to be added?

/kind feature

I was really looking forward to the bot detection feature.
But, the fingerprint collection require Javascript (and maybe someday can be spoofed ?).
Also, javascript requirement can be a blocker for some users who disable Javascript or some reader that don't implement it.

I think, adding a TLS fingerprint (like ja4 and not ja4+) with matching user_agent and fingerprint to determine if user can access or not (without javascript) and let admin choose if tls fingerprint is require, device fingerprint or both

Why is this needed?

This is needed to no discriminate some users, device or something else and (maybe) make Crowdsec’s WAF even more secure

PS : another haproxy ressource : https://github.com/O-X-L/haproxy-ja4-fingerprint ^^

[github-actions]

@Dryusdan: Thanks for opening an issue, it is currently awaiting triage.

In the meantime, you can:

1. Check Crowdsec Documentation to see if your issue can be self resolved.
2. You can also join our Discord.
3. Check Releases to make sure your agent is on the latest version.

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.

[github-actions]

@Dryusdan: There are no 'kind' label on this issue. You need a 'kind' label to start the triage process.

• /kind feature
• /kind enhancement
• /kind refactoring
• /kind bug
• /kind packaging

Details

I am a bot created to help the crowdsecurity developers manage community feedback and contributions. You can check out my manifest file to understand my behavior and what I can do. If you want to use this for your project, you can check out the BirthdayResearch/oss-governance-bot repository.

[Dryusdan]

/kind feature

[blotus]

Hello,

JA4 is definitely something we have been looking at, but unfortunately, implementation is kinda tricky: because it relies of the TLS handshake, it's pretty tricky to get the data from the bouncers:

• I tried for nginx with LUA, we can get some information about the handshake, but part of it (such as extensions unknown to the openssl version linked with nginx) are dropped (although I haven't checked in details the impact this would have on the ability to use the hash to detect bots). A fully working implementation would require a native nginx module (and even a patch to both nginx and openssl, see https://github.com/FoxIO-LLC/ja4-nginx), which we have been actively avoiding since the start, as this comes with its own headaches distribution-wise (you need to ship one module per nginx version)
• Situation is even worse with traefik: AFAIK, there's no way to get the information at all
• HAProxy does seem the most straightforward to implement

Having something relying more on the user infrastructure (eg, they somehow provide the hash to the bouncer) could be a potential solution, but it would make the setup much more complex, and if I had to guess, would be barely used.

If you (or anyone) has any ideas/workaround for those issues, we'd be more than happy to add support for it !

[Dryusdan]

Hum, I try only with Haproxy, that’s probably why I thought about it again immediately 😅

Send the hash to the bouncer can block request process during this time.
I remember the first haproxy bouncer in LUA, in live mode each request will be send (with a cache).

I think, the most basic idea I have to send hash to bouncer is write in the access log, but it's slow to take any action.
And provide an hashmap "this ja4 hash can be one of these user agent".

But it's alway for haproxy 😅 for nginx is not simple at all :/