16:00:13 <meskio> #startmeeting tor anti-censorship meeting
16:00:13 <MeetBot> Meeting started Thu Oct  9 16:00:13 2025 UTC.  The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:13 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:15 <meskio> hi everyone!
16:00:17 <meskio> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:00:19 <meskio> ask me in private to give you the link of the pad to be able to edit it if you don't have it
16:00:21 <meskio> I'll wait few minutes for everybody to add you've been working on and put items on the agenda
16:01:39 <cohosh> hi
16:01:48 <meskio> I was wondering if I was alone :)
16:02:09 <meskio> hehe
16:03:08 <cohosh> there's always MeetBot XD
16:03:30 <meskio> yes, but is kind of a cold entity
16:03:55 <meskio> should we start with the CDN77 blocking?
16:04:14 <cohosh> yeah we have a few updates
16:04:36 <Shelikhoo[mds]> hi~hi~
16:04:43 <cohosh> nina13[mds] opened https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40067 yesterday
16:05:16 <cohosh> and included some OONI data that suggests our phpmyadmin front for CDN77 has some anomalies in Belarus
16:05:31 <cohosh> https://explorer.ooni.org/chart/mat?test_name=web_connectivity&axis_x=measurement_start_day&since=2024-10-08&until=2025-10-09&time_grain=day&probe_cc=BY&domain=www.phpmyadmin.net
16:06:02 <cohosh> we've made a few changes that were shipped in the most recent stable release of Tor Browser
16:06:09 <cohosh> which went out two days ago
16:07:21 <Shelikhoo[mds]> nice!
16:07:24 <cohosh> those changes are that the moat settings (which include Connect Assist and bridge requests)
16:07:32 <cohosh> have been udpated to use netlify
16:07:37 <cohosh> https://gitlab.torproject.org/tpo/applications/tor-browser/-/merge_requests/1539
16:07:41 <meskio> is it?
16:07:47 <meskio> because this merge request was for alpha
16:08:28 <cohosh> yeah i asked the applications team and they marked for stable
16:08:35 <cohosh> i don't know how that is tracked in gitlab
16:08:43 <meskio> ahh, cool
16:08:44 <cohosh> but i use alpha so I haven't confirmed that
16:09:03 <cohosh> we also updated the snowflake bridge line to use netlify
16:09:21 <cohosh> i talked with meskio yesterday about our netlify transfer and request limits
16:09:23 <meskio> AFAIK I told them to push it into TB 15, that should be released later this month
16:09:31 <Shelikhoo[mds]> we should monitor the usage meter at netlify
16:09:35 <cohosh> ah okay someone should check then
16:09:45 <cohosh> but i think i asked them to backport it
16:09:47 <meskio> but that was months ago
16:09:54 <meskio> ok, then is probably there, thanks
16:10:05 <meskio> so now we might be using netlify for both
16:10:16 <meskio> we'll need to keep an eye to the free account limits
16:10:24 <meskio> Shelikhoo[mds]: are those in different accounts?
16:10:37 <cohosh> about the limits: we were concernted because i looked up the snowflake https-count metrics yesterday and there are close to 4 million domain fronting rendezvous per day
16:10:40 <Shelikhoo[mds]> they are different projects in the same accout
16:10:43 <Shelikhoo[mds]> account
16:10:56 <cohosh> but then i realized that orbot are probably the majority of our snowflake users
16:10:58 <meskio> ok, so if they get blocked both gets blocked at once
16:11:18 <meskio> I think we should keep one of them in CDN77 and diversify our domain fronting
16:11:20 <Shelikhoo[mds]> if the account get closed, then yes
16:11:22 <cohosh> and i don't know how aggressive thye are with pulling the latest builting in bridge lines from https://bridges.torproject.org/moat/circumvention/builtin
16:11:52 <meskio> (I've seen tons of requests comming to that endpoint, but AFAIK TB doesn't use it)
16:12:01 <meskio> so some other client is pulling that endpoint
16:12:07 <meskio> is the one with more requests
16:12:21 <cohosh> yeah i agree that it would be good to stick with cdn77 once we find new fronts that work in most places
16:12:38 <cohosh> (for snowflake)
16:12:55 <Shelikhoo[mds]> in any case I have deployed the fronting domain probing on vantage points
16:13:21 <cohosh> let's track the tests in https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/168 and have a  buliting cdn77 bridge line by the end of october 15.0 Tor Browser release?
16:13:21 <meskio> I agree, we can try to keep moat in netlify and use CDN77 for snowflake
16:13:26 <Shelikhoo[mds]> I can have bring the result to next week's meeting
16:13:44 <cohosh> Shelikhoo[mds]: that would be awesome, thanks!
16:13:54 <meskio> thanks Shelikhoo[mds]
16:13:54 <Shelikhoo[mds]> hehe!
16:14:05 <Shelikhoo[mds]> no problem!!!
16:15:23 <cohosh> i think that's all the updates i have, onyinyang have you heard back from the community team on the forum post?
16:16:37 <meskio> mmmm, maybe onyinyang is not around
16:16:48 <cohosh> okay i'll follow up with her after the meeting
16:17:01 <meskio> cool, thank you for putting some head to it
16:17:01 <nina13[mds]> I asked some users to test snowflake bridges from the post in Russia - bridges do work
16:17:09 * onyinyang is lurking 👀
16:17:09 <meskio> nice
16:17:18 <cohosh> nina13[mds]: that's great, thanks!
16:17:18 <meskio> maybe we should go life with it?
16:17:25 <cohosh> yeah let's do that :)
16:17:40 <meskio> onyinyang: do you want to do the honors?
16:17:48 <meskio> (do that sentence work in english?)
16:17:55 <onyinyang> I made the post public in the forum, ggus had some comments
16:17:57 <cohosh> it does :D
16:18:07 <meskio> ahh, wow, sorry I didn't follow up
16:18:09 <meskio> thanks
16:18:50 <onyinyang> https://forum.torproject.org/t/snowflake-and-conjure-inaccessible-due-to-cnd77-blockage-try-this-workaround/20650
16:18:55 <Shelikhoo[mds]> nice!
16:19:03 <onyinyang> there hasn't been a whole lot of reaction to it though
16:19:17 <cohosh> onyinyang: awesome, thanks!
16:19:50 <onyinyang> :D
16:20:05 <Shelikhoo[mds]> maybe if it perfectly working no one need to send a feedback
16:20:15 <meskio> <3
16:20:35 <onyinyang> hehe, hopefully Shelikhoo[mds]
16:20:51 <Shelikhoo[mds]> hehe!
16:21:05 <meskio> anything more on this topic?
16:21:15 <Shelikhoo[mds]> EOF from me
16:21:23 <meskio> I guess we can move to the next one
16:21:48 <meskio> you might recall we are keeping go 1.22 in our PT clients
16:22:02 <meskio> that is needed for old versions of OSX, wich are supported by firefox
16:22:27 <meskio> I missunderstood the applications team, and thought that we could stop supporting it for TB 15 (about to be released)
16:22:45 <meskio> but this is not true, TB 15 will keep needing it
16:23:10 <meskio> so we need to maintain go 1.22 for another 6 months at least, and depends on the deprecation of OSes from firefox
16:23:32 <cohosh> hm
16:23:42 <meskio> Shelikhoo[mds] has being doing a nice work of backporting security patches for go 1.22, as golang standar library doesn't support that version anymore
16:23:43 <cohosh> i keep forgetting about that
16:24:18 <meskio> there is the posilibity of disabling PTs in affected OSes, but will be nice if we don't do that
16:24:24 <Shelikhoo[mds]> yes, I was hoping that there will be less need for such backporting
16:24:57 <Shelikhoo[mds]> but in the meanwhile it doesn't hurt for us to pin the version for a little longer
16:25:51 <meskio> I hope we don't need to backport many more
16:26:29 <meskio> anyway, let's keep an eye to this and revisit it if it becomes a problem
16:26:46 <Shelikhoo[mds]> yes, another option is to patch the golang toolchain
16:27:00 <Shelikhoo[mds]> to make it support more version of operating systems
16:27:28 <Shelikhoo[mds]> but for obvious reason we are kind of avoiding it
16:28:31 <meskio> yes, that sounds like some work, let's hope we don't need it
16:28:48 <meskio> this is all from my side on this
16:29:27 <cohosh> i just realized that i removed the go-1.22 target for our gitlab CI
16:29:28 <cohosh> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/70a6b134a71c34c48f1a10d1bb3ff262cf2d0b6b/.gitlab-ci.yml#L151
16:29:38 <cohosh> but i can add it back in for just client builds
16:29:51 <cohosh> (we had a security patch for the snowflake server that required a go version update)
16:30:06 <meskio> that is a good idea, let's make sure the client keeps building with 1.22
16:30:14 <cohosh> that might be a good idea so we don't accidentally merge KCP updates that won't build for clients
16:30:18 <Shelikhoo[mds]> EOF from me as well, we might want to add go1.22 verifyit to lyrebird instead
16:30:29 <meskio> because having a newer version on the go.mod we might not notice if we break it
16:30:34 * cohosh makes an issue now
16:31:07 <Shelikhoo[mds]> okay, having this test on snowflake can help us discover issue earlier
16:31:30 <meskio> Shelikhoo[mds]: not sure I understand what you mean about lyrebird
16:31:45 <meskio> go.mod in lyrebird is pin to 1.22
16:32:17 <Shelikhoo[mds]> yes! sorry I was thinking we need to make sure it lyrebird would build with go1.22
16:32:23 <Shelikhoo[mds]> but forgot we already pinned it
16:32:31 <Shelikhoo[mds]> sorry for the noise
16:32:35 <Shelikhoo[mds]> EOF
16:32:36 <meskio> I'm not sure what version we use in the CI
16:32:56 <meskio> looks like we use golang:bookworm
16:33:07 <meskio> maybe this needs changing, I can do it after the meeting
16:33:24 <meskio> anything more on this?
16:34:18 <meskio> then, next topic: Decide whether to simplify webtunnel setting for sni imitation use case
16:34:20 <meskio> Shelikhoo[mds]?
16:34:34 <Shelikhoo[mds]> yes, this is from shell
16:34:42 <Shelikhoo[mds]> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/merge_requests/135#note_3271738
16:35:08 <Shelikhoo[mds]> So basic we are in the process of implementing tls sni imitation support in webtunnel
16:35:34 <Shelikhoo[mds]> which can help many users in place with sni allowlisting to bypass censorship
16:36:23 <Shelikhoo[mds]> and one of the contributor suggests we should make it less verbose in the config to enable the support for this use case
16:37:14 <Shelikhoo[mds]> I am not so sure since it would means automatically set insecure option in utls
16:38:05 <meskio> what do you mean about insecure option in utls?
16:38:22 <Shelikhoo[mds]> and switching to use utls automatically, in certain case even if the old behavior is to use stdlib tls
16:38:58 <Shelikhoo[mds]> It is the InsecureServerNameToVerify
16:39:16 <Shelikhoo[mds]> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/lyrebird/-/blob/main/transports/webtunnel/utls.go?ref_type=heads#L64
16:39:44 <meskio> but this is only enabled if a cert is provided, isn't it?
16:39:49 <Shelikhoo[mds]> which is mapped to utls-authority config
16:39:51 <Shelikhoo[mds]> no
16:40:15 <Shelikhoo[mds]> currently if user set utls-authority then it will be enabled
16:40:32 <Shelikhoo[mds]> and the contributor suggests to enable it if servername is set
16:41:10 <meskio> does it make sense to enable servername and not utls-authority?
16:41:13 <Shelikhoo[mds]> I wonder if excurso is in our meeting...
16:41:28 <meskio> (no one with that nick in the room)
16:41:44 <Shelikhoo[mds]> there are 2 usecases for these options
16:42:06 <Shelikhoo[mds]> 1. SNI imitation which we wants to support with these merge requests
16:42:13 <Shelikhoo[mds]> 2. domain fronting, which is also in theory supported
16:43:15 <Shelikhoo[mds]> with 1.SNI imitation user set url=https://httphost/path servername=fakesni utls-authority=realdomainnameoncert
16:43:46 <Shelikhoo[mds]> with 2. domain fronting user set url=https://httphost/path servername=frontingsni
16:44:08 <Shelikhoo[mds]> in case one the certificate returned by server will be issued for realdomainnameoncert
16:44:25 <Shelikhoo[mds]> in case 2, the server will return certificate issued for frontingsni
16:44:34 <Shelikhoo[mds]> Over
16:45:36 <cohosh> what is the need for a simpler configuration? is the bridge line too long?
16:45:39 <meskio> if I understand correctly (I see there are many tecnical details) this boils down to, do we want to make more straight forward 1. or 2.?
16:45:56 <meskio> making utls-authority needed for one of the two options
16:46:19 <meskio> cohosh: those options are not provided by the bridge, but by users hacking their way
16:46:58 <Shelikhoo[mds]> they wants a simpler configuration to make it get more usage(by making it more convenient to use)
16:47:04 <cohosh> right, but they are set by the client either in the ClientTransportPlugin line or the Bridge line, right?
16:47:26 <Shelikhoo[mds]> It should be set in the bridgeline
16:47:34 <cohosh> i guess what is it about the way it's implemented now that is not convenient?
16:48:14 <Shelikhoo[mds]> yes, I was trying to make it "correct" from a engineering point of view, but for users it is not the most easy thing to do
16:49:04 <cohosh> but what is it that users have to do? just set both servername= and utls-authority= in the bridgeline?
16:49:24 <cohosh> is it that it's easy to misconfigure?
16:49:44 <Shelikhoo[mds]> have to set url, utls, servername, utls-authority to get 1.SNI imitation to work
16:49:59 <Shelikhoo[mds]> in the bridgeline
16:50:17 <cohosh> ok got it
16:50:27 <meskio> (I think we should split this discussion in two things, the utls-authority param and the utls by default configuration)
16:51:51 <Shelikhoo[mds]> yes, one of the thing we could do is to make webtunnel use utls by default
16:52:33 <Shelikhoo[mds]> optionally when utls-authority is set(or servername is not url.hostname())
16:53:52 <cohosh> i guess that would be utls=hellorandomizedalpn by default, and then users could optionally include the utls= arg to use a different fingerprint?
16:54:15 <Shelikhoo[mds]> yes, that's true
16:54:21 <cohosh> or "utls=hellorandomizednoalpn" or whatever
16:54:26 <cohosh> that sounds reasonable to me
16:55:05 <cohosh> i understand the goal is the cut down on the number of arguments you need configured just right to enable a single feature
16:55:07 <Shelikhoo[mds]> yes, I am slightly hesitate since utls is not stdlib, so it might lag behind security updates
16:55:28 <meskio> Shelikhoo[mds]: pointed to me that there is a risk that some webservers attempt to use extensions advertized but not implemented by uTLS and make the connection fail
16:55:29 <cohosh> i like the idea of using it be default if utls-authority is set
16:55:44 <meskio> but in a reconnection it should pick a different set of extensions and hopefully work...
16:56:06 <Shelikhoo[mds]> yes, if we are using the hellorandomizednoalpn then there isn't such risk
16:56:28 <meskio> ahh, cool
16:56:39 <Shelikhoo[mds]> the risk of unable to connect due to failed handshake is mostly about chrome client hello
16:56:53 <Shelikhoo[mds]> but this is a regression risk we need to consider
16:57:10 <Shelikhoo[mds]> cohosh: Yes, I think this is a possibility as well
16:58:02 <Shelikhoo[mds]> so.... Which route should we pursue...
16:58:07 <meskio> we are doing uTLS by default in snowflake now, isn't it?
16:58:39 <Shelikhoo[mds]> for snowflake at least we are supplying the bridgeline with it
16:58:55 <meskio> ohh, I see
16:59:03 <cohosh> i don't think it's by default, but most of our bridgelines have it
17:00:35 <meskio> so we are relaying on uTLS already for snowflake anyway, I don't see it a big problem to use it by default in webtunnel, but I don't have a strong option there
17:00:35 <cohosh> unless there is a way to turn off utls in the bridgeline, i think we should add it only if utls-authority is set if the goal is to make sni spoofing easier
17:01:16 <cohosh> but i don't have a strong opinion considering we need utls in most places anyway
17:01:34 <cohosh> well not most places but most places that require the use of circumvention tools
17:02:16 <meskio> yes, it used to be that goTLS in mobile was blocked by some censors, but I haven't hear reports about issues with webtunnel on mobile
17:03:20 <Shelikhoo[mds]> cohosh: we can turn off utls with bridgeline using utls=none
17:03:36 <Shelikhoo[mds]> so maybe we can just use utls by default?
17:04:02 <cohosh> okay cool then yeah i think it's okay to use it by default
17:04:46 <meskio> cool, that is one of the problems, and the other is keeping utls-authority as it is or seting it by default
17:06:29 <meskio> I assume domain fronting (2.) will be mostly set by some bridges, while SNI imitation (1.) will be done by users fideling with the bridge line
17:07:17 <Shelikhoo[mds]> yes, I think this assumption is likely to be true
17:08:08 <meskio> I would prefer to make easier for users than bridge operators, but I get it that it might involve more complexity in the code
17:08:13 <meskio> and not sure if worth it
17:09:54 <Shelikhoo[mds]> I can handle code complexity without any issue, I just wants to make sure there isn't too much risk of surprise or  security issue
17:10:30 <Shelikhoo[mds]> since this would make the option servername have different meaning depending on value of utls
17:11:06 <Shelikhoo[mds]> which will soon be changed by default
17:11:32 <Shelikhoo[mds]> but I understand it would be convenient for users.
17:13:28 <meskio> I'm not sure I follow all the details
17:13:35 <meskio> and we are running a bit over time
17:13:57 <cohosh> same here, i'd need time to read up on these settings to give a good opinion there
17:13:58 <Shelikhoo[mds]> yes... I think we can proceed with using utls by default
17:14:08 <meskio> sounds good
17:14:10 <Shelikhoo[mds]> and discuss this again in a week
17:14:39 <meskio> I guess we can leave it here
17:14:52 <meskio> thank you for making all the work to keep our users happy
17:14:58 <meskio> a reminder we have a reading group in two weeks
17:15:06 <meskio> #endmeeting