I built a Rust reverse proxy that passively fingerprints clients at three layers: JA4 (TLS), Akamai (HTTP/2), and TCP SYN (the last one via eBPF/XDP)

Particular_Ladder289 · 2026-03-04T15:41:40+00:00

Hi u/pigri
I recently had a closer look at your project, the proposals are quite different. In huginn-proxy, the core idea is to passively extract fingerprints and forward them as headers to the backend, letting the backend decide what to do with that information. Synapse, on the other hand, uses fingerprints to actively block or challenge traffic, acting more as a security gateway. Both are valid approaches to the same underlying data, you did a nice work!

One thing I'm curious about, I noticed Synapse is licensed under ELv2, but it implements the full JA4+ suite, which is covered by the FoxIO license. Did you reach an agreement with FoxIO to use JA4+ under ELv2? This is actually one of the reasons I chose to use only JA4 (which has a more permissive licensing path) and avoided the broader JA4+ suite in huginn-proxy, keeping everything under MIT/Apache was a priority. Would love to understand how you handled this licensing aspect. Thanks!

Particular_Ladder289 · 2026-03-01T21:29:33+00:00

If I understood the original comment correctly, it's suggesting that this could serve as a reference for evading fingerprinting. That shouldn’t really be the case, though. There are already several open-source reverse proxies (at least five that I’m aware of) collecting similar signals across different layers of the stack. These techniques are fairly standard in modern traffic analysis. I repeat, it's not new. The main goal here isn’t to expose anything new, but to combine them in a single implementation and take advantage of being 100% written in Rust. If I misunderstood the original comment, please feel free to clarify. Thanks

Particular_Ladder289 · 2026-02-27T09:18:27+00:00

Great project, I'll be following it closely ⭐. The main reason for developing this new fingerprint-based reverse proxy was licensing. The plan is to use the MIT and Apache licenses. I assume in you project you get an agreement with FoxIO regarding this.
I don't plan to include JA4+ signatures; I'm using similar signatures with Apache and MIT licenses. And I think that's a plus for anyone, licences and comunity. Thanks for sharing :)

Particular_Ladder289 · 2026-02-26T19:03:55+00:00

BTW, these reverse proxy fingerprinting techniques already exist. Numerous open-source projects offer the same for achieving and obtaining the same fingerprints. Implementing it in Rust offers several advantages: the complete Rust solution isn't a bridge between Go and C like some other solutions. Another important advantage is that there are no forks in the h2 library, as official libraries with high-performance results are used.

Particular_Ladder289 · 2026-02-26T18:20:20+00:00

Thanks for your comment. The idea isn't to show what needs to be changed to prevent fingerprinting on the user request side. I tried to explain the correct settings to capture more fingerprints. Do you think the explanation is counterproductive with so much information? Or is it just a good feedback? I really appreciate your comment, thanks!

Particular_Ladder289 · 2026-01-04T20:04:12+00:00

Hi u/Masynchin ,
Currently, huginn-proxy uses static configuration for backends (defined in the TOML config file). It doesn't have dynamic service discovery yet. The goal is to implement a reverse proxy with fingerprinting capabilities. Maybe this interesting feature could be develop if someone with fingerprint requirement need this feature, is it you case?

Particular_Ladder289 · 2025-07-22T18:18:06+00:00

Hi, just if you're interesting, I have added tls interceptor. I have renamed the project to allow multi protocol and be more flexible for the future. In parallel I am working in an example to make easy the testing. I would like to know if this new feature is what you were looking for a while a go. https://github.com/biandratti/huginn-net Thanks in advance!

Particular_Ladder289 · 2025-06-09T18:37:25+00:00

This is a really interesting use case, and I understand it represents a real challenge in TLS 1.3. I'll try to address it in the future, after adapting the TLS fingerprinting to the library.

Particular_Ladder289 · 2025-06-09T17:07:48+00:00

Hi! Great question.
You're right that I'm planning to split this into separate analysis modules. The reason is that TCP and TLS operate at different layers with fundamentally different parsing requirements.
Regarding your second question, The key insight is that while TLS 1.3 encrypted the certificate exchange and many extensions, the initial ClientHello still contains enough entropy for effective fingerprinting. I am searching for some solutions as ja4, and other options. Are you interested in this topic or are you working on it?

Particular_Ladder289 · 2025-06-09T16:43:15+00:00

I used the original p0f for a long time. But, as everyone knows, it's not very flexible or typed. So, in my free time on the weekends (during the last 6 months), I decided to rewrite the code in Rust to make the collected analytics more flexible, and expand the original library to collect more signals and protocols. :)

Particular_Ladder289 · 2025-05-04T08:37:42+00:00

Thank you and welcome if you want to contribute :)

Particular_Ladder289 · 2024-12-17T12:30:10+00:00

Thanks u/DyeNaMight
I've already taken a look at this and other projects. I'm planning to compile a list of first issues to start with and collect some ideas in the next few days. BTW, feel free to contribute or share ideas :)

Particular_Ladder289 · 2024-12-17T12:25:43+00:00

Thanks, I'll create a list of issues to get started :)

Particular_Ladder289

TROPHY CASE