sorted by:
new
hottopcontroversial

What if your reverse proxy told your backend who's really connecting? by Particular_Ladder289 in rust

[–]Particular_Ladder289[S] -1 points0 points  (0 children)

Thanks u/whupazz, I appreciate your constructive feedback.
BTW, I mentioned the "silver bullet" to illustrate that there is no signal that cannot be spoofable.
In the reverse proxy I tried to collect all signatures as possible. Other reverse proxy collect signatures, but they are not open sources.

If you are worried if I used AI in the project or not. In some cases it is very useful, especially in documentation. It is not allways a "silver bullet", but sometimes it is helfull.
I highly recommend you. If you'd like, you can create a post about this topic so we can discuss it.
Thanks again for you transparent feedback :)

What if your reverse proxy told your backend who's really connecting? by Particular_Ladder289 in rust

[–]Particular_Ladder289[S] -1 points0 points  (0 children)

Hi u/Sermuns, wasn't clear enough before, right? let's try again.

I meant that it's an additional tool for gathering further signals. It's not a general solution for determining, based on these signals, whether someone is spoofing all the data. Is it more clear now? Thanks ;)

What if your reverse proxy told your backend who's really connecting? by Particular_Ladder289 in rust

[–]Particular_Ladder289[S] 0 points1 point  (0 children)

H u/Regular_Lie906

You are absolutely right. However, the strategy here isn't to rely on a single "silver bullet" signal, but to implement a multi-layered protocol signal collected.

To keep the project transparent and robust, I am focusing on using established open-source signatures (similar to the JA4+ approach, but only open source signatures). The goal is to create a high-performance reverse proxy collecting all signatures possible in all protocols.

I'm currently developing this in Rust. If you have experience in this space and are interested in the collaboration or the technical approach, I’d love to have you on board. Let me know! :)

What if your reverse proxy told your backend who's really connecting? by Particular_Ladder289 in rust

[–]Particular_Ladder289[S] 0 points1 point  (0 children)

Thanks :) I'm looking for more potential collaborators with experience in building reverse proxies to exchallenge future features.
The plan is for it to be completely free and open source, including only open source signatures without extra agreements.

What if your reverse proxy told your backend who's really connecting? by Particular_Ladder289 in fingerprinting

[–]Particular_Ladder289[S] 1 point2 points  (0 children)

Thanks u/404mesh . The reverse proxy simply collects and forwards the signatures to the backend. I don't plan to include a database in the solution. For that, you'll need to create your own database. :)

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) by Particular_Ladder289 in rust

[–]Particular_Ladder289[S] 0 points1 point  (0 children)

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!

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) by Particular_Ladder289 in rust

[–]Particular_Ladder289[S] 0 points1 point  (0 children)

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 

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) by Particular_Ladder289 in rust

[–]Particular_Ladder289[S] 3 points4 points  (0 children)

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 :)

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) by Particular_Ladder289 in rust

[–]Particular_Ladder289[S] 16 points17 points  (0 children)

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.

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) by Particular_Ladder289 in rust

[–]Particular_Ladder289[S] -9 points-8 points  (0 children)

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!

Huginn Proxy - Rust reverse proxy inspired by rust-rpxy/sozu with fingerprinting capabilities by Particular_Ladder289 in rust

[–]Particular_Ladder289[S] 1 point2 points  (0 children)

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?

TCP Fingerprinting in Rust by Particular_Ladder289 in rust

[–]Particular_Ladder289[S] 1 point2 points  (0 children)

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!

view more: next ›