Tor Relay TLS ClientHello SNI fingerprinting

Iranian ParsOnline ISP has a regexp filter for the domain generation algorithm used in Tor for ClientHello SNI field.
www\.[a-z]{4,25}\.com

https://gitweb.torproject.org/tor.git/tree/src/lib/tls/tortls_openssl.c?h=maint-0.4.7&id=21b3397f9b0803134bc458b83cd161de259887fd#n1082

You can connect to the majority of Tor relays, but the connection would freeze if this type of SNI is used along with ClientHello size <= 256 bytes.
Changing the domain name even slightly, like .com to .org allows to connect to Tor Relay.
This filter seem to be applied only to known Relays IP addresses in Tor network.

I thought that the client SNI encoded some signification information for the Tor handshake, but I was mistaken. By my reading of the spec, there are no restrictions on the SNI, and so the name generation algorithm could be changed by a single client compatibly.

What I was thinking of, relating to the name being significant, is actually in the server certificate. A commonName ending in .net indicates a v2 handshake; any other TLD is for a v3 handshake. For backward compatibility, some conventional implementation details of the v2 handshake were selected to be markers of v2 when v3 was introduced.

https://gitweb.torproject.org/torspec.git/tree/tor-spec.txt?id=4234d9325913a0c2ab54a86f2108b3fe99551035#n330

In “in-protocol” (a.k.a. “the v3 handshake”), the initiator sends no certificates, and the responder sends a single connection certificate. The choice of ciphersuites must be as in a “renegotiation” handshake. There are additionally a set of constraints on the connection certificate, which the initiator can use to learn that the in-protocol handshake is in use. Specifically, at least one of these properties must be true of the certificate:

  • The certificate is self-signed
  • Some component other than “commonName” is set in the subject or issuer DN of the certificate.
  • The commonName of the subject or issuer of the certificate ends with a suffix other than “.net”.
  • The certificate’s public key modulus is longer than 1024 bits.

More info: Proposal 176: Proposed version-3 link handshake for Tor.

By the way, please fix cross-compilation of arti. Now there is a problem with the system openssl. Many Rust projects support cross-compilation this way: https://docs.rs/openssl/latest/openssl/#vendored or something like that.

I don’t do any Arti development. It’s better to report at Core Tor - Tor Project Forum or The Tor Project / Core / Arti · GitLab.

Да, я разобрался как кросскомпилировать в linux64 для linux32. На примере Kali Linux (Debian Testing). Правда, это не static сборка, но тоже работает. Ждем поддержку onion.

Вообще, линуксоиды могут утащить отсюда + все зависимые либы, конечно.

Так ведь к вам туда не попадешь. На форуме сидят одни чайники (не разработчики), я как-то спрашивал, никто не ответил. На гитлабе требуется ручное подтверждение (одобрение) учетки (чего я не люблю), да и не подтверждают меня, я тоже как-то пробовал.

Помогли в matrix канале tor-dev. Для гитлаба так и не пришло письмо.