15:59:30 <meskio> #startmeeting tor anti-censorship meeting
15:59:31 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:59:36 <meskio> hello everybody!!!
15:59:42 <irl> hi
15:59:43 <shelikhoo> hello~
15:59:45 <cohosh> hi \o/
15:59:49 <meskio> our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:59:59 <anadahz> o/
16:00:09 <meskio> feel free to add what you've been working on and put items on the agenda
16:00:44 <meskio> should we start with the first point? kazakhstan
16:00:57 <meskio> I miss the meetin last week, not sure if something was already discussed there
16:01:11 <meskio> do someone want to lead it?
16:01:17 <dcf1> we discussed it a lot last week, this time we can follow up
16:01:26 <meskio> (me wonders if all those discussion points are from last week)
16:01:34 <meskio> and need cleaning
16:01:48 <dcf1> I cleaned the discussion points from last week but kept the ones that looked like they could use an update
16:01:54 <meskio> thanks
16:02:19 <dcf1> so I couldn't pay much attention to the KZ situation the last 2 days
16:02:42 <ggus> hello o/
16:02:48 <dcf1> 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 <dcf1> ggus, is that correct?
16:03:08 <cohosh> the discovery of the port 3785 happened after the meeting last week, i think
16:03:27 <dcf1> 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 <meskio> :(
16:03:43 <ggus> yes, tor user support team answered ~500 users from KZ
16:03:52 <meskio> wow
16:04:01 <cohosh> that's a lot
16:04:04 <dcf1> 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 <ggus> yes, it seems kz is back online for the last 2 days.
16:04:38 <dcf1> 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 <ggus> but idk if they're blocking tor
16:05:17 <ggus> https://twitter.com/OliverLinow/status/1481536681656426497
16:05:28 <dcf1> here's my bridge https://metrics.torproject.org/rs.html#details/0E9783A73F029E0910FD72F1EC120CA818868DA0
16:07:03 <meskio> 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 <dcf1> 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 <meskio> https://metrics.torproject.org/rs.html#details/0EF21F772819956CD8008114C2F0A046258FFD0D
16:07:18 <dcf1> ach, no time for all these things :(
16:07:20 <meskio> they had some traffic, but not tons of it
16:07:31 <shelikhoo> 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 <cohosh> same: https://metrics.torproject.org/rs.html#details/9895B5226332DD07952CE9C3468AB8F83C7A5E39
16:07:46 <ggus> dcf1: i don't think we're sharing your bridge on frontdesk@ email.
16:08:00 <dcf1> 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 <ggus> one user reported that cohosh bridge was blocked on beeline ISP, though.
16:08:18 <meskio> ggus: you say tor is blocked, do you know what circumvention mechanisms work there?
16:08:27 <anadahz> I agree with dcf1
16:08:30 <cohosh> dcf1: can you explain how you found that port 3785 was working?
16:08:48 <anadahz> Ideas: Does it make sense to deploy dnstt bridges?
16:09:20 <dcf1> it wasn't me, it was users who reported that https://github.com/net4people/bbs/issues/99#issuecomment-1008347493
16:09:26 <cohosh> ah!
16:09:39 <ggus> meskio: i said that i don't know if tor is blocked
16:09:42 <anadahz> As it seems DNS traffic was always available during the "network disruption" in KZ.
16:09:54 <dcf1> 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 <meskio> ggus: ok, I just missread, sorry
16:10:32 <dcf1> 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 <irl> 3785 is used by BFD which is directly related to BGP
16:11:15 <cohosh> for the port scanning trick, do have to do the scan from kazakhstan?
16:11:20 <dcf1> 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 <dcf1> 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 <shelikhoo> 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 <ggus> tbh, when i saw the shutdown graphs, i thought we couldn't do anything
16:12:08 <dcf1> cohosh: I scanned from outside, just guessing that the rules would be bidirectional
16:12:29 <cohosh> thanks! seems like a good trick to have ready for other shutdowns
16:12:53 <dcf1> 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 <dcf1> I left the plaintext UDP mode in for just such situations as this though, it may come in handy some day
16:13:52 <shelikhoo> dcf1: Yes, plain text UDP is good for personal usage
16:14:07 <shelikhoo> but for tor, just another domain to block
16:14:34 <dcf1> 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 <meskio> anything more about kazakhstan? should we move to the next point?
16:16:11 <dcf1> that answers all my questions
16:16:31 <cohosh> i'm curious about matching up the usage metrics with the number of front desk replies
16:16:35 <cohosh> if there's something to be learned there
16:16:37 <anadahz> dcf1: Do you have some doc somewhere for a torrc with dnstt ?
16:16:39 <cohosh> about usability or blocking
16:16:52 <cohosh> becuase my bridge usage was still pretty low despite (i think?) being handed out
16:17:11 <dcf1> anadahz: https://www.bamsoftware.com/software/dnstt/#proxy-tor
16:17:50 <anadahz> dcf1: thx!
16:17:54 <ggus> 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 <cohosh> yeah good point
16:18:59 <shelikhoo> +1 on more vantage point
16:19:04 <cohosh> (that's all from me for now on this subject)
16:19:04 <ggus> 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 <anadahz> How feasible is to have a bridge listening to multiple ports preferably with the same key config?
16:19:42 <dcf1> 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 <shelikhoo> On Linux, this can be achieved with a single iptables command
16:20:00 <dcf1> Not so easy: getting BridgeDB to know about the different port. It's more useful for manual distribution.
16:20:45 <dcf1> Unfortunately I do not think you can just use multiple ServerTransportListenAddr, I think there's an issue about that.
16:20:53 <anadahz> 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 <meskio> we don't have currently a good mechanism to provide bridges with an specific port
16:21:33 <meskio> there is an issue about that
16:22:04 <meskio> https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/40041
16:22:28 <cohosh> dcf1 pointed out a good reason why it might not be a good idea
16:22:50 <cohosh> at least not without some extra features to prevent enumeration that way
16:22:58 <anadahz> 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 <irl> are there reasons to not listen on all ports?
16:23:42 <anadahz> ^ even better!
16:24:22 <meskio> we'll need to modify a bunch of pieces to make that work, but might be a nice idea
16:24:47 <dcf1> 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 <dcf1> 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 <anadahz> 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 <meskio> great, I guess we should explore more the idea of binding to multiple ports
16:29:07 <cohosh> +1
16:29:11 <meskio> should we continue with the next point of the agenda?
16:29:16 <meskio> probetest keeps breaking...
16:29:18 <dcf1> anadahz: is this along the lines of what you are thinking of? https://www.bamsoftware.com/proxy-probe/
16:29:38 <shelikhoo> 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 <dcf1> I left this discussion item just to see if shelikhoo had discovered anything yet
16:30:39 <shelikhoo> No, I haven't begin to investigate this.
16:31:07 <dcf1> 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 <meskio> ok, we have an alert and are watching for it while the problem is still there
16:31:37 <meskio> I guess we don't need to discuss more about it until shelikhoo comes with news, good luck with the hunt
16:31:46 <dcf1> on the next point, about the fronting domain, I just have a small update
16:32:05 <dcf1> last week, we had the question of what happens when tor is configured with multiple bridges that have the same fingerprint
16:32:33 <dcf1> 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 <dcf1> https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/40242
16:32:43 <dcf1> https://gitlab.torproject.org/tpo/core/tor/-/issues/40193
16:33:07 <anadahz> 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 <dcf1> not sure if this is helpful for our ideas re having multiple snowflake bridges
16:34:02 <cohosh> dcf1: thanks for dredging that up
16:34:31 <dcf1> anadahz: ok, interesting
16:34:41 <cohosh> 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 <dcf1> correct, it's not an issue for the plan we have now
16:35:01 <cohosh> oh this ticket is only 1 year old
16:35:03 <cohosh> heh
16:35:53 <dcf1> I found it while looking for something else.
16:36:48 <cohosh> i vaguely recall seeing it while making this: https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Roadmaps/Core-Tor-Roadmap
16:37:47 <cohosh> but now there's a definite use-case for it
16:38:05 <cohosh> that is seperate from the IPv6 bucket i sorted it into
16:39:02 <cohosh> anyway, good to know :)
16:40:28 <meskio> anyway, it was a productive session two days ago
16:40:34 <meskio> we are getting there slowly
16:41:45 <shelikhoo> Yes, I think the load balanced snowflake bridge will be good for test once the onion key diverge issue is resolved
16:42:38 <meskio> should we talk about china anti-fraud?
16:42:41 <meskio> shelikhoo?
16:42:46 <shelikhoo> Yes
16:43:24 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40026
16:43:32 <meskio> can you do a summary of the situation?
16:44:32 <shelikhoo> 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 <shelikhoo> users will be redirected to a "Anti-Fraud" Webpage
16:45:56 <meskio> :(
16:46:16 <shelikhoo> Currently there is detailed report about this kind of censorship
16:46:28 <shelikhoo> and I have no vantage point there
16:46:48 <shelikhoo> Currently there is no detailed report about this kind of censorship
16:46:48 <cohosh> is it confirmed that it's done with an allow list rather than a block list?
16:47:10 <anadahz> shelikhoo: OONI Telemetry data == OONI reports ?
16:47:51 <shelikhoo> No, I am unable to independently confirm that this censorship is a allow list one
16:48:23 <shelikhoo> But some user on internet claim their non well known website is hit by this
16:48:26 <dcf1> 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 <shelikhoo> anadahz: Yes, report form OONI
16:48:54 <dcf1> Blockpage/redirect injection is commonly used in other countries, but unusual for China?
16:49:14 <anadahz> shelikhoo: You got this data from OONI's API or AWS S3 bucket?
16:49:32 <shelikhoo> dcf1: Yes, there is usually no page shown to user when the block happen for national GFW
16:49:55 <shelikhoo> anadahz: data are retrieved from AWS S3 bucket
16:50:00 <dcf1> shelikhoo: thanks, that's interesting
16:50:10 <shelikhoo> And additionally
16:50:44 <shelikhoo> The url user are forwarded to /fzyujing?parameter=XXXXXX
16:50:57 <shelikhoo> have an base64 data attached to it
16:51:33 <shelikhoo> This is interesting what data is in it
16:51:45 <anadahz> shelikhoo: thx, that's interesting. It could be reproduced to find similar blocking in other countries
16:51:52 <ggus> (brb)
16:53:19 <meskio> thanks for the info
16:53:37 <meskio> anything more about it? do we want to discuss anything about it?
16:53:38 <shelikhoo> 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 <shelikhoo> so there is a lack of information
16:54:10 <shelikhoo> help is wanted
16:54:20 <dcf1> shelikhoo: maybe censored planet can help with this
16:54:37 <dcf1> I think they can do regional scans without much difficulty
16:54:38 <shelikhoo> Yes, we need at least a packet capture to know how it works
16:55:10 <shelikhoo> there are a lot of conflicting information online that I cannot verify
16:55:43 <shelikhoo> But we need reliable information to make improvements
16:55:46 <shelikhoo> over
16:56:02 <anadahz> shelikhoo: Could it be an A/V I see this header tag in most/all reports: X-Adblock-Key
16:56:09 <cohosh> whenever i see "over" used this way i make the radio static noise in my head lol
16:56:45 <anadahz> cohosh: :)
16:57:18 <shelikhoo> anadahz: It could be, so we need more informations. It is too early to make any decisions based on this.
16:58:00 <shelikhoo> EOF
16:58:10 <anadahz> 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 <shelikhoo> Yes, but the page it redirected to is a government website
16:59:13 <anadahz> (whenever I see EOF, I make the sound of a dot matrix printer in my head :D)
16:59:21 <cohosh> :o
16:59:24 <shelikhoo> and different user from different isp is forwarded to a different website
16:59:52 <shelikhoo> so it is unlikely this is a software on user's device that did this
17:00:03 <shelikhoo> \r\n\r\n
17:01:04 <meskio> I see you trying to mess up with our heads...
17:01:14 <meskio> should we talk about finland?
17:01:18 <anadahz> shelikhoo: feel free to ping me so we can have a closer if you like
17:01:40 <shelikhoo> anadahz: yes!
17:02:36 <meskio> who did add the point about the user spike in finlad?
17:02:51 <anadahz> https://metrics.torproject.org/userstats-relay-country.html?start=2021-10-13&end=2022-01-13&country=fi&events=off
17:03:27 <anadahz> 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 <irl> did the spike coincide with a geoip database update?
17:04:57 <anadahz> Where are the geoip database updates reported?
17:05:17 <irl> we used to put them on the metrics timeline, but hiro is probably the person to ask
17:06:21 <anadahz> hiro: ^^
17:06:22 <GeKo> anadahz: see latest email to tor-talk
17:06:28 <GeKo> for a possible explanation
17:06:58 <GeKo> the one from markus ottela
17:07:34 <irl> i'm not sure because that's not explicit about it being a *tor* client starting up every time
17:07:41 <anadahz> A user reported this: https://lists.torproject.org/pipermail/tor-talk/2022-January/045795.html
17:07:43 <irl> the users metrics come from directory bandwidth consumed
17:08:02 <irl> 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 <irl> 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 <meskio> 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 <meskio> 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 <meskio> any last words?
17:10:29 <shelikhoo> \0x00
17:10:32 <meskio> #endmeeting