15:59:30 #startmeeting tor anti-censorship meeting 15:59:31 Meeting started Thu Jan 13 15:59:30 2022 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:31 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:36 hello everybody!!! 15:59:42 hi 15:59:43 hello~ 15:59:45 hi \o/ 15:59:49 our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:59:59 o/ 16:00:09 feel free to add what you've been working on and put items on the agenda 16:00:44 should we start with the first point? kazakhstan 16:00:57 I miss the meetin last week, not sure if something was already discussed there 16:01:11 do someone want to lead it? 16:01:17 we discussed it a lot last week, this time we can follow up 16:01:26 (me wonders if all those discussion points are from last week) 16:01:34 and need cleaning 16:01:48 I cleaned the discussion points from last week but kept the ones that looked like they could use an update 16:01:54 thanks 16:02:19 so I couldn't pay much attention to the KZ situation the last 2 days 16:02:42 hello o/ 16:02:48 some users found that certain ports were accessible even during the shutdown, and as I understand it, the Tor forum post shares instructions on how people can get a bridge on one of these ports 16:02:54 ggus, is that correct? 16:03:08 the discovery of the port 3785 happened after the meeting last week, i think 16:03:27 meanwhile, there were a couple of posts that said the special ports were no longer accesible on at least one ISP (Beeline) 16:03:41 :( 16:03:43 yes, tor user support team answered ~500 users from KZ 16:03:52 wow 16:04:01 that's a lot 16:04:04 This morning I looked at IODA and it looks like the shutdown ended 2022-01-11 00:00? I'm not sure, sometimes the charts can be difficult to interpret. 16:04:36 yes, it seems kz is back online for the last 2 days. 16:04:38 I'm looking at my obfs4 bridge right now that has ports 3785 and 179 open, and it looks like there is currently just 1 user from KZ 16:05:03 but idk if they're blocking tor 16:05:17 https://twitter.com/OliverLinow/status/1481536681656426497 16:05:28 here's my bridge https://metrics.torproject.org/rs.html#details/0E9783A73F029E0910FD72F1EC120CA818868DA0 16:07:03 I set up a couple of private bridges on those port for tor support to hand out: https://metrics.torproject.org/rs.html#details/0EF21F772819956CD8008114C2F0A046258FFD0D 16:07:07 if it's really over, I'm thinking it would be nice to have a little retrospective about what we learned this time 16:07:09 https://metrics.torproject.org/rs.html#details/0EF21F772819956CD8008114C2F0A046258FFD0D 16:07:18 ach, no time for all these things :( 16:07:20 they had some traffic, but not tons of it 16:07:31 but this restoration network connectivity seems to attributed to government regain control of region with force...... So my feeling toward this is mixed.... 16:07:42 same: https://metrics.torproject.org/rs.html#details/9895B5226332DD07952CE9C3468AB8F83C7A5E39 16:07:46 dcf1: i don't think we're sharing your bridge on frontdesk@ email. 16:08:00 I will say that we had some hopeful results during this shutdown, it was not a complete success but we showed that a shutdown is not necessarily a hopeless situation 16:08:16 one user reported that cohosh bridge was blocked on beeline ISP, though. 16:08:18 ggus: you say tor is blocked, do you know what circumvention mechanisms work there? 16:08:27 I agree with dcf1 16:08:30 dcf1: can you explain how you found that port 3785 was working? 16:08:48 Ideas: Does it make sense to deploy dnstt bridges? 16:09:20 it wasn't me, it was users who reported that https://github.com/net4people/bbs/issues/99#issuecomment-1008347493 16:09:26 ah! 16:09:39 meskio: i said that i don't know if tor is blocked 16:09:42 As it seems DNS traffic was always available during the "network disruption" in KZ. 16:09:54 https://ntc.party/t/network-shutdown-all-around-kazakhstan/1601/16 "I guess people found it out by brute-forcing different ports" 16:09:54 ggus: ok, I just missread, sorry 16:10:32 Knowing about 3785, I did some port scans to find other potentially working ports, of which port 179 (bgp) apparently worked for at least some for at least a while https://ntc.party/t/network-shutdown-all-around-kazakhstan/1601/20 16:11:08 3785 is used by BFD which is directly related to BGP 16:11:15 for the port scanning trick, do have to do the scan from kazakhstan? 16:11:20 anadahz: yes, one thing I wish had gone better is having DNS tunnels more reading for deployment, and be ready for the onset of blocking 16:11:52 apparently dnstt was working for at least one person we were corresponding with, but I think it was about 2 days into the shutdown before we got that working 16:11:58 Correct me if I am wrong, DNSTT works by using encrypted DNS as transport. I guess when we say dns still works, we means unencrypted dns 16:12:02 tbh, when i saw the shutdown graphs, i thought we couldn't do anything 16:12:08 cohosh: I scanned from outside, just guessing that the rules would be bidirectional 16:12:29 thanks! seems like a good trick to have ready for other shutdowns 16:12:53 shelikhoo: dnstt has a plaintext UDP mode, which is what was working during the shutdown. Not DoH or DoT. Plaintext UDP mode is covert, though, and it's easy to block if you know what to look for. 16:13:34 I left the plaintext UDP mode in for just such situations as this though, it may come in handy some day 16:13:52 dcf1: Yes, plain text UDP is good for personal usage 16:14:07 but for tor, just another domain to block 16:14:34 btw "plaintext" just means that the DNS messages are inspectable, the tunneled traffic is still encrypted. So they can detect and block you, but cannot read what you are saying. 16:14:47 * meskio recalls how many times have being able to connect using iodine in paid networks, should set up dnstt 16:16:05 anything more about kazakhstan? should we move to the next point? 16:16:11 that answers all my questions 16:16:31 i'm curious about matching up the usage metrics with the number of front desk replies 16:16:35 if there's something to be learned there 16:16:37 dcf1: Do you have some doc somewhere for a torrc with dnstt ? 16:16:39 about usability or blocking 16:16:52 becuase my bridge usage was still pretty low despite (i think?) being handed out 16:17:11 anadahz: https://www.bamsoftware.com/software/dnstt/#proxy-tor 16:17:50 dcf1: thx! 16:17:54 cohosh: it would be nice to have a vantage point on KZ, since one person reported that your bridge wasn't working on beeline ISP. 16:18:43 yeah good point 16:18:59 +1 on more vantage point 16:19:04 (that's all from me for now on this subject) 16:19:04 from one of the bridges that we shared with kz people: Heartbeat: In the last 6 hours, I have seen 15 unique clients. 16:19:10 How feasible is to have a bridge listening to multiple ports preferably with the same key config? 16:19:42 anadahz: that's easy, you can do it with port forwarding: https://ntc.party/t/network-shutdown-all-around-kazakhstan/1601/30 16:19:43 On Linux, this can be achieved with a single iptables command 16:20:00 Not so easy: getting BridgeDB to know about the different port. It's more useful for manual distribution. 16:20:45 Unfortunately I do not think you can just use multiple ServerTransportListenAddr, I think there's an issue about that. 16:20:53 Great! Shall we opt to use multiple ports to bridges so that bridges can be potentially reused (like in the case of KZ)? 16:21:26 we don't have currently a good mechanism to provide bridges with an specific port 16:21:33 there is an issue about that 16:22:04 https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40041 16:22:28 dcf1 pointed out a good reason why it might not be a good idea 16:22:50 at least not without some extra features to prevent enumeration that way 16:22:58 So from the time that we found out that specific ports were not blocked in KZ the bridges should be configured to listen to all known non-blocked ports available. 16:23:27 are there reasons to not listen on all ports? 16:23:42 ^ even better! 16:24:22 we'll need to modify a bunch of pieces to make that work, but might be a nice idea 16:24:47 irl: with a probe-resistant protocol like obfs4, it's probably okay. with protocols that are not probe resistant, more ports makes it easier to find. 16:25:39 That's the current bug with obfs4 bridges needing to expose a vanilla tor ORPort, if a user ever naively connects to the ORPort, it's passively detectable as tor, and the whole IP can be blocked along with the obfs4 port 16:26:20 Another idea that requires a bit more work will be to deploy some relay honeypots, to help us understand how the censors are blocking them. 16:29:01 great, I guess we should explore more the idea of binding to multiple ports 16:29:07 +1 16:29:11 should we continue with the next point of the agenda? 16:29:16 probetest keeps breaking... 16:29:18 anadahz: is this along the lines of what you are thinking of? https://www.bamsoftware.com/proxy-probe/ 16:29:38 dcf1: When I was testing obfs4 blocking pattern, I avoided ORPort issue by forwarding traffic from an additional VPS to the vps hosting that obfs4 bridge 16:29:45 I left this discussion item just to see if shelikhoo had discovered anything yet 16:30:39 No, I haven't begin to investigate this. 16:31:07 anadahz: back in 2016/2017, we used a VPN provider in KZ, called GoHost.kz. Not sure if it still exists/works. https://www.bamsoftware.com/papers/thesis/#sec:proxy-probe-kazakhstan 16:31:15 ok, we have an alert and are watching for it while the problem is still there 16:31:37 I guess we don't need to discuss more about it until shelikhoo comes with news, good luck with the hunt 16:31:46 on the next point, about the fronting domain, I just have a small update 16:32:05 last week, we had the question of what happens when tor is configured with multiple bridges that have the same fingerprint 16:32:33 I happened upon a couple of issues that say tor will actually use only one of the bridge, not all of them -- but that this is not considered desirable/expected 16:32:38 https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40242 16:32:43 https://gitlab.torproject.org/tpo/core/tor/-/issues/40193 16:33:07 dcf1: I need to refresh my memory by rereading this paper. I was thinking though of deploying some IDS or something similar and try to understand any blocking patterns during censorship incidents. 16:33:50 not sure if this is helpful for our ideas re having multiple snowflake bridges 16:34:02 dcf1: thanks for dredging that up 16:34:31 anadahz: ok, interesting 16:34:41 if we're just doing load balancing on a single machine it sounds like it won't be an issue? But if we want more than one machine it will be 16:34:57 correct, it's not an issue for the plan we have now 16:35:01 oh this ticket is only 1 year old 16:35:03 heh 16:35:53 I found it while looking for something else. 16:36:48 i vaguely recall seeing it while making this: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Roadmaps/Core-Tor-Roadmap 16:37:47 but now there's a definite use-case for it 16:38:05 that is seperate from the IPv6 bucket i sorted it into 16:39:02 anyway, good to know :) 16:40:28 anyway, it was a productive session two days ago 16:40:34 we are getting there slowly 16:41:45 Yes, I think the load balanced snowflake bridge will be good for test once the onion key diverge issue is resolved 16:42:38 should we talk about china anti-fraud? 16:42:41 shelikhoo? 16:42:46 Yes 16:43:24 https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40026 16:43:32 can you do a summary of the situation? 16:44:32 There is a (new) kind of censorship observed in China, that block less common websites in addition to the websites that GFW blocks 16:44:56 users will be redirected to a "Anti-Fraud" Webpage 16:45:56 :( 16:46:16 Currently there is detailed report about this kind of censorship 16:46:28 and I have no vantage point there 16:46:48 Currently there is no detailed report about this kind of censorship 16:46:48 is it confirmed that it's done with an allow list rather than a block list? 16:47:10 shelikhoo: OONI Telemetry data == OONI reports ? 16:47:51 No, I am unable to independently confirm that this censorship is a allow list one 16:48:23 But some user on internet claim their non well known website is hit by this 16:48:26 If I understand correctly, the interesting part about these redirect pages is that the GFW has never before used explicit block pages like this, only DNS injection, RST injection, and IP blocking? 16:48:45 anadahz: Yes, report form OONI 16:48:54 Blockpage/redirect injection is commonly used in other countries, but unusual for China? 16:49:14 shelikhoo: You got this data from OONI's API or AWS S3 bucket? 16:49:32 dcf1: Yes, there is usually no page shown to user when the block happen for national GFW 16:49:55 anadahz: data are retrieved from AWS S3 bucket 16:50:00 shelikhoo: thanks, that's interesting 16:50:10 And additionally 16:50:44 The url user are forwarded to /fzyujing?parameter=XXXXXX 16:50:57 have an base64 data attached to it 16:51:33 This is interesting what data is in it 16:51:45 shelikhoo: thx, that's interesting. It could be reproduced to find similar blocking in other countries 16:51:52 (brb) 16:53:19 thanks for the info 16:53:37 anything more about it? do we want to discuss anything about it? 16:53:38 I didn't receive report from V2Ray users about this since V2Ray have built in countermeasures, but Tor's data cannot show information about regional block like this 16:54:00 so there is a lack of information 16:54:10 help is wanted 16:54:20 shelikhoo: maybe censored planet can help with this 16:54:37 I think they can do regional scans without much difficulty 16:54:38 Yes, we need at least a packet capture to know how it works 16:55:10 there are a lot of conflicting information online that I cannot verify 16:55:43 But we need reliable information to make improvements 16:55:46 over 16:56:02 shelikhoo: Could it be an A/V I see this header tag in most/all reports: X-Adblock-Key 16:56:09 whenever i see "over" used this way i make the radio static noise in my head lol 16:56:45 cohosh: :) 16:57:18 anadahz: It could be, so we need more informations. It is too early to make any decisions based on this. 16:58:00 EOF 16:58:10 There are some very intrusive A/V nowadays that MiM the user's connection. 16:58:12 * cohosh still makes radio static noise 16:59:01 Yes, but the page it redirected to is a government website 16:59:13 (whenever I see EOF, I make the sound of a dot matrix printer in my head :D) 16:59:21 :o 16:59:24 and different user from different isp is forwarded to a different website 16:59:52 so it is unlikely this is a software on user's device that did this 17:00:03 \r\n\r\n 17:01:04 I see you trying to mess up with our heads... 17:01:14 should we talk about finland? 17:01:18 shelikhoo: feel free to ping me so we can have a closer if you like 17:01:40 anadahz: yes! 17:02:36 who did add the point about the user spike in finlad? 17:02:51 https://metrics.torproject.org/userstats-relay-country.html?start=2021-10-13&end=2022-01-13&country=fi&events=off 17:03:27 There was a big spike of users in FI reported here: https://lists.torproject.org/pipermail/tor-talk/2022-January/045793.html 17:04:12 did the spike coincide with a geoip database update? 17:04:57 Where are the geoip database updates reported? 17:05:17 we used to put them on the metrics timeline, but hiro is probably the person to ask 17:06:21 hiro: ^^ 17:06:22 anadahz: see latest email to tor-talk 17:06:28 for a possible explanation 17:06:58 the one from markus ottela 17:07:34 i'm not sure because that's not explicit about it being a *tor* client starting up every time 17:07:41 A user reported this: https://lists.torproject.org/pipermail/tor-talk/2022-January/045795.html 17:07:43 the users metrics come from directory bandwidth consumed 17:08:02 so if it is all from the same IP then it is possible that bootstrapping a ton of clients would cause this 17:08:23 but if they are sharing the same data dir then that wouldn't be happening, it'd just show as a single user 17:09:07 the user in tor-talk is talking about making connections, doesn't sound like they are deleting the data dir for it 17:09:55 is 10min after the hour, if you don't mind I will be closing this meeting as I have to jump into another one 17:10:00 any last words? 17:10:29 \0x00 17:10:32 #endmeeting