15:58:10 <shelikhoo> #startmeeting tor anti-censorship meeting
15:58:10 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:58:10 <shelikhoo> feel free to add what you've been working on and put items on the agenda
15:58:10 <MeetBot> Meeting started Thu Mar  2 15:58:10 2023 UTC.  The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:10 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:15 <shelikhoo> Hi~
15:58:25 <itchyonion> hello
15:58:37 <onyinyang[m]> hihi o/
15:59:04 <shelikhoo> hi~
15:59:52 <cohosh> hey
16:01:56 <shelikhoo> okay, I didn't see any additional edit, let's start the first discussion topic
16:02:08 <shelikhoo> Should we improve anti-censorship measures against Tor without bridges? Should we fix the fingerprints and randomize them? (ValdikSS)
16:02:18 <valdikss> Hi, 1 min
16:02:30 <shelikhoo> yes! please take your time
16:04:47 <valdikss> Hello everyone. Tor network have a lot of active "classic" relays (6000+) installed on both hosting and residential connections, which could be used to bypass IP-based blocks in the countries with censorship. However, I see a very little effort to improve its anti-censorship characteristics.
16:04:55 <valdikss> For example, Tor has a very distinct and unique TLS fingerprint which is based AFAIK on very old Firefox versions (6+ years old). It is blocked in Turkmenistan.
16:04:59 <valdikss> Domain generation pattern for SNI is also very distinct (www\.[a-z]{4,25}\.com), which is blocked in Iran.
16:06:04 <valdikss> With simple changes such as ciphersuite randomization on every run and domain generation .net and .org suffix, classic relays could be used in both Iran and Turkmenistan. And due to its large amount and presence on residential connection, many relays are reachable in Turkmenistan, where almost all hosting ranges are blocked.
16:06:42 <valdikss> Should classic tunnels receive anti-censorship improvements or are they generally considered not to be used in the countries with strict censorship?
16:08:47 <shelikhoo> There is actually 2 difficulties with improving the anti-censorship part of original Tor protocol
16:09:11 <shelikhoo> firstly, C-Tor is currently being replaced with Rust-Tor
16:09:12 <valdikss> I wrote a program to download all relays from onionoo and check for its reachability, it's working quite fine and may be preferred way to connect to Tor in some cases (classic relays may provide more throughput or better latency): https://github.com/ValdikSS/tor-relay-scanner
16:09:28 <shelikhoo> (Arti)
16:10:02 <shelikhoo> so it is not receive as much attention, that includes anti-censorship attention
16:10:55 <shelikhoo> so almost every change is being "closed to favor arti"
16:11:07 <shelikhoo> which isn't used by default yet
16:11:39 <shelikhoo> so right now is a more difficult time to make improvement on Tor's original protocol
16:12:02 <cohosh> valdikss: thanks for raising this, historically we haven't tried to make tor's ciphersuites censorship resistance also because this is exactly what pluggable transports were introduced to address
16:12:44 <cohosh> is there a situation where using vanilla tor relays is better than using obfs4 bridges?
16:13:21 <cohosh> i guess if there is more churn in the relays then it could work better..
16:13:21 <shelikhoo> secondly, it is about team role, anti-censorship usually work on PT and don't have direct control over tor's spec or code base
16:13:52 <dcf1> sorry I missed the beginning of this discussion; there is an old document about some of the ways that tor changed to become more blocking resistant (tweaking ciphersuites etc.) before pluggable transports:
16:13:56 <dcf1> https://gitlab.torproject.org/tpo/team/-/wikis/projects/Tor/TLSHistory
16:13:56 <shelikhoo> so in general it is easier to fix an issue on PT side, than on C-Tor side
16:14:03 <valdikss> shelikhoo: These two issues mentioned above does not require any changes to the protocol itself. I can connect to the relays with my modifications without any issues. Does Arti follow exactly the same decisions regarding client connections as it is in C Tor, or is it implemented with anti-censorship in mind?
16:14:56 <cohosh> dcf1: ah cool, thanks for the link
16:16:25 <valdikss> <cohosh> is there a situation where using vanilla tor relays is better than using obfs4 bridges? < Yes. The largest reason is their amount: Turkmenistan's internet could be hardly called "an internet", as I'd say 40% of the IP ranges are blocked there. You can hardly find any hosting provider which ranges are reachable just on IP level. Tor Relays are the perfect source of testing for reachability and finding a working relay, while obfs4
16:16:27 <valdikss> bridges could be requested only in a small quantity and are usually 100% blocked (since ≈all of them are on hosting ranges, not on residential connection ranges)
16:16:27 <shelikhoo> valdikss: I have not yet reviewed Arti's censorship resistant awareness in its plain Tor protocol, and can't advise on that
16:17:03 <valdikss> And another pro is that Relays are public and could be just downloaded and scanned for reachability programmatically, without captchas or limits. I just scripted and it works.
16:18:22 <cohosh> valdikss: oh got it, that all makes sense
16:18:45 <cohosh> ahf: just pinging you to read this backlog ^
16:20:09 <shelikhoo> yes, that being said, it is hard to say whether plain Tor relay will be blocked extensively when they are more commonly used
16:20:10 <ahf> gonna take a look - i am in a meeting right now
16:21:09 <shelikhoo> although I agree that it would work for while, until censor also get a list of ip address and block them
16:22:16 <shelikhoo> so we should continue to discuss whether it would work, after the censor is already aware it
16:22:26 <shelikhoo> let's say when we include it by default
16:23:20 <shelikhoo> having an anti-censorship design for a person for a while is easy, while designing one keep working for everyone is much harder
16:23:25 <valdikss> shelikhoo: right now Iran applies domain (SNI) regexp filter for the IP addresses which are involved in Tor network. That means that simple change of www.[a-z].com to www.[a-z].org in ClientHello SNI allows to connect to classic Relays. It's cat-and-mouse game, but not more than other fingerprints which were present in Meek and Snowflake until very recently.
16:25:27 <shelikhoo> valdikss: yes, I think we can discuss this with network team to know if their opinion on this...
16:25:39 <shelikhoo> valdikss: yes, I think we can discuss this with network team to know their opinion on this...
16:26:13 <shelikhoo> for me I think if we wants to change the sni part, we would have to make sni configurable for user
16:26:29 <shelikhoo> without revealing user identity
16:28:04 <shelikhoo> which would require some research or advise...
16:28:28 <shelikhoo> we can create a ticket to track this, but I am unsure how it will progress
16:28:30 <shelikhoo> over
16:29:13 <shelikhoo> anything more on this topic?
16:29:40 <valdikss> I can collect more data and create a ticket with all the information. Patched Tor + relay scanner is currently used in my ongoing project to create and host censorship monitoring probes, so it's quite useful for me.
16:30:04 <shelikhoo> yes! thanks! let's have a wider discussion in the ticket
16:31:22 <shelikhoo> the next part is interesting links
16:31:23 <shelikhoo> https://www.fortinet.com/blog/threat-research/dissecting-tor-bridges-pluggable-transport
16:31:23 <shelikhoo> In which the intrepid FortiNet analyst busts out OllyDbg rather than read the source code.
16:31:23 <shelikhoo> Workaround for server-side Tor block: https://web.archive.org/web/20221205135630/https://www.fortinet.com/blog/threat-research/dissecting-tor-bridges-pluggable-transport
16:31:23 <shelikhoo> Part 2: https://www.fortinet.com/blog/threat-research/dissecting-tor-bridges-pluggable-transport-part-2
16:32:04 <shelikhoo> someone is analysing tor with reverse engineering tools, while source code is available
16:32:36 <shelikhoo> anything we would like to discuss on this topic?
16:33:32 <shelikhoo> okay, I will just combine the next topic with reading group notification that in next week we will discuss paper
16:33:39 <shelikhoo> Detecting Tor Bridge from Sampled Traffic in Backbone Networks
16:33:55 <shelikhoo> and there is a video(or two) about this
16:34:14 <shelikhoo> please remember to read the paper, and maybe watch the video
16:34:27 <shelikhoo> anything more we would like to discuss?
16:34:33 <shelikhoo> in this meeting?
16:35:46 <shelikhoo> okay, let's call it a meeting
16:35:47 <shelikhoo> #endmeeting