16:00:16 <Shelikhoo[mds]> #startmeeting tor anti-censorship meeting
16:00:16 <MeetBot> Meeting started Thu Apr  9 16:00:16 2026 UTC.  The chair is Shelikhoo[mds]. Information about MeetBot at https://wiki.debian.org/MeetBot.
16:00:16 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:16 <Shelikhoo[mds]> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:00:16 <Shelikhoo[mds]> editable link available on request
16:00:16 <Shelikhoo[mds]> hi~hi~
16:00:23 <theo_> Hi:)
16:00:35 <meskio[mds]> hello
16:00:37 <onyinyang> helloooo!
16:01:20 <cohosh> hi
16:03:07 <Shelikhoo[mds]> A small update about 3 type nat system we discussed previously, there is a vibe powered demo at https://plasma-cyclops.exe.xyz/ for testing nat type of the proxy, as described in https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40077#note_3382448
16:03:43 <Shelikhoo[mds]> feel free to provide comments asyncly while I am working on implementing it
16:04:13 <Shelikhoo[mds]> comments are welcomed here: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/699
16:04:27 <Shelikhoo[mds]> no discussion necessary
16:04:54 <Shelikhoo[mds]> Let's start the first discussion topic:
16:04:55 <Shelikhoo[mds]> (New 04-08) Requesting feedback on broker AIMD dynamic poll interval
16:04:55 <Shelikhoo[mds]> Description: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25598#note_3382867
16:04:55 <Shelikhoo[mds]> Simulation results: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/25598#note_3392744
16:04:55 <Shelikhoo[mds]> Implementation: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/701
16:05:11 <cohosh> that's from me
16:05:24 <Shelikhoo[mds]> thanks! I think this is from cohosh , is that correct?
16:05:39 <cohosh> i've been working on implementing the proxy fairness proposal that we discussed previously
16:05:55 <cohosh> i have a candidate implementation of the dynamic poll rate adjustment at the broker
16:06:36 <cohosh> this change will eventually have a big impact on the proxy pool
16:07:15 <cohosh> so i'd like a comment on the MR from dcf1 and Shelikhoo[mds] at the very least, even if it's just to say that you're okay with moving ahead despite not having time to look at it
16:07:32 <cohosh> and comments from anyone are welcome
16:07:58 <cohosh> the actual changes to the code aren't very big
16:08:11 <cohosh> the feedback i'm looking for is mostly on the algorithm
16:08:25 <Shelikhoo[mds]> yes! I will have a look async, and we can discuss about it in the merge request.
16:08:31 <cohosh> yeah no need for that to be immediate, just wanted to announce it in the meeting
16:08:46 <dcf1> is it a good idea to do a very coarse live experiment to test the assumptions of the simulation?
16:09:18 <dcf1> I am thinking of deploying a temporary, let's say, doubling or halving of the poll interval, and seeing how it affects the client denial rate
16:09:46 <dcf1> is that hard to do, is there a significant fraction of proxies that would not know how to honor a request to change poll rate still?
16:09:48 <cohosh> hmm
16:09:57 <cohosh> yeah we'd have the update the proxy pool
16:10:10 <cohosh> which can take time considering most of the pools are from standalone proxies
16:10:17 <cohosh> *most of the polls
16:10:49 <Shelikhoo[mds]> it is not hard to deploy a broker with such test, but as for the proxies, I think we have to run them ourself to run the test
16:11:29 <cohosh> well it depends on what you want to test. if you want to test the effects of the pool that requires every or most proxies to update
16:11:31 <Shelikhoo[mds]> otherwise the proxy version rollout is going to take very long, as cohosh has already said
16:12:06 <dcf1> there is a subtlety in TCP congestion control, which is that what looks like a linear increase would actually become quadratic, because it not only increases the size of the window, it also increases the rate at which window updates occur
16:12:09 <cohosh> we could do it that way though, start trying to deploy this feature with a static poll rate first
16:12:38 <dcf1> maybe you've encountered that already
16:12:56 <dcf1> I'm not against the idea at all, AIMD is a reasonable approach
16:13:11 <cohosh> dcf1: yeah, my thoughts on that are that increasing the poll interval isn't urgent, it's okay if they are quadratic
16:13:34 <cohosh> the main advantage that increasing this has is a slight enumeration resistance
16:13:58 <dcf1> an early idea behind "broker controls proxy poll rate" is that someone would look at the logs and how many proxies there are, and manually tweak a parameter once a day or so
16:14:17 <cohosh> oh interesting
16:14:23 <dcf1> so I am okay with taking baby steps like that, especially if at first we are not sure to be able to control all the proxies.
16:14:40 <cohosh> i'm not against that. Broker deployments are disruptive to metrics but otherwise not a big deal
16:14:43 <dcf1> to gain an understanding of the live dynamics
16:14:57 <Shelikhoo[mds]> oh, yes, I think start with manually adjusting the rate is a great idea
16:15:06 <Shelikhoo[mds]> or we can have something like min rate and max rate
16:15:39 <dcf1> a safety check on min rate for sure, we don't want to accidentally compute a zero and DDoS the broker
16:16:25 <dcf1> (on that note, maybe proxies could self-adjust to slow down when they encounter a broker failure, I guess that could go wrong as well. maybe you already mentioned that possibility.)
16:16:40 <Shelikhoo[mds]> which allow the algorithm to make automatic adjustment within that range, allow us to test the algorithm with safe bounds
16:17:09 <cohosh> my dynamic poll rate MR does have a min and max poll interval
16:17:24 <dcf1> you're right though that it is irritating to have a break in broker metrics for every restart, maybe this is something that could use a SIGHUP halder or something to re-read a configuration file
16:17:57 <cohosh> yeah, we have that functionality for geoip database reloads
16:18:09 <Shelikhoo[mds]> cohosh: nice!
16:19:13 <cohosh> ok so this is my understanding of the consensus: static manual adjustments first, then this dynamic adjustment patch with constrictive min and max bounds, then loosen the bounds?
16:20:06 <Shelikhoo[mds]> yes! I think that is a good idea! I will read the issue and merge request to provide additional feedback soon.
16:20:21 <dcf1> I think you can do as you think best. I'm just offering that (1) adding the ability and defining the protocol fields to make polling rate adjustment possible, and (2) adding an algorithm to automatically monitor and adjust the polling rate, are two different things.
16:20:25 <cohosh> ok well the merge request is just on dynamic poll rate adjustment so if we're not doing that soon then there's no rush
16:20:43 <Shelikhoo[mds]> yes!
16:20:58 <cohosh> we've already merged the protocol fields, just not support in proxies to honour it
16:21:26 <cohosh> so proxy support is what i'll focus on next
16:21:51 <Shelikhoo[mds]> nice!
16:22:41 <dcf1> The AIMD idea is good and what you're written about it so far looks excellent, thank you for that.
16:22:51 <cohosh> thanks for taking a look!
16:23:14 <cohosh> a benefit of trying a static manual poll interval adjustment is that we have more control if the effect on the proxy pool is not what we expect
16:23:54 <cohosh> there's also another piece of this which is rejecting proxies that are polling too frequently, but i'm still planning to leave that for later
16:25:12 <cohosh> the notion of what "a proxy" is is sufficiently complicated
16:25:16 <Shelikhoo[mds]> yes~
16:26:00 <Shelikhoo[mds]> anything more we would like to discuss on this topic?
16:26:15 <Shelikhoo[mds]> the next topic is:  - Snowflake-targeted DTLS filtering in Russia, starting 2026-03-30  https://github.com/net4people/bbs/issues/603
16:26:16 <cohosh> nothing more from me, this was helpful. thanks!
16:26:28 <Shelikhoo[mds]> thanks @cohosh!
16:27:03 <Shelikhoo[mds]> This topic looks like from dcf1 ?
16:27:36 <Shelikhoo[mds]> There are some tasks we are already working on to deal with this issue
16:27:44 <cohosh> we have been responding to this, there's now support for covertdtls in iptproxy: https://github.com/tladesignz/IPtProxy/issues/85
16:28:09 <cohosh> and i released a new version of snowflake yesterday with it set to randomizemimic by default
16:28:40 <cohosh> Shelikhoo[mds] made sure the docker image is updated
16:28:42 <dcf1> how nice to have the elements of a solution in the back pocket
16:28:55 <cohosh> yeah, really grateful for the work by theodorsm :D
16:28:58 <Shelikhoo[mds]> hahaha yes!
16:28:59 <theodorsm> :))
16:29:07 <Shelikhoo[mds]> yes thanks theodorsm !!!
16:29:29 <theodorsm> Hopefully it will bypass the block, but I am still very curious how they fingerprinted it
16:29:39 <theodorsm> @cohosh, have you taken a look at the pcaps?
16:30:02 <theodorsm> J4A fingerprint was mentioned by the reporter
16:30:09 <cohosh> i have, but without testing things actively it's hard to say what specifically is being used to fingerprint
16:30:25 <cohosh> other than likely something in the client hello
16:31:12 <theodorsm> Hmm, there was talk about a delay also, could that mean active fingerprint or just the DPI taking a bit of time
16:31:19 <Shelikhoo[mds]> yes, we need to replay/partial replay the traffic to triangulate exactly what was targetted
16:31:23 <cohosh> what i was able to confirm is just that the pion/dtls fingerprints were very static and consistently those connections were servered, but only after some application data was sent
16:31:41 <cohosh> *severed
16:32:40 <Shelikhoo[mds]> in theory if the censor was bidirectional, we might be able to test it without a vantage point in the affected network
16:34:13 <Shelikhoo[mds]> it would require a program to send udp packet with specific ttl and
16:34:33 <Shelikhoo[mds]> maybe packet capture to see icmp response
16:34:39 <cohosh> there was a report that suggested the fingerprinting is done dynamically if there's more than one simultaneous connection: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40529
16:35:00 <cohosh> we've had trouble reproducing it, but it could be that this type of blocking is regional
16:35:11 <theodorsm> @cohosh which ciphersuite was at the top of the cipher list for the blocked handshakes?
16:35:15 <cohosh> if this is what's happening, theodorsm's work will still help
16:35:47 <cohosh> theodorsm: let me check
16:36:55 <cohosh> always TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
16:37:04 <theodorsm> ok, tnx
16:38:01 <Shelikhoo[mds]> anything more we wish to discuss about this topic?
16:38:26 <cohosh> i have a todo to check with orbot on updating kindness mode
16:38:53 <cohosh> should we send an email to tor-relays@ asking proxy operators to update?
16:39:20 <cohosh> the docker image will take care of itself for docker users but there may be many operators who don't use that
16:39:39 <cohosh> well, for docker users who use some auto update tool i guess
16:39:40 <Shelikhoo[mds]> I think we could maybe send the email next week, considering most of the watch tower can run the update on its own
16:40:15 <Shelikhoo[mds]> so if the operator do check the snowflake version
16:40:31 <Shelikhoo[mds]> they can not only check if snowflake is updated and running correctly
16:40:42 <Shelikhoo[mds]> but whether the auto update is working
16:41:20 <Shelikhoo[mds]> since we have recently updated the docker compose file, we could use this chance to request operator to their their auto update setup as well
16:41:34 <Shelikhoo[mds]> * operator to check their their
16:41:52 <cohosh> ok and we can follow up about debian packaging next week too
16:41:54 <Shelikhoo[mds]> (but really that recent, but it is still worth checking)
16:43:09 <Shelikhoo[mds]> yes, although I don't think we need for wait for debian packaging before send the email
16:43:25 <Shelikhoo[mds]> since the debian packaging could sometime take years to update
16:43:42 <Shelikhoo[mds]> anyway, that is EOF from me about this topic
16:43:48 <Shelikhoo[mds]> the next topic is
16:43:49 <Shelikhoo[mds]> here is a interesting link:     https://www.internetsociety.org/resources/doc/2025/mandated-dns-blocking/
16:43:49 <Shelikhoo[mds]> "Mandated DNS blocking, often presented as a straightforward policy solution, is ineffective, harmful, and impractical. It is ineffective because it is easily circumvented by users and fails to remove targeted content, which simply reappears under new domain names. It is harmful because this blunt instrument cannot distinguish between lawful and unlawful material, leading to overblocking, fragmentation of the Internet’s global
16:43:49 <Shelikhoo[mds]> naming system, and the failure of interconnected services, including critical security protocols. Finally, it is impractical because the DNS is not bound by geography, meaning national blocking orders against global resolvers create unintended and widespread extraterritorial effects. Mandated blocking is the wrong tool for a role the DNS was never designed to play."
16:43:50 <cohosh> and again, really great work theodorsm, it's a very big deal that we are able to respond immediately to a change in our own settings and not have to manually figure out where the fingerprinting is happening and fix it
16:44:08 <Shelikhoo[mds]> Mandated DNS blocking, often presented as a straightforward policy solution, is ineffective, harmful, and impractical. It is ineffective because it is easily circumvented by users and fails to remove targeted content, which simply reappears under new domain names. It is harmful because this blunt instrument cannot distinguish between lawful and unlawful material, leading to overblocking, fragmentation of the Internet’s global
16:44:08 <Shelikhoo[mds]> naming system, and the failure of interconnected services, including critical security protocols. Finally, it is impractical because the DNS is not bound by geography, meaning national blocking orders against global resolvers create unintended and widespread extraterritorial effects. Mandated blocking is the wrong tool for a role the DNS was never designed to play.
16:44:18 <Shelikhoo[mds]> yes, thanks theodorsm again!!!
16:44:58 <SergioSantos> Sorry to interrupt. I wanted to ask something about a topic from the previous meeting. Is there any issue created so I can track "bloco" being added to the snowflake metrics ProxyType? Not urgent, just wanted to track it.
16:45:02 <theodorsm> thanks, happy to provide some resistance! ^^
16:46:05 <cohosh> SergioSantos: my bad, it slipped my mind to make an issue and assign myself, i will do that now
16:47:11 <SergioSantos> cohosh: thank you. I'm waiting for the Android app to be published on F-droid to call for testers in the Tor forums.
16:48:13 <cohosh> awesome
16:48:19 <theodorsm> @cohosh, just so I understood it correctly about the pcaps. Do the handshake complete, send some application data and then get blocked? Or does the CH get blocked immediately?
16:49:28 <Shelikhoo[mds]> cohosh: ^^^
16:50:08 <Shelikhoo[mds]> sorry for the ping, in the mean time, anything else we would like to discuss in this meeting?
16:50:17 <cohosh> SergioSantos: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40534
16:50:44 <cohosh> theodorsm: the handshake completes and some application data is sent in both directions
16:51:14 <cohosh> so i suppose it could be something other than the client hello, it's just that the pion/dtls client hello fingerprint consistently gets blocked and others don't
16:51:40 <cohosh> i haven't taken a look at the most recent shared pcaps
16:52:51 <Shelikhoo[mds]> thanks for the answer from cohosh to theodorsm !
16:52:56 <theodorsm> Hmm, it could be block due to the AES GCM nonce generation. Pion did it not according to best practice
16:53:04 <theodorsm> But we have changed it
16:53:19 <Shelikhoo[mds]> anything else we would like to discuss in this meeting?
16:53:40 <theodorsm> And the newest proxy versions of snowflake should have the proper nonce generation
16:53:43 <theodorsm> EOF
16:54:53 <Shelikhoo[mds]> #endmeeting