16:01:56 <Shelikhoo[mds]> #startmeeting tor anti-censorship meeting
16:01:56 <MeetBot> Meeting started Thu Oct 23 16:01:56 2025 UTC.  The chair is Shelikhoo[mds]. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:56 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:01:56 <Shelikhoo[mds]> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:01:56 <Shelikhoo[mds]> editable link available on request
16:02:07 <meskio> hi
16:02:10 <onyinyang> hihi
16:04:45 <Shelikhoo[mds]> okay I think we can start with the first topic
16:04:46 <Shelikhoo[mds]> CDN77 new domains?... (full message at <https://matrix.debian.social/ircbridge/media/v1/media/download/AZUxetyLxMT_7o98la0a_2mLLVI68HP0MHowJRlT7GUkcVM7uAfyBxscL1UuouXlP4MucqYvUYzVlg35vYn5eABCeaNd1MigAG1hdHJpeC5kZWJpYW4uc29jaWFsL0lCRFVEV09tbkRRa0hqYVVLQ2hSYXhDZg>)
16:05:17 <Shelikhoo[mds]> we have picked up 2 domains from our previous testing targets
16:05:44 <Shelikhoo[mds]> that are confirmed to work on all vantage points as the fronting domains to be used for cdn77
16:06:07 <Shelikhoo[mds]> yet, we are planning to get more domains for testing
16:06:35 <cohosh> we updated the snowflake builtin bridge yesterday: tor-browser-build!1333
16:06:40 <Shelikhoo[mds]> with the hope of having some hot backups just in case
16:07:09 <meskio> we should remember to udpate the bridges in the circumvention map in rdsys-admin
16:07:25 <meskio> I think there are a buch of countries getting specific bridgelines there
16:07:42 <meskio> or maybe we can just remove those specific bridgeliens and just use the default ones in some places
16:08:57 <cohosh> good idea
16:09:08 <Shelikhoo[mds]> personally I think our choice on whether to stop using counties specific bridges depends on why we start using them in the first place
16:09:08 <cohosh> are the order of bridge lines supposed to be a priority ordering in that map?
16:09:47 <cohosh> because if it is, it
16:10:12 <cohosh> would be nice to prioritize ampcache in some places
16:10:38 <meskio> AFAIK is not a priority, as all will be configured in torrc and c-tor will choose what to connect to
16:10:47 <Shelikhoo[mds]> for the purpose of the vantage point, these lines are treated as a sequence of tests
16:11:11 <Shelikhoo[mds]> each of them will be tested individually
16:12:38 <onyinyang> on the conjure side: the updated fronts seem to work for registration, but there is another issue with connecting to phantom proxies that I'm (slowly) debugging with the conjure devs
16:12:50 <onyinyang> it seems that conjure works from some providers but not from others
16:13:30 <Shelikhoo[mds]> I have a look at the pcap and think it is likely that the it is the station's ISP get blocked
16:13:40 <Shelikhoo[mds]> but I didn't test that theory
16:14:37 <onyinyang> Yes, that was one hypothesis we were working with, but it seems like the blocking is not universal
16:15:06 <Shelikhoo[mds]> anything else we would like to discuss on this topic?
16:15:32 <Shelikhoo[mds]> the next topic is:
16:15:32 <Shelikhoo[mds]> Proposal: repeat proxy churn measurement at broker, but one for each pool this time
16:15:32 <Shelikhoo[mds]> from cohosh
16:15:47 <Shelikhoo[mds]> This is about snowflake
16:15:55 <cohosh> yeah
16:15:56 <onyinyang> s/blocking/whatever is going on
16:16:18 <cohosh> i'm looking into enumeration attacks on snowflake
16:16:55 <cohosh> and it's unsurprisingly a lot easier on the unrestricted proxy pool than the restricted one
16:17:07 <cohosh> our previous churn experiments looked at all proxies together
16:17:51 <cohosh> honestly, measuring this doesn't necessarily have any direct outcome associated with it
16:19:07 <meskio> I think it makes sense to run this measurement
16:19:15 <cohosh> my thinking is that enumeration resistance is directly related to both churn and how long proxies go at their capacity (and therefore not polling)
16:19:45 <cohosh> and we know that most standalone proxies with no NATs are on VPS that have probably no churn and high capacities
16:21:09 <cohosh> so it's not like knowing this is going to change what we do, but i am curious about what it actually looks like, because there are a few home networks that have only ip-based filtering and those proxies will work with symmetric NATs
16:21:22 <Shelikhoo[mds]> since we are typically churn hyperloglog++ counting everything on a daily basis, it is hard for us to encounter the case where a proxy keep running at full load for a day
16:22:04 <Shelikhoo[mds]> unless we change the group interval from a day to maybe a hour or less
16:22:18 <Shelikhoo[mds]> unless we change the group by interval from a day to maybe a hour or less
16:22:42 <cohosh> i think for my purposes a day is what i want
16:22:49 <Shelikhoo[mds]> yes...
16:23:42 <dcf1> where is hyperloglog++ counting used? i thought it had been removed in tpo/anti-censorship/pluggable-transports/snowflake#40280
16:24:00 <cohosh> it's not currently implemented as far as i know
16:24:05 <Shelikhoo[mds]> it was removed already
16:24:20 <dcf1> ok
16:24:24 <cohosh> this would add it back and count it for both pools seperately
16:24:40 <dcf1> ok I see, sorry, I'm not caught up on the issues
16:24:43 <cohosh> but i'm open to not doing it, i don't think it's necessary
16:25:13 <Shelikhoo[mds]> I think this is a nice thing to run, but I am unsure how others think about it
16:25:33 <cohosh> it's more like a scientific curiousity of how things are for us in practice
16:27:20 <meskio> +1
16:27:58 <cohosh> ok i'll open a MR for it and leave it open for comments for a week or something like that
16:28:32 <cohosh> that's it from me
16:29:08 <Shelikhoo[mds]> anything additional comment about this topic?
16:29:41 <Shelikhoo[mds]> the next topic is:
16:29:41 <Shelikhoo[mds]> should we auto enable utls-authority?
16:29:41 <Shelikhoo[mds]> continued from last week about making sni imitation easier to configure
16:29:41 <Shelikhoo[mds]> it make easier to configure
16:29:41 <Shelikhoo[mds]> will make servername means differerent thing, depending on whether utls is used
16:29:56 <Shelikhoo[mds]> this is related to webtunnel in lyrebird
16:30:44 <Shelikhoo[mds]> I was hoping to make reach a consensus in this meeting to release a new version for lyrebird next monday
16:31:32 <cohosh> ah i'm sorry, i wanted to read up on this more and i completely forgot
16:31:39 <cohosh> this is what we discussed 2 meetings ago, right?
16:31:51 <Shelikhoo[mds]> maybe 1 meeting a ago I think
16:31:52 <cohosh> at the end of https://meetbot.debian.net/tor-meeting/2025/tor-meeting.2025-10-09-16.00.log.html
16:32:33 <Shelikhoo[mds]> yeah, but anyway we discussed about it a while ago
16:32:51 <meskio> I think is best to make easier what we consider the most common use case, making the servername a different thing depending on the context
16:33:07 <meskio> but I don't have a strong opinion there, and I think is fine the other option, we have already simplified the utls config
16:35:17 <meskio> but Shelikhoo[mds] I got the impresion that you'll prefer to keep it explicit, and you have been the one puttin some head to it
16:36:06 <Shelikhoo[mds]> I try to reduce the side effect of options, which is optimal from an engineering point of view
16:36:35 <Shelikhoo[mds]> but I also understand that it might not be the most user friendly thing
16:37:56 <Shelikhoo[mds]> so I think it is better if I get some additional opinions from others...
16:38:34 <meskio> I agree
16:39:20 <cohosh> if you want, i can look at it after the meeting and comment on the issue
16:39:41 <Shelikhoo[mds]> yes!
16:39:48 <Shelikhoo[mds]> let's move on to the next topic
16:40:15 <Shelikhoo[mds]> https://github.com/EndPositive/slipstream
16:40:15 <Shelikhoo[mds]> DNS tunnel, like dnstt, but using QUIC as the session protocol. The better congestion control of QUIC proves to be important in performance.
16:40:22 <Shelikhoo[mds]> here is an interesting link
16:41:22 <Shelikhoo[mds]> cohosh: please add your comment about this issue to https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/merge_requests/135#note_3277250 if you are willing and able
16:41:51 <Shelikhoo[mds]> then 2 links about geedge leak
16:41:52 <Shelikhoo[mds]> https://geedge-docs.haruue.com/geedge_docs/OM/attachments/129101971_attachments_Orbot_20241111.json... (full message at <https://matrix.debian.social/ircbridge/media/v1/media/download/Aa1Y38lvh8zZXpF9720VVeegR9kJx67KHYHiAf6p61JHfUf7RsGdg45Lmh4cs8HA_TbMs6hC9a-PhBxBT82MO01CeaNf9CtgAG1hdHJpeC5kZWJpYW4uc29jaWFsL1dFVEdXTW9FY2xiZ2lTRVNmQnNHYVhrSw>)
16:42:31 <meskio> nice splitstream, I added the link to our signaling channels ideas
16:42:35 <Shelikhoo[mds]> It seems the fronting domain we, and other anti-censorship tools are using is being monitored by censor
16:42:42 <Shelikhoo[mds]> yes, nice!
16:43:09 <Shelikhoo[mds]> I observed that splitstream is written in C
16:43:13 <dcf1> slipstream is interesting also because it suggests that snowflake could be faster with QUIC on the inside in place of KCP
16:43:45 <cohosh> dcf1: did they try KCP for slipstream and find QUIC to be better?
16:43:46 <Shelikhoo[mds]> personally I think that transport is faster depends on the network environment
16:44:17 <Shelikhoo[mds]> rather than just the auto retransmission control protocol
16:44:33 <cohosh> or did dnstt use KCP already?
16:44:34 <dcf1> cohosh: see https://endpositive.github.io/slipstream/protocol.html
16:44:46 <cohosh> ah ok and i see https://www.bamsoftware.com/software/dnstt/protocol.html
16:44:48 <cohosh> thanks
16:45:13 <Shelikhoo[mds]> so I am not certain that one of them would better in all environments
16:45:47 <cohosh> wow this is a nice writeup
16:45:49 <dcf1> "Achieving high performance in DNS tunneling requires careful management of query rates to maximize throughput while avoiding rate limits imposed by DNS resolvers. In addition, with larger RTTs, DNS tunnels suffer from low performance, showing the importance of a good congestion control algorithm. Since the bandwidth of a single stream is mostly based on the RTT and window size (i.e. related to
16:45:55 <dcf1> bandwidth-delay-product), managing the window size is crucial."
16:46:54 <dcf1> "QUIC implementations are abundant, allowing us to pick and choose an implementation that fits the pull interface proposed in TurboTunnel. The main selection criteria for a QUIC implementation is support for a pull interface and the multipath QUIC extension. ... We’ve found picoquic to be the simplest implementation to work with, supporting the latest proposals and providing a pull interface for
16:47:00 <dcf1> sending and receiving packets."
16:47:49 <dcf1> also the QUIC header can be much smaller
16:48:03 <cohosh> awesome
16:48:09 <Shelikhoo[mds]> nice!
16:48:29 <meskio> cool
16:49:17 <Shelikhoo[mds]> okay anything more we wants to discuss on this topic
16:49:27 <Shelikhoo[mds]> we still have a reading group for this weekl
16:49:31 <dcf1> Geedge Orbot_20241111.json is a file that was originally attached to https://geedge-docs.haruue.com/geedge_docs/OM/index.html, which is a giant table of many application services, including Orbot and VPNs
16:49:49 <dcf1> This is a scraped table of all such JSON files attached to that page: https://gist.github.com/wkrp/89f2f22a2fbcd2f7e3b456e0e576569a
16:50:18 <dcf1> The JSON files have the form of Maat rules; i.e., they are an AND of ORs, with each clause of the AND optionally inverted.
16:50:50 <dcf1> And we see that this "Orbot" json file contains fqdn patterns `*orbot.app`, `*phpmyadmin.net`, `*cdn77.com`.
16:50:58 <dcf1> But how exactly this file may be used, I am not sure.
16:51:36 <Shelikhoo[mds]> I assume this is used to identify what app users are running in a given network
16:51:39 <dcf1> That's all, just the observation that Orbot snowflake domain fronts appear in at least one place, in the form of a matching rule.
16:51:43 <Shelikhoo[mds]> (I guess)
16:51:53 <Shelikhoo[mds]> We will discuss "The Internet Coup" on October 23rd
16:51:53 <Shelikhoo[mds]> https://interseclab.org/wp-content/uploads/2025/09/The-Internet-Coup_September2025.pdf
16:51:53 <Shelikhoo[mds]> Particularly relevant sections: "Blocking online privacy and circumvention tools" section of InterSecLab report on Geedge Networks, mentions Tor, Snowflake, WebTunnel
16:51:53 <Shelikhoo[mds]> Notes: https://github.com/net4people/bbs/issues/519#issuecomment-3282101626
16:52:06 <Shelikhoo[mds]> okay here is the reading group discussion
16:52:41 <dcf1> Oh, also that Orbot JSON file has a JA3 TLS fingerprint: 140e0f0cad708278ade0984528fe8493
16:52:58 <dcf1> "signature_name": "Orbot_JA3_20241114"
16:53:23 <Shelikhoo[mds]> anyone brave enough to try to summarize beyond https://github.com/net4people/bbs/issues/519#issuecomment-3282101626 <- which is a really good summary by the way?
16:53:45 <dcf1> What I like about this report is that it summarizes Geedge products and how they interact with each other
16:54:13 <dcf1> Tiangou Secure Gateway (TSG, I have also seen it called "tango" in the source code) is the actual hardware device looking at packets.
16:54:57 <dcf1> TSG Galaxy is a https://en.wikipedia.org/wiki/Stream_processing system that aggregates events from TSG and can do more correlated or time window-based analysis
16:55:17 <dcf1> (P.S. Stream processing is an important topic in MESA papers as well.)
16:55:50 <dcf1> Cyber Narrator is a dashboard UI that displays information from TSG and TSG Galaxy
16:56:07 <dcf1> Network Zodiac or Nezha is a monitoring system for all the other systems (maybe something like Apache ZooKeeper?)
16:56:35 <dcf1> Besides that, they have a section for the various countries where Geedge equipment is known to be used
16:57:28 <dcf1> Deployment of Geedge seems to involve intensive on-site presence of Geedge engineers
16:58:12 <dcf1> There are also some shocking claims, such as that Geedge personnel and MESA students have live access (e.g. SSH) to traffic flows in the countries where the firewalls are deployed.
16:58:31 <dcf1> And that there are Great Cannon-like DDoS capabilities, possibly.
16:59:32 <meskio> is interesting to see their capabilities, like how they track users, like having alerts for users that change of SIM cards or gather together
17:00:01 <Shelikhoo[mds]> on my side, me and my friends think this is a nice reference to justify many designs in the anti-censorship tool that could be considered overenginnering from someone without specialized anti-censorship knowledge
17:00:42 <meskio> they seem to confirm what we've been seeing in myanmar, that they block vanilla Tor, but AFAIK webtunnel bridges work fine there
17:00:47 <onyinyang> Shelikhoo[mds], hehe
17:01:04 <meskio> :D
17:01:16 <cohosh> Shelikhoo[mds]: nice, was there a particular example that stood out to you?
17:01:36 <dcf1> Regarding DDoS, it seems different than what the report was talking about, but poling around I found this "yydns/att script" that seems to have simple implementations of various kinds of DoS against DNS resolvers.
17:01:40 <dcf1> https://geedge-git.haruue.com/mesalab_git/zhuyujia/yydns.git/tree/att%20script
17:02:05 <dcf1> Using, e.g, CVE-2023-44487 "The HTTP/2 protocol allows a denial of service (server resource consumption) because request cancellation can reset many streams quickly, as exploited in the wild in August through October 2023."
17:02:18 <Shelikhoo[mds]> like censor have a memory/profile of specific internet users
17:02:21 <dcf1> or "By sending specific requests to the target domain name resolution server, this causes degraded service quality or complete service disruption, resulting in a denial-of-service attack."
17:03:22 <Shelikhoo[mds]> like the "assigning scores to users" in page 20
17:03:49 <dcf1> Shelikhoo[mds]: my impression is that this capability is something that ISPs/goverments are asking for
17:04:48 <Shelikhoo[mds]> dcf1: yes... this means we couldn't make anti-censorship tool barely work
17:05:42 <dcf1> One big and interesting open question is how much of this affects our understanding of GFW censorship in China. There are sections for Xinjiang, Jiangsu, and Fujian. But one could also imaging doing something like, network fingerprinting and matching it to the Geedge implementations.
17:05:56 <Shelikhoo[mds]> as each time it get blocked, users will receive "invisible" punishment when it comes to their "score"
17:06:32 <dcf1> The point about identifying new VPN servers by watching the connections of past known VPN users is really interesting.
17:07:01 <cohosh> yeah i was just typing up a comment on that
17:07:03 <dcf1> There is the paper "Identifying VPN Servers through Graph-Represented Behaviors" (https://github.com/net4people/bbs/issues/455) that is sort of a fumbling attempt at doing that.
17:07:08 <Shelikhoo[mds]> we are a little overtime
17:07:19 <cohosh> i was thinking about it from the context of the reputation based bridge distribution work
17:07:39 <cohosh> which is still a mainly academic approach to the proxy enumeration problem
17:07:45 <dcf1> Related, possibly, is "ProxyKiller: An Anonymous Proxy Traffic Attack Model Based on Traffic Behavior Graphs" (https://link.springer.com/chapter/10.1007/978-3-031-70890-9_9) (also by Liu Qingyun)
17:08:06 <dcf1> And this one which I saw recently but haven't read: "Robust network traffic identification with graph matching" (https://www.sciencedirect.com/science/article/abs/pii/S1389128622004029)
17:08:12 <meskio> yes, so we should not design tools that try all possible methods at once, as this will raise the user score
17:08:50 <cohosh> but, if a user's traffic is getting discovered in this way and the proxies they get are getting blocked by a censor associating them with VPN or circumvention tool use, i think the reputation systems will "work" in the sense that those users will be limited in the damage they do
17:08:50 <Shelikhoo[mds]> but the point the censorship device has memory also validate work about (server)host based proxy identification
17:08:57 <ggus> dcf1: fwiw, those orbot rules were/are applied to geedge deployment in Myanmar
17:09:00 <dcf1> Another observation from the leak is that Geedge et al. care waaaaay more about Orbot than they do about desktop Tor Browser.
17:09:01 <cohosh> but unfortunately they themselves will be shut out from getting proxies
17:09:12 <dcf1> Like, it seems desktop circumvention is almost an afterthought, across the board.
17:09:49 <meskio> also, this is in part comming from their PR, I wonder how successful they really are identifying user that move around, switch mac addresses and so
17:10:05 <Shelikhoo[mds]> maybe because in many regions... computer is not as popular as smart phones....
17:10:20 <cohosh> meskio: that's a good point about how autoamted techniques to determine what works might hurt the user
17:11:01 <dcf1> thanks ggus
17:11:04 <meskio> the report in page 57 mention that they have a "nearly complete list of bridges" that they gather quering our distribution systems
17:11:15 <meskio> we've been assuming censors have different blocking lists
17:11:28 <meskio> but that might not be true for some censors
17:11:37 <meskio> and maybe something to consider as part of lox design
17:11:51 <dcf1> that reminds me, it woudl be a good idea to search the files for anything that might be the implementation of an enumeration program
17:12:03 <dcf1> just start with a global grep for "bridgedb" or something
17:12:26 <meskio> or bridges.torproject.org
17:12:38 <ggus> in one of the students repo and research about blocking webtunnel, they were just using scriptzteam repository
17:12:57 <dcf1> haha
17:13:20 <meskio> ohhh, I've been assuming the scriptzteam has too many false postives from censors to actually use it
17:13:38 <dcf1> well, a lot of the student repos are half-baked, it doesn't mean they are actually used
17:13:44 <meskio> sure
17:13:46 <ggus> yep
17:13:56 <Shelikhoo[mds]> they also need to apply for fundings I think, so it is not "wrong" to over advertise things
17:14:15 <dcf1> remember there is a split between MESA graduate students (who may be trying fanciful research stuff) and actual Geedge operational stuff, all of which seem to be present
17:15:09 <ggus> it is important to follow their jira, because this is what goes to production (eg, in myanmar, kazakhstan, etc)
17:15:15 <dcf1> https://github.com/net4people/bbs/issues/519#issuecomment-3434457013 see geedge_jira/issues/OMPUB-1051.json, you can see a process of debugging with a customer network (E21)
17:15:28 <dcf1> "After upgrading the APP Sketch DB to 23.10.680.2 on November 8, as of November 16, the E21 site no longer encountering segmentation faults in third-party DPI issues."
17:17:44 <Shelikhoo[mds]> yeah
17:17:55 <Shelikhoo[mds]> BTW we are slightly overtime...
17:18:03 <dcf1> I have talked about the aspects I wanted to point out, I think. Thanks everyone for reading this.
17:18:13 <Shelikhoo[mds]> is there anything more we wants to discuss in this meeting?
17:18:19 <dcf1> I am sure there will be much more to learn and discuss coming out of it.
17:18:37 <meskio> no, I think it was a nice reading to learn how censors operate inside
17:19:43 <dcf1> In the interesting links, there is a 1h44m video presentation all about Tor and onion services. It's all in Chinese and I couldn't tell whether it's interesting at all. A Chinese speaker may want to skim it.
17:19:48 <dcf1> https://geedge-docs.haruue.com/mesalab_docs/study/attachments/27716171_attachments_20220602.mp4
17:20:24 <dcf1> From what I could tell looking at the visuals, it seemed mostly like a high-level overview, like for example a university lecture introduction to Tor.
17:22:55 <Shelikhoo[mds]> okay, I think this is the end of our meeting
17:23:01 <Shelikhoo[mds]> thanks everyone
17:23:07 <Shelikhoo[mds]> #endmeeting