How to set fingerprint?

[sem-hub]

Hi.

I decided to try a new feature of mTLS. But I don't understand how to set it correctly. There is no option utls-fp, so I must set it in URL path like "proxy https://user:[email protected]:port?utls-fp=HelloChrome_Auto" ? But it does not work for me. I see the lines in my log: handler.go:84: ERROR Can't satisfy CONNECT request: reading proxy response failed: unable to read HTTP response: EOF

Give me a hint please.

[Snawoot]

Hi! It seems you're doing everything right. Which program serves TLS on the other end? Is it some OpenSSL-based software or dumbproxy as well?

[sem-hub]

Both dumbproxy with the same (simple) config. But first has proxy directive pointed at second one. They works good without FP setting. May be I miss something. I didn't use mTLS before.

[Snawoot]

Oh, I see. You mean uTLS. mTLS is a different beast.

The problem is following: uTLS mimic entire ClientHello message of the TLS handshake from Chrome, which means it will have ALPN extension enabling HTTP/2 (because Chrome uses HTTP/2 if available). Server is unaware about this and will try to speak HTTP/2. But https:// dialer of dumbproxy is purely HTTP/1.1 protocol, so it will send a request which is invalid for negotiated ALPN value and it is unaware about ALPN overriden by forged ClientHello.

Easiest way to solve ithis is just to use HTTP/2 dialer to talk to upstream proxy: -proxy h2://user:[email protected]:port?utls-fp=HelloChrome_Auto.

Other options are:

• Disable HTTP/2 on the remote server side (option -disable-http2)
• Disable ALPN negotiation on the remote server side (option -tls-alpn-enabled=false)

But these are not recommended, both of them will effectively disable HTTP/2 operation on server.

[Snawoot]

Edit: h2://, not https:// in the proposed URL.

[sem-hub]

Great! Thanks for explain. It's work now.