15:59:43 <cohosh> #startmeeting tor anti-censorship meeting
15:59:43 <MeetBot> Meeting started Thu Nov 18 15:59:43 2021 UTC.  The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:59:43 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:59:50 <cohosh> welcome!
15:59:56 <cohosh> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
16:00:17 <cohosh> please feel free to add items to the agenda and/or update us on what you've been up to :)
16:00:29 <meskio> hello
16:03:13 <cohosh> just a brief announcement: instead of doing a mailing list post, we put our latest monthly report on the new discourse forum: https://forum.torproject.net/t/anti-censorship-team-updates-from-september-and-october-2021/630
16:03:37 <shelikhoo> I have pasted my translated version of Chinese version of that tweet. It seems they have omitted some info in the English version.
16:04:00 <cohosh> or bi-montly report rather
16:04:25 <cohosh> idk if anyone reads these updates tbh, or if they are useful
16:04:38 <cohosh> please let me know if you know of a use-case where emails are still useful
16:04:47 <cohosh> shelikhoo: oh awesome, thanks!
16:05:26 <cohosh> shelikhoo: do you want to lead the discussion there?
16:07:10 <shelikhoo> no.... My attempt to reproduce this experiment is inconclusive. I would like to hear advice from tram members.
16:08:26 <meskio> I guess this could impact obfs4 private bridges
16:08:38 <cohosh> so if i understand correctly, @gfw_report is saying that they found evidence that random-looking obfuscation protocols are being blocked by the protocol level and not by endpoint
16:08:58 <cohosh> and that this blocking has been deployed only for traffic going to endpoints in some data centers
16:09:01 <arma2> in the past we've had people report this claim, and it turned out not to be dpi but still just endpoint blocking
16:09:20 <arma2> the feedback loop of "how come my connection doesn't work" is not easy
16:09:36 <cohosh> i am looking forward to the full report
16:09:54 <shelikhoo> There is already some discussion on issue with random like traffic
16:09:55 <shelikhoo> https://github.com/madeye/sssniff
16:09:57 <shelikhoo> like this one
16:09:59 <meskio> anyway I will be surprised they can actually block random trafic, I mean intermediate packages of https do look like random and will be impressive if they keep state of every tls handshake
16:10:23 * cohosh nods
16:10:43 <cohosh> i checked the tests we have running this morning
16:10:51 <meskio> they will need a huge DB just to know if this random package comes from a known protocol already seen or just out of the bloe
16:10:56 <cohosh> we are doing daily connections to a selection of obfs4 bridges, including private ones
16:11:16 <cohosh> and none of them appear to be blocked, but based on the whois data they are also not in these datacenters
16:12:16 <shelikhoo> There is report from V2Ray users that their VMess server get blocked. https://github.com/v2fly/v2ray-core/issues/1380(Chinese text)
16:12:37 <cohosh> meskio: yeah, i wonder if instead of trying to block all unknown protocols, it's a targeted attack against a few known circumvention tools?
16:13:28 <meskio> for that they will need to be able to fingerprint this circumvention tools
16:13:32 <shelikhoo> It is possible, so I will run Shadowsockets, VMess+TCP, alongside Random, HTTP server
16:13:34 <meskio> so they are not so random
16:13:37 <shelikhoo> to see the result
16:15:05 <cohosh> shelikhoo: good luck and i'm curious what you find
16:15:43 <cohosh> i'm wondering if it's a good idea to find some private obfs4 bridges running in these data centers and add them to our probes
16:16:58 <arma2> couldn't hurt. or do a test of every bridge in the 'unpublished' bucket and see what the pattern is.
16:18:00 <shelikhoo> unless they have discovered the probe machine and block every IP it connects...
16:18:15 <cohosh> yeah that's always a risk
16:21:07 <shelikhoo> I usually just create a new VPS for the experiment, and destroy it after the experiment
16:21:50 <cohosh> anything else we can/should be doing in the meantime other than trying to learn more about what is happening?
16:22:29 <cohosh> we have HTTPT in the pipeline as a not random looking PT that has a similar traditional bridge deployment scenario as obfs4
16:22:56 <arma2> the georgetown folks have also been working on an "obfs5" variant that expands traffic to have variable entropy
16:23:28 <shelikhoo> HTTPT should work, since WebSocket transport in V2Ray is working
16:23:51 <cohosh> yeah, i guess the main question is whether this is enough info to move deploying a replacement to obfs4 up in our roadmap
16:24:08 <arma2> cohosh: definitely no. let's wait until somebody gives us very solid concrete details.
16:24:30 <arma2> we've had this sort of report maybe 5 or 10 times before, and it never really turns out to be true
16:24:48 <arma2> i guess more of the internet is using look-like-nothing transports now than before, so eventually china will do something about it
16:25:11 <arma2> so i don't want to declare that it must be wrong this time. but, definitely too early to change roadmaps. :)
16:25:28 <cohosh> makes sense
16:26:14 <cohosh> any more on this topic before we move on to the next?
16:26:31 <shelikhoo> no...
16:26:48 <cohosh> ggus: i think that next point is yours?
16:26:57 <cohosh> or maybe meskio?
16:27:05 <meskio> it was mine
16:27:13 <meskio> but yes, is about the campain ggus  is running
16:27:22 <meskio> https://blog.torproject.org/run-a-bridge-campaign/
16:27:25 <meskio> pretty cool
16:27:46 <cohosh> oh wow i love the happy onions on the bridge XD
16:27:48 <meskio> it did motivate me to run some bridges and see how does it feel
16:27:58 <meskio> yes, the picture is soo nice
16:28:15 <ggus> sorry, i'm at another meeting now :(
16:28:27 <meskio> is fine we are just prissing you
16:28:42 <meskio> setting up the bridges did bring me some questions
16:28:58 <meskio> that might trigger some improvements in documentation
16:29:27 <meskio> one is about ports, did I hear is more useful to run the bridge in port 443 or 80 as it will not be blocked in many networks?
16:29:35 <meskio> do we want to recommend that somehow?
16:29:48 <meskio> is there other ports that are useful?
16:29:59 <arma2> i think for obfs, using a high numbered port makes more sense than 443 or 80
16:30:05 <arma2> since "443 or 80" and "really random" is a weird combo
16:30:09 <cohosh> i think 443 and 80 ports are also useful for users who have restrictive firewalls for outbound traffic
16:30:28 <arma2> also, i am curious if we've solved "get obfsproxy to bind to low port" on debian properly
16:30:34 <cohosh> like "block everything but HTTP traffic" for example
16:30:42 <arma2> e.g. by setting up capabilities
16:30:52 <arma2> but yes, there are definitely users who can only reach 80 and 443 still
16:31:07 <meskio> I'm using capabilites to run the docker image without root permitions
16:31:45 <arma2> meskio: more generally, i've been wanting somebody like duncan to walk through the ux of setting up a bridge, and figure out where the stop points are
16:31:59 <arma2> so please grab your experience, and talk to duncan and nah and see if they can be helpful
16:32:18 <meskio> sure, I can talk with them
16:32:37 <meskio> is a bit hard to improve the doc, as there is one documentation per distro
16:32:51 <arma2> that itself is a bug that we should consider how to fix, imo
16:32:53 <meskio> so things like preferred ports will require modifing everything
16:33:14 <arma2> the relay / bridge guides are a strange maze of variations on the same text
16:33:41 <arma2> maybe that is the best possible situation, or maybe there is room for improvement :)
16:34:21 <meskio> also there are two ports to consider, the OR_PORT and the PT_PORT, but AFAIK users only use the PT_PORT isn't it? so this is the port that actually matters
16:34:52 <arma2> correct. except for the bug (design flaw) where the ORPort needs to be reachable still too.
16:35:05 <arma2> https://gitlab.torproject.org/tpo/core/tor/-/issues/7349
16:35:11 <meskio> yes
16:35:42 <meskio> anyway, we don't have a preferred port, so maybe the documentation is fine and is good to let the operator to pick whatever they prefer
16:36:13 <cohosh> thanks for going through this process meskio
16:36:39 <cohosh> it's very useful to hear where confusion and pain points are
16:37:01 <meskio> another question I have is about the blog post, it says "don't host more than two bridges in one IP address"
16:37:23 <meskio> what will be the usecase for hosting more than one? tor being single threaded and use the CPU better?
16:37:33 <meskio> or censors blocking per port instead of IP?
16:37:53 <arma2> i think gus just didn't want people to run ten bridges on one computer and earn all the goodies
16:37:58 <cohosh> i think both of those make sense
16:38:07 <arma2> sometimes china has blocked only by ip:port,
16:38:14 <arma2> sometimes they have blocked by blackholing the whole ip address
16:38:34 <arma2> i don't remember which one they're doing this year
16:38:42 <arma2> maybe shelikhoo knows :)
16:39:01 <meskio> the problem of two in one IP is that if they get into different pools and one of the pools is discovered both might be blocked at once
16:39:09 <arma2> right
16:39:12 <shelikhoo> For this year, automatic block is typically conducted by blocking the port
16:39:33 <shelikhoo> and any confirmed proxy is blocked by ip
16:39:40 <arma2> hm!
16:39:42 <meskio> nice, then is not so bad to host two in one IP (for now)
16:39:52 <arma2> so they would start blocking by ip:port and then...at some point they would block the whole IP?
16:40:09 <arma2> how do they do the 'confirmed' step?
16:40:34 <shelikhoo> no... I think china block obfs4 bridges by getting more proxy by request it from different ip
16:40:43 <shelikhoo> so it is confirmed proxy
16:40:58 <shelikhoo> of the 3 proxy I got for my ip
16:41:07 <shelikhoo> 2 of them is blocked by ip
16:41:17 <arma2> ok. so when they fetch them from bridgedb, they block them by ip
16:41:29 <shelikhoo> This is my guess
16:41:33 <arma2> and in that case, meskio's point is a good one, which is that one bridge per ip address is best
16:41:40 <arma2> not just to spread out the addresses better,
16:41:54 <arma2> but it's also a good example of how one of the bridges can put the other bridge at risk
16:42:09 <shelikhoo> actually we can try to host some IPv6 bridge
16:42:21 <arma2> similar to how we stopped giving out the vanilla bridge line for an obfs4 bridge, because when we did that, you could block the bridge by whichever protocol is weaker
16:42:27 <shelikhoo> it is said that china is yet to have any block by ip for ipv6
16:42:55 <cohosh> oh interesting
16:42:55 <meskio> bridgedb is not distributing obfs4 ipv6 bridges
16:43:13 <meskio> I mean the other way around, sorry
16:43:14 <shelikhoo> and there is a some of chinese ISP provide IPv6 access
16:43:24 <arma2> i *think* that an ipv6 obfs4 bridge ought to work these days, in tor browser. somebody should get one and test it.
16:43:33 <shelikhoo> no i am not talking about bridgedb
16:43:41 <meskio> the bridge authority doesn't provide info if an obfs4 transport is available over ipv6
16:43:47 <meskio> it does for vanilla proxies
16:43:55 <meskio> but in the transport line there is never info about ipv6
16:44:18 <meskio> I was checking it last week and surprised about that
16:44:20 <shelikhoo> it is just firewall don't block any ipv6 address yet
16:44:49 <cohosh> meskio: we have a few ipv6 bridges in bridgedb
16:44:55 <meskio> vanilla bridges
16:44:59 <meskio> non obfs4 ones
16:45:01 <cohosh> aha yeah
16:45:07 <shelikhoo> I can try if these bridge works later
16:45:15 <meskio> the file format doesn't have a field for ipv6
16:45:16 <cohosh> we really need to fix that
16:45:33 <meskio> we could guess the ipv6 from the vanilla configuration
16:45:36 <meskio> and assume is the same port
16:45:41 <meskio> but doesn't need to be
16:46:01 <meskio> many vanilla bridges have different port for ipv6 than for ipv4, not sure why
16:46:22 <arma2> meskio: i think people might pick the ports manually
16:46:47 <arma2> but yes, all of this is a topic that somebody should grab and run with and see where you get. ipv6 has not been well supported or had much attention from us, so there is much to do.
16:46:53 <cohosh> the vanilla config is also the OR port, which is distinct from the public facing obfs4 port
16:47:35 <meskio> yes, what I mean is the vanilla config does contain an IPv6 and IPv4 for many bridges
16:48:06 <meskio> we could guess that the IPv6 published in the OR port part will work for obfs4, but that is an assumption
16:48:37 <cohosh> hmm yeah sounds like a good place to start
16:48:42 <meskio> anway, I thought about opening a ticket but somehow got out of my pile of things to do, now that I see it might matter I will open the issue and see if we can move it forward
16:48:53 <cohosh> thanks!
16:49:24 <arma2> ipv6 has been a great idea for a long time. many countries buy western censorship tools, for example for a long time iran used the same tools for censorship as western companies use for their own corporate censorship,
16:49:38 <arma2> and if those corporations don't have ipv6, then the censorship boxes never build ipv6 censorship, and then it turns out iran doesn't get it either
16:50:57 <shelikhoo> Because there is so many IPv6 address, blocking individual ip address is not that feasible
16:51:16 <cohosh> this is the core tor issue: https://gitlab.torproject.org/tpo/core/tor/-/issues/11211
16:52:14 <cohosh> and a historical anti-censorship team issue: https://gitlab.torproject.org/tpo/anti-censorship/bridgedb/-/issues/26542
16:53:21 <meskio> nice, I guess the question is, do we care to ask the network team to prioritize tor#11211 or are we ok with the status quo?
16:53:54 <meskio> I see my docker autogenerated torrc config and my bridges only listen in IPv4 space
16:53:56 <arma2> an earlier step might be: see if an ipv6 obfs4 bridge still actually works in tor browser
16:54:55 <meskio> so my proposal of guessing the IPv6 from the vanilla config might not work as I don't think obfs4 bridges will be listening in IPv6 too as the 0.0.0.0 is in the config (I could test it)
16:55:57 <meskio> arma2: I did grep over the cached-extrainfo file in polyanthum and there is no single IPv6 obfs4 bridge there
16:56:03 <arma2> and speaking of prioritizing 11211 vs 7349 vs others, maybe the initial answer is to get a list somewhere of which tickets we're hoping network team will do, and why, and then we can periodically triage them to see if we've started caring more about particular ones
16:56:19 <arma2> meskio: yep, you'd have to do one manually i think
16:56:24 <arma2> maybe an iptables redirect or something
16:56:32 <arma2> and then see if it works or if it breaks
16:56:56 <shelikhoo> A simpler step will be setup a public IPv6 obfs4 bridge and see if it can still work after a while
16:57:08 * arma2 realizes it's still the anti-censorship-team-meeting and it's 57 minutes after the hour
16:57:23 <arma2> did we have other things on the topic list or was this it :)
16:57:42 <cohosh> yeah i think we're at the end of the agenda
16:57:52 <arma2> whew
16:57:55 <cohosh> anything else before we close the meeting?
16:58:11 <meskio> I'm good
16:58:23 <shelikhoo> no....
16:58:27 <meskio> it did open a lot of more questions in my head
16:58:31 <arma2> meskio: i think it would be great to get some "big picture" view of which tickets we're hoping network team will do, and what each of them is blocking
16:59:01 <arma2> at first i was thinking a gitlab label would do it, but that doesn't have the organization to it
16:59:04 <cohosh> arma2: yes we have a labelling system for that
16:59:23 <cohosh> i just commented on the ticket how to get the right label on it
16:59:50 <arma2> yes but i think that is a different thing
16:59:54 <arma2> that is "hello this ticket should be on the list"
17:00:13 <arma2> but then, the list itself would be not just a pile of ticket numbers, but an organized described set of what we need, why, etc
17:00:30 <arma2> maybe that is overkill. but i feel like it is a thing we're missing
17:01:34 <meskio> I'll be happy to help triagging, but I'm not sure I have the big picture (yet) to leed that work
17:01:39 <meskio> s/leed/lead/
17:02:01 <cohosh> arma2: you're welcome to write this :) it sounds like maybe more planning work than is necessary
17:02:37 <cohosh> what's the goal? to convince the network team what they should choose next?
17:02:47 <cohosh> or to figure out our own internal prioritization?
17:03:13 <meskio> become a lobby!!!
17:03:29 <arma2> the latter
17:03:39 <arma2> or just to know what we're missing and what we're waiting on
17:03:55 <arma2> and why and what we're missing while waiting
17:05:04 <cohosh> okay yeah our documentation can always use work
17:05:25 <cohosh> for now i moved forward giving it the right labels
17:06:10 <cohosh> i'll think a bit about how to make our team documentation and roadmaps more legible :)
17:06:21 <cohosh> but for now i think we can end the meeting for today
17:06:45 <cohosh> #endmeeting