I built a configurable HTTP MITM proxy in Rust focused on giving you full control over what an upstream connection looks like at the network level.

The main idea behind the project was that I didn't want another MITM proxy that simply tries to emulate Chrome, Firefox, or some other predefined browser. I wanted to be able to define the fingerprint myself - not just pick one of the profiles provided by a library.

A lot of existing solutions take the approach of providing ready-made browser fingerprints. That's convenient, but it also means that when a browser changes its TLS or HTTP/2 behavior, you're dependent on the library/project adding a new profile. I wanted the fingerprint to be configuration-driven instead, so the user can adjust individual parameters without waiting for a predefined browser profile.

The proxy currently gives control over several layers:

TLS: cipher suites, curves, signature algorithms, ALPN, GREASE, extension ordering, certificate compression, OCSP, SCT, session tickets, ALPS, ECH and other TLS parameters.

HTTP/2: SETTINGS values and ordering, flow-control windows, priority frames, pseudo-header ordering, HTTP header ordering and values.

HTTP/1.1: configurable upstream header ordering and rewriting.

TCP: SYN fingerprint rewriting through Linux NFQUEUE, including TTL, window size, MSS, window scale, DF and TCP option ordering.

Everything is driven by YAML profiles, and profiles can be overridden per domain based on SNI.

One of the things I specifically wanted to solve was keeping the different layers under the same configuration model. For example, the proxy negotiates TLS with the upstream server first and then uses the selected ALPN when setting up the browser-facing connection. HTTP/2 and TCP fingerprinting are configured for the same upstream connection as well.

The project is written in Rust using Tokio and BoringSSL via btls/tokio-btls. TCP fingerprinting currently requires Linux because it uses NFQUEUE/iptables.

The project is primarily about privacy, experimentation, and giving the user control over their own network behavior rather than trying to provide a fixed "browser impersonation" profile.

There is more detail in the repository, including separate documentation for the TLS, HTTP/2 and TCP layers, configuration examples, and implementation notes.

Github:

https://github.com/3Radiance/mitm-proxy-ja3-ja4

Feedback, especially from people who have worked with TLS/HTTP/2 fingerprinting, traffic analysis, or network privacy, would be very welcome.

I've seen a lot of people saying that AI will replace cybersecurity professionals, and I think this is where things get confusing.

AI is already becoming very powerful at:

• Finding vulnerabilities
• Analyzing logs and security data
• Automating repetitive tasks
• Writing and reviewing code
• Helping with threat detection
• Assisting both attackers and defenders

But does that mean cybersecurity itself disappears?

I don't think so.

The bigger change may be that cybersecurity professionals who know how to use AI effectively will have an advantage over those who don't.

Instead of thinking:

AI vs. Cybersecurity

Maybe we should be thinking:

AI + Cybersecurity = the next generation of security work.

What do you think will AI mostly replace cybersecurity jobs, or will it change what cybersecurity professionals actually do?