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
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.
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.