How to control dumbproxy client and server TLS fingerprints

Server side

Usually it's not an issue, but some people may find undesirable to have Go TLS library fingerprints on server side. The way around this is to use some reverse proxy such as HAProxy or Nginx to terminate incoming TLS connection. In that case you just operate dumbproxy on some local port as usual with TLS disabled, but your reverse proxy has TLS enabled and points to dumbproxy.

Note

If you need HTTP/2 to work in that case, you need to set your reverse proxy to negotiate HTTP/2 via ALPN. HAProxy example:

frontend dp_fe
  mode tcp
  bind :443 ssl crt /path/to/cert.crt alpn h2,http/1.1
  default_backend dp_be

backend dp_be
  mode tcp
  server dp 127.0.0.1:8080 send-proxy-v2

Note alpn option of the bind directive. This example assumes dumbproxy is running on local port 127.0.0.1:8080 with -proxyproto option enabled to properly recover client IP address from incoming connection.

Client side

There's two options available.

Fingerprint parroting with uTLS library

In order to mimic some TLS handshake just add utls-fp parameter to upstream proxy specification like this:

dumbproxy -proxy 'https://user:password@example.com:443?utls-fp=HelloChrome_Auto'

Full list of available fingerprints is available here.

Delegation of TLS operation to an external program

It is possible to use external program to establish TLS connection for dumbproxy and then use it for tunneling of requests:

dumbproxy -proxy 'cmd://?cmd=/home/user/1.sh' -proxy 'h2c://user:password@example.com:443'

having external program 1.sh like this

#!/bin/sh

exec openssl s_client \
  -connect "$DUMBPROXY_DST_ADDR" \
  -alpn h2,http/1.1 \
  -quiet \
  -verify_quiet \
  -verify_return_error \
  -nocommands

This way we can use real OpenSSL handshake for proxy connections.