16:00:08 <onyinyang> #startmeeting tor anti-censorship meeting
16:00:08 <MeetBot> Meeting started Thu Sep 25 16:00:08 2025 UTC.  The chair is onyinyang. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:08 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:08 <onyinyang> hello everyone!
16:00:08 <onyinyang> here is our meeting pad: [https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469](https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469)
16:00:12 <Shelikhoo[mds]> hi~hi~
16:01:18 <cohosh> hi
16:03:05 <onyinyang> We don't have anything in our agenda this week XD
16:03:20 <Shelikhoo[mds]> EOF, I don't have any topic to suggest
16:03:32 <onyinyang> Do we want to set a date for the next reading group while we're here?
16:03:37 <dzwdz> i can talk some more about dual-stack bridge stuff
16:03:49 <dzwdz> there are a few small issues
16:03:56 <dzwdz> sorry for barging in lol
16:03:59 <onyinyang> ah ok, sure. go ahead dzwdz
16:04:17 <onyinyang> though meskio is away today
16:04:27 <dzwdz> i'm in a car rn, hopefully my connection won't drop out
16:04:36 <onyinyang> I'm not sure who are the most relevant people to be part of this discussion
16:05:08 <dzwdz> we've switched Serge to not test reachability so its opinion about the Running flag is useful again, and i wanted to get to work on onionoo and metrics
16:05:12 <dzwdz> to properly show reachability data
16:05:44 <dzwdz> but i've realized the data bridgestrap send to collector is incorrect for bridges with multiple transports
16:06:21 <dzwdz> it shouldn't be too hard to fix but it's also an opportunity to rethink how it should handle bridges with multiple transports
16:06:59 <dzwdz> and on that note i've been thinking about bridges with e.g. obfs4 on multiple IPv4 addresses
16:07:22 <dcf1> I see, so it could be possible for a single bridge fingerprint to be "Running" with respect to one transport and not "Running" with respect to another transport.
16:07:25 <dzwdz> because some providers give you extra ips for free, so it'd be nice to use that
16:07:27 <dzwdz> dcf1: yup
16:07:54 <dzwdz> it would probably be best not to reveal how many IPs (of the same address family) a transport is listening on?
16:08:49 <dzwdz> i was thinking that for each transport & address family pair we could output a boolean saying if all of these were reachable
16:09:08 <dzwdz> so e.g. if one of your IPs is down you just get false with no extra detail
16:09:36 <dzwdz> it could say "1 out of 2 IPv4 obfs4 transports are reachable" but you'll need to check them all anyways so it's kinda useless
16:09:48 <dcf1> dzwdz: unless I'm mistaken, it's not possible to configure the same transport multiple times in the same instance of Tor. The PT protocol would permit it, but torrc syntax does not allow it, because things like ServerTransportListenAddr are keyed by a transport name.
16:10:01 <dzwdz> right now it's impossible, yup
16:10:06 <dcf1> There's an implicit assumption in torrc that any bridge runs at most one instance of each named transport.
16:10:16 <dzwdz> which would also be nice to change
16:10:20 <dcf1> yes!
16:10:25 <dzwdz> it would be good to use separate obfs4 keys for each address, for example
16:10:50 <dzwdz> otherwise censors with a bunch of IPv4 bridgelines could probe suspected IPv6 bridges with the keys from these bridgelines
16:11:37 <dcf1> so at any rate, at the current moment, if a single host is running multiple instances of the same transport, that's actually going to be multiple instances of tor with different fingerprints, and hence distinct bridges as far as the network is concerned.
16:12:04 <dzwdz> depends
16:12:11 <dzwdz> you can have a single transport listening on multiple IPs
16:12:16 <dzwdz> which is already the case for dualstack bridges
16:13:02 <dzwdz> it would be easy to let tor publish more than one IP address per family for a single transport but that's a half-solution
16:14:21 <dcf1> "censors could probe" the repository wangmeiqi/obfs4_verify in the Geedge leak is a rudimentary tool that probes for obfs4 support, given a bridgeline
16:14:26 <dcf1> https://geedge-git.haruue.com/mesalab_git/wangmeiqi/obfs4_verify.git
16:14:30 <dcf1> https://github.com/net4people/bbs/issues/519#issuecomment-3289654410
16:15:22 <dzwdz> i think that's pretty much it from me? i wasn't really prepared i just saw that there's a meeting going on
16:15:36 <cohosh> dzwdz: thanks for bringing it up
16:15:40 <dzwdz> i'm mostly blocked by the bridgestrap issue
16:15:47 <dzwdz> i could get a patch going but i don't know if we want to change the format or not
16:16:12 <dcf1> dzwdz: btw here's an issue about multiple ServerTransportListenAddr per transport: https://gitlab.torproject.org/tpo/core/tor/-/issues/11211
16:16:55 <dzwdz> actually, is there a formal process i should follow to send a proposal to change the format of bridgestrap-status?
16:16:57 <dzwdz> like with spec proposals
16:17:39 <dzwdz> oh, sidenote
16:17:50 <cohosh> dzwdz: there is a repository for spec proposals, mostly used by the network team: https://gitlab.torproject.org/tpo/core/torspec/
16:17:58 <dcf1> actually I was mistaken in what I said earlier, apparently it is also a limitation of the PT protocol that you can't configure more than one instance of the same transport name https://gitlab.torproject.org/tpo/core/tor/-/issues/11211#note_2762831
16:18:21 <cohosh> it's been awhile since i looked at bridgestrap, but i would suggest writing up the proposal in the issue you created
16:18:29 <dzwdz> yeah, i did look at that and i think i have a rough plan for how this could be done without breaking compatibility
16:18:39 <cohosh> https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/48
16:18:47 <dzwdz> i also saw that there's a v2 and v3 PT spec outside of tor
16:18:50 <dzwdz> and i'm very confused about it
16:19:04 <onyinyang> dzwdz, yeah, I was going to suggest what cohosh said
16:19:24 <dzwdz> ok
16:19:33 <cohosh> i haven't been actively involved in bridgestrap for a while
16:19:49 <Shelikhoo[mds]> realistically I think it would be easier to aim at get things done at arti for running more than one transport of the same kind
16:20:00 <cohosh> so it might be best to wait for meskio's input
16:20:04 <Shelikhoo[mds]> I think it would be quite hard to get such changes into C-Tor
16:20:35 <Shelikhoo[mds]> but it would take a few years before Arti support server side things
16:21:11 <cohosh> but from my first read, the changes to bridgstrap-stats seem reasonable and wouldn't be too difficult to do
16:21:41 <dzwdz> i mean i'm already trying to get a bunch of stuff merged into c-tor
16:22:22 <Shelikhoo[mds]> yes, cohosh I was not commenting about bridgestrap-stats but torrc and pt spec changes
16:22:54 <cohosh> Shelikhoo[mds]: oh yeah i know, i was just continuing my thought
16:23:13 <Shelikhoo[mds]> yes.. sorry for the interruption
16:23:19 <dzwdz> if all we want is different obfs4 keys per IP
16:23:37 <dzwdz> then we can get by with one obfs4 instance
16:24:03 <dzwdz> we'd need to allow passing multiple bind addresses, then it would choose a different key for each address it binds to
16:24:09 <dcf1> different obfs4 keys per IP is probably universally solved currently just by running multiple copies of tor. I'm sure that's how everyone who wants that does it.
16:24:31 <dzwdz> people don't really do that currently
16:24:43 <dzwdz> there was a thread on tor-relays@ (i think) recently about someone wanting to run obfs4 on an alternate IP
16:24:51 <dzwdz> behind NAT, which is what you get on DO
16:24:52 <dzwdz> it went nowhere
16:25:13 <dcf1> But they do, right? Like there was not so long ago a change in the limit on the number of relays per IP address, that only matters for people who run multiple tor instances.
16:25:36 <dzwdz> they run them to make better use of available bandwidth etc
16:25:47 <dzwdz> i would assume the VPSes used for bridges are usually pretty weak
16:26:02 <dcf1> Running multiple instances of tor has more to do with CPU than with bandwith.
16:26:18 <dcf1> It's a technical workaround for the limitation of C-tor being single-threaded.
16:26:25 <dcf1> https://www.bamsoftware.com/papers/pt-bridge-hiperf/#tor
16:26:37 <dcf1> "A single Tor process is limited to one CPU core: once Tor reaches 100% CPU, the performance of the bridge is capped, no matter the speed of the network connection or the number of CPU cores to spare."
16:26:48 <dzwdz> also people might want to run a single bridge on a /lot/ of IPs
16:26:58 <dzwdz> they might have a large ipv6 subnet available or something
16:27:07 <dcf1> Maybe it doesn't happen so much with bridges, but certainly it's something that relay operators do.
16:28:11 <dcf1> I'm not disagreeing with you that it would be better if the spec and configuration files permitted more general configurations, just saying that for the narrow use case of running multiple copies of obfs4 with the different obfs4 certs there's already a compatible workaround.
16:28:45 <dzwdz> i was thinking about this in the context of using the ipv6 subnets assigned to you too
16:28:49 <dzwdz> you might want to listen on 100, 200 ips
16:29:01 <dzwdz> ignoring the fact that this wouldn't be a good idea right now
16:29:04 <dcf1> (Actually I'm recalling there is a minor bandwidth-related technical reason, which has to do with some relays doing anti-DDoS defenses that limit traffic per IP address.)
16:29:34 <dzwdz> i assume censors right now only block a /128 at a time
16:30:03 <dcf1> hmm, I don't know offhand of evidence either way, but don't rely on that assumption too much
16:30:18 <dcf1> even e.g. spam blacklists block /64 without remorese.
16:30:26 <dzwdz> figuring out the correct subnet size to block for each provider would be extra work for them
16:30:39 <dzwdz> my connection is getting really bad :(
16:30:50 <dzwdz> there are providers which give you more than a /64
16:32:59 <dcf1> that doesn't really matter from a collateral damage perspective; a censor can then still safely block a /64 at a time. What would matter is if it's common for providers to give *less* than a /64, because then blocking a /64 might result in overblocking of something important in an adjacent network with different ownership (or might not).
16:33:40 <dcf1> Censors aren't trying to limit the number of IP addresses they block, in general: they're trying to limit the number of high-important (to them) services that get collaterally blocked.
16:33:44 <dzwdz> what i meant is that in this case you could run your transport on a bunch of addresses in e.g. your /56
16:33:58 <dzwdz> even if the censor blocks a few /64s, you'd still have a bunch more left up
16:34:03 <dcf1> yes, I'm with you on that.
16:34:48 <dzwdz> but i think it's also common for providers to give you less
16:34:53 <dzwdz> lemme open up DO, one sec
16:35:23 <dcf1> that's not necessary, I think I understand you fully
16:35:41 <Shelikhoo[mds]> the minimum bgp announcement prefix for ipv6 is /48.... so blocking /64 would limit damage to a single vps provider
16:35:45 <dcf1> just cautioning not to rely on intuition on censor behavior when thinking about possible defenses
16:36:26 <cohosh> dzwdz: just to make sure we don't block you on the bridgestrap stuff...
16:36:34 <Shelikhoo[mds]> but I think in most region block are based on singular ip rather than prefix
16:36:38 <cohosh> i read https://gitlab.torproject.org/tpo/anti-censorship/bridgestrap/-/issues/48
16:36:45 <dzwdz> i mean they do need to figure out a safe prefix size to block per provider
16:37:01 <cohosh> and the first suggestion of making the result an all or nothing thing sounds correct and it's a self-contained change in bridgestrap
16:37:08 <Shelikhoo[mds]> notable region to block by network block is Turkmenistan
16:37:11 <cohosh> i think it's safe to move forward with making a MR if you're up for it
16:37:15 <dcf1> btw here's an issue about the bandwidth-related reason for multiple IP addresses. Though in this case it's the source address of *outgoing* traffic, not listening addresses. https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40223
16:37:25 <dzwdz> i don't think saying that this is extra work for them requires intuition
16:37:39 <dcf1> "they do need to figure out a safe prefix size to block per provider" my guess is that this is false
16:38:09 <dzwdz> why?
16:38:29 <dcf1> it depends on what you mean by "safe". "Overblocking", for a censor, doesn't mean just that they blocked more IP addresses than they need to -- it means they accidentally block something *important* to them.
16:38:53 <dcf1> If they "overblock" a bunch of empty address space, they won't care about that at all.
16:39:01 <dzwdz> so they can't block /64s, because IIRC DO gives you less than that
16:39:20 <dzwdz> so the only safe one without doing extra research is /128
16:39:24 <dcf1> They'll only go to the trouble of minimizing address ranges if they find that whatever their current policy is actually results in important things getting collaterally blocked.
16:39:52 <dzwdz> cohosh: and how about the format changes? because depending on that i'll do very different things in onionoo and metrics
16:40:03 <dcf1> "they can't block /64s, because IIRC DO gives you less than that" if they block 10 DO customers while intending to block only 1, that's not a problem, unless one of those other 9 customers was providing something of high value.
16:40:18 <dzwdz> ah, that's what you mean
16:40:27 <dzwdz> sure
16:41:05 <dcf1> but as I say, offhand I don't know of research or evidence on the size of IPv6 address range blocking
16:41:37 <dzwdz> re: bridgestrap - the format of data returned by onionoo will be different depending on the data i get from bridgestrap, and that in turn changes how i will display it
16:42:12 <cohosh> dzwdz: for the format changes, i would suggest specing out what those would look like more precisely and the changes they'd require in onionoo and metrics so that meskio and someone from the metrics team can review it and discuss
16:42:42 <cohosh> i see your proposal there, but following up on what exactly it might break would help move the discussion a long
16:42:46 <dzwdz> okay
16:42:57 <cohosh> and thanks for your attention to this
16:42:59 <dzwdz> and i should do that in the issue, right?
16:43:06 <cohosh> yeah the issue is a good place for now
16:43:38 <dzwdz> will do
16:43:42 <dzwdz> eof from me, then
16:44:08 <onyinyang> coool, thanks for all your work on this so far dzwdz :D
16:44:34 <Shelikhoo[mds]> yes, thanks dzwdz!
16:44:53 <dzwdz> :)
16:45:26 <onyinyang> so back to my earlier question, at our last reading group we sort of discussed making The Internet Coup the next reading group item. Do we want to do that?
16:45:42 <onyinyang> maybe on the 16th or 23rd?
16:45:58 <Shelikhoo[mds]> either time would work for me
16:46:01 <cohosh> same here
16:46:42 <onyinyang> hmmm ok, let's say the 23rd
16:47:18 <Shelikhoo[mds]> nice!
16:47:20 <Shelikhoo[mds]> EOF
16:47:47 <onyinyang> Oh, I guess it's just one specfic section that we identified: Blocking ONline Privacy And Circumvention Tools on page 56
16:49:16 <onyinyang> Though, the whole report is probably not as dense as some of the papers we typically have for reading group.
16:50:00 <dcf1> yeah just read the whole thing I would suggest
16:50:05 <onyinyang> so I'll say, the whole report, with particular emphasis on that section
16:50:12 <onyinyang> sounds good
16:50:18 <dcf1> my notes and highlights are https://github.com/net4people/bbs/issues/519#issuecomment-3282101626
16:50:25 <onyinyang> Thanks for that dcf1
16:51:35 <onyinyang> ok that's it for this week!
16:51:46 <onyinyang> #endmeeting