Add functionality to set SNI for client connections

Some (not so smart) firewalls restrict Tor connections based solely on SNI. Some of them do look how random is it, while others just whitelist common SNIs. It maybe just enough to set some common SNI for TLS connections to go around these blocks.

changed milestone to %Tor: unspecified

added component::core tor/tor ex-sponsor-19 ex-sponsor19 milestone::Tor: unspecified priority::medium reviewer::asn severity::normal status::needs-information type::enhancement labels

Trac:
0001-Implement-ClientSNI-option-to-set-SNI-for-client-TLS.patch

I have implemented it as a torrc option. Probably the naming isn't good enough.

Trac:
Status: new to needs_review

Some (not so smart) firewalls do look how random is it

Can you post links to such vendors, links to reps, something else? (I think dumb firewalls does simple NXDOMAIN verification, and very dumb fw does IP/SNI/cert verification/comp)

Probably the naming isn't good enough.

CustomSNI maybe?

What about SNI-less handshake?

Some (not so smart) firewalls do look how random is it Can you post links to such vendors, links to reps, something else? (I think dumb firewalls does simple NXDOMAIN verification, and very dumb fw does IP/SNI/cert verification/comp) Oh, not really. It was just my guess as they probably get NXDOMAIN in fact. I observed it on a network and didn't think it may be as simple as DNS resolving. :)

Probably the naming isn't good enough. CustomSNI maybe?

Sounds better! I also was thinking about expanding SNI to ServerNameIndication but it maybe too long and pointless.

What about SNI-less handshake? SNI support in tor was introduced to look more like a web browser (though it's no longer that efficient). AFAIK almost all modern TLS clients use SNI so it may really stand out of the crowd if one isn't using it. Though it can still be a feature to disable SNI as well...

Though it can still be a feature to disable SNI as well... Yep

EnableSNI,  BOOL,     "1"

Though it can still be a feature to disable SNI as well... Yep It should go to another ticket as this one is for altering behavior of SNI.

It should go to another ticket disagree. This ticket is already about the same.

Trac:
Cc: N/A to dmr

Trac:
Reviewer: N/A to asn

I can't imagine normal users would have any chance of figuring out that they need to set this option, and then picking a good option for it.

I would be a bit happier with some sort of adaptive "oh I'm in this network situation, I need to set my SNI like this" algorithm that Tor just does for you. But for that case I would be worried about a network that induces changes in SNI behavior, to confirm that you're being a Tor client.

Did we get an answer to "which firewalls?"

Tor (that is, the vanilla Tor protocol) isn't doing very well these days at imitating real TLS from real browsers. That arms race has mainly shifted to pluggable transports.

Big picture: if we think we can fix things for a lot of users here, we should try to do it. But if adding this patch will fix things for approximately zero users, maybe we should send those people to use pluggable transports instead.

Trac:
Status: needs_review to needs_information

What about a design where Tor has a pool of 20 SNIs, and chooses between them, as its default behavior?

Or it flips a coin and either picks an SNI from the pool, or fabricates a fake one like the current behavior.

Neither of those strategies will make Tor traffic blend in particularly well, but both of them would let a user behind twim's firewall use Tor out-of-the-box.

(I guess they could both help with fingerprinting Tor in other ways though? Like, "find out if the domain they claim to be going to is associated with that other IP address". But, "that domain they claim to be going to doesn't even resolve" is a pretty strong indicator as it is.)

How many of these SNIs do we expect to fail? For example, if we want tor to bootstrap in 30 seconds, after making about 7 connections, we need at least 1/7 of the SNIs to be unblocked.

How it find connection fail because SNI? What about timeouts? You need to package some alive expert with every software bundle.

Trac:
Milestone: N/A to Tor: unspecified

duplicate of #21115 (moved) ?

If we want to do this right, it's probably an anti-censorship team thing.

Trac:
Sponsor: N/A to Sponsor19-can

Adding the keyword to mark everything that didn't fit into the time for sponsor 19.

Trac:
Keywords: N/A deleted, ex-sponsor-19 added

Remove sponsor 19 and add a keyword ex-sponsor19 to mark all the tickets that could have been in the scope of the sponsor.

Trac:
Sponsor: Sponsor19-can to N/A
Keywords: N/A deleted, ex-sponsor19 added

moved to tpo/core/tor#26425 (closed)