Alternative server implementation (with padding support)

[bjin]

I recently added naiveproxy payload padding to hprox, a lightweight HTTP proxy server written in Haskell. In case anyone is looking for alternative solutions other than Caddy, please take a look.

The following is an usage example:

# echo "user:pass" > ./hprox_users
# hprox -p 443 -q 8443 -a ./hprox_users --name Caddy \
  -s "example.com:$HOME/.acme.sh/example.com/fullchain.cer:$HOME/.acme.sh/example.com/example.com.key" \
  --rev archive.ubuntu.com:80 --naive --hide

Then hprox will listen on TCP port 443 for HTTPS (both HTTP/1.1 and HTTP/2) and UDP port 8443 for QUIC (HTTP/3), using domain name example.com with certificates issued by acme.sh. hprox will send Server: Caddy header in response, and fallback to http://archive.ubuntu.com for non-proxy connections. Naiveproxy compatible padding will be enabled along with probe resistance. Also, password file ./hprox_users will be Argon2-hashed after first run.

After that, naiveproxy can be configured to connect to either https://user:pass@example.com:443 or quic://user:pass@example.com:8443.

hprox also supports DNS-over-HTTPS and Websocket redirection, please check the README files for features and detailed usage.

Currently only static binary for linux-x86_64 is provided in releases page, but hprox should compile fine on both Linux and macOS (just remember to add --flag hprox:quic to enable QUIC support).

hprox now provides binary for Linux (x86_64/aarch64), Windows (x86_64) and macOS (aarch64). See GitHub releases page.

[klzgrad]

Please consider making it extensible for alternative padding formats, because the current one used in naiveproxy is very naive and is planned to be replaced soon.

[bjin]

the current one used in naiveproxy is very naive and is planned to be replaced soon.

I see. I will sure follow changes made to naiveproxy, and since the user base is quite small for hprox, making backward incompatible changes is also possible.

That being said, is there any details you could share about the upcoming changes?

[klzgrad]

I'm considering adding a new padding frame format and the negotiable process for it. The current padding frame has only one byte to encode padding size. Stronger obfuscation needs two bytes to encode padding size. But that's an incompatible protocol change. So some http headers can help negotiating a protocol version supported by both the client and server.

See example https://github.com/klzgrad/naiveproxy/blob/958d8b012ac2a2eaaa2f94bfc0c5845d4a06770c/src/net/tools/naive/naive_protocol.h#L56.

Currently it's hard coded to pad only 8 packets. Also considering making that flexible.