Opened 2 years ago

Last modified 17 months ago

#26425 needs_information enhancement

Add functionality to set SNI for client connections

Reported by: twim Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: ex-sponsor-19, ex-sponsor19
Cc: dmr Actual Points:
Parent ID: Points:
Reviewer: asn Sponsor:

Description

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.

Child Tickets

TicketTypeStatusOwnerSummary
#21115enhancementclosedBuilding Tor With Static SNI

Attachments (1)

0001-Implement-ClientSNI-option-to-set-SNI-for-client-TLS.patch (4.5 KB) - added by twim 2 years ago.

Download all attachments as: .zip

Change History (22)

comment:1 Changed 2 years ago by twim

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

comment:2 Changed 2 years ago by twim

Status: newneeds_review

comment:3 Changed 2 years ago by cypherpunks

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?

comment:4 Changed 2 years ago by cypherpunks

What about SNI-less handshake?

comment:5 Changed 2 years ago by twim

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.

comment:6 Changed 2 years ago by twim

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

comment:7 Changed 2 years ago by cypherpunks

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

Yep

EnableSNI,  BOOL,     "1"

comment:8 Changed 2 years ago by twim

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.

comment:9 Changed 2 years ago by cypherpunks

It should go to another ticket

disagree.
This ticket is already about the same.

comment:10 Changed 2 years ago by dmr

Cc: dmr added

comment:11 Changed 2 years ago by asn

Reviewer: asn

comment:12 Changed 2 years ago by arma

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.

comment:13 Changed 2 years ago by asn

Status: needs_reviewneeds_information

comment:14 Changed 2 years ago by arma

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

comment:15 Changed 2 years ago by teor

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.

comment:16 Changed 2 years ago by cypherpunks

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

comment:17 Changed 2 years ago by nickm

Milestone: Tor: unspecified

comment:18 Changed 19 months ago by cypherpunks

duplicate of #21115 ?

comment:19 Changed 19 months ago by teor

Sponsor: Sponsor19-can

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

comment:20 Changed 17 months ago by gaba

Keywords: ex-sponsor-19 added

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

comment:21 Changed 17 months ago by gaba

Keywords: ex-sponsor19 added
Sponsor: Sponsor19-can

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

Note: See TracTickets for help on using tickets.