Any plans to implement it in Rust?

[Numenorean]

I see you also developing in rust, so any plans to reimplement same functionality(or like a lite version) in rust(probably using boringssl or openssl)?

[gaukas]

Actually I liked and highly support this idea.

If it is challenging to build a Rust library from rustls that supports ALL features in uTLS, at least it would be valuable to have a library to allow customization to a certain extent, or being able to (almost) perfectly mimic one, or a few, popular TLS implementations/browsers.

[gaukas]

Any early proposal or project draft is welcome and wanted!

[Gowee]

I patched rustls for that purpose for noisy-shuttle. To keep to the changes minimum, I add a new rustls::ClientConnection::new_with that takes a custom client random, a custom session id and a function as an additional param which takes a rustls::Message and modifies it per fingerprints. The implementation isn't porting features from utls while solely exists as a simplified alternative for my needs. And now it is a little outdated.

Porting utls to Rust would be a great idea. I am willing to contribute if anyone is gonna start such. Or I could start a project myself, but I may not be able to maintain it in a timely fashion on my own.

[gaukas]

Thanks for sharing @Gowee! Your fork looks great and indeed contains many features that a rutls library could benefit from.

I am willing to contribute if anyone is gonna start such.

Sure, I don't mind kick this off by forking a popular and mostly-complete TLS library in Rust. Is Rustls a good starting point or what are the other choices? I'm not super familiar with the TLS ecosystem in Rust.

I may not be able to maintain it in a timely fashion on my own.

That is totally fine. Either way I don't believe on the refraction side we have enough capacity for rutls, so it will be more likely a community driven project. We could start it here under refraction's github org for now and decide its fate later.

---

Or utlsr, open for ideas on naming!

[RPRX]

对 Rust 来说，或许直接使用 Chromium 的代码？XTLS/Xray-core#2257 (comment)

---

For Rust, maybe just use the Chromium code? XTLS/Xray-core#2257 (comment)

[raintean]

对 Rust 来说，或许直接使用 Chromium 的代码？XTLS/Xray-core#2257 (comment)

其实尝试做一个cronet的rust binding就OK了. 这个对于rust来说不难.
但是我在做的过程中突然想到一个问题, 我们很难在同一个程序里面提供多个版本的cronet.
换句话说, 这个库强对应一个chrome的版本. 这个就不是很科学了.

---

For Rust, maybe just use Chromium's code? XTLS/Xray-core#2257 (comment)

Actually try to make a rust binding for cronet and you'll be fine. It's not hard for rust.
But one thing that occurred to me while I was doing it is that it is very difficult to provide multiple versions of cronet in the same program.
In other words, the library has to be compatible with one version of Chrome. That's not very scientific.

[fedosgad]

AFAIK, @mhils (author of mitmproxy) has looked for Rust analog of utls around time of mitmproxy v8 release. Maybe he knows something useful about such libraries?

[gaukas]

Thanks for tagging/linking @fedosgad. Out of curiosity, (how) did mitmproxy solve the TLS ClientHello fingerprinting issue in the end?

[mhils]

We don't have ClientHello mimicry in mitmproxy yet. Right now we're using OpenSSL via pyca/cryptography, which makes this pretty hard to implement. I looked into switching to rustls a while ago, but that attempt was abandoned due to compatibility issues (unrelated to mimicry) back then.

[gaukas]

we're using OpenSSL via pyca/cryptography

Does it indicate that mitmproxy produces a relatively unique/unpopular ClientHello fingerprint or not? (Better if would like to provide it in tlsfingerprint.io's format, you may pull from https://client.tlsfingerprint.io/, so we could examine how relatively popular it is)

compatibility issues

I would entertain your insights on this if you would love to elaborate. What kind of compatibility issue and if there are any other good paths Rust (and potentially other programming language) programmer should take to counter the ClientHello fingerprinting?

i.e., if not then perhaps we should try to start building a rustls-based rutls, or alternatively, as @RPRX and @raintean mentioned here, a chromium/cronet Rust binding.

(Disclaimer: refraction is not against such project, but unlikely to spare any capacity on leading/moderating the project. I would suggest starting a new organization and adding interested developers in, unless there is already something we could contribute to.)

[mhils]

Does it indicate that mitmproxy produces a relatively unique/unpopular ClientHello fingerprint or not? (Better if would like to provide it in tlsfingerprint.io's format, you may pull from https://client.tlsfingerprint.io/, so we could examine how relatively popular it is)

$ mitmdump --mode reverse:https://client.tlsfingerprint.io/ &
$ curl -k http://localhost:8080
{"tls_record_version":769,"tls_handshake_version":771,"cipher_suites":[4866,4867,4865,49195,49199,49196,49200,52393,52392,158,159,52394,49187,49191,49161,49171,49188,49192,49162,49172,103,107,156,157,60,61,47,53,255],"compression_methods":[0],"extensions":[0,11,10,35,22,23,13,43,45,51],"extensions_normalized":[0,10,11,13,22,23,35,43,45,51],"server_name":"client.tlsfingerprint.io","supported_groups":[29,23,30,25,24,256,257,258,259,260],"ec_point_formats":[0,1,2],"signature_algorithms":[1027,1283,1539,2055,2056,2057,2058,2059,2052,2053,2054,1025,1281,1537,771,769,770,1026,1282,1538],"alpn":null,"compress_certificate":null,"record_size_limit":[],"supported_versions":[772,771],"psk_key_exchange_modes":[1],"key_share":[29],"application_settings":null,"user_agent":"curl/7.81.0","nid":5075520528980946569,"norm_nid":-7307055319671900602,"id":"466fdf07a41cae89","norm_id":"9a981fe6b4d3f646"}

I would entertain your insights on this if you would love to elaborate. What kind of compatibility issue and if there are any other good paths Rust (and potentially other programming language) programmer should take to counter the ClientHello fingerprinting?

One major blocker for us back then was the lack of support for IPs as dnsAltNames. Rustls supports that nowadays though. :)
Another issue for us was the lack of support for older TLS versions. We have users who put mitmproxy in front of outdated IoT devices to upgrade them to a recent TLS version. Typically not a concern otherwise.