16:00:01 <shelikhoo> #startmeeting tor anti-censorship meeting
16:00:01 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469
16:00:01 <shelikhoo> editable link available on request
16:00:01 <MeetBot> Meeting started Thu Jan 16 16:00:01 2025 UTC.  The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:01 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:00:06 <shelikhoo> hi~hi~
16:00:08 <meskio> hello
16:00:15 <theodorsm> hei! :)
16:00:21 <onyinyang> hihi
16:00:34 <WofWca[m]> Hi
16:02:46 <cohosh> hi
16:03:24 <shelikhoo> okay I think we can begin today's first topic
16:05:17 <shelikhoow> sorry my irc setup was a little broken
16:05:35 <shelikhoow> so the summary about this merge request: https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/455
16:05:57 <shelikhoow> is that we are considering to let snowflake proxy run as unprivileged user
16:06:10 <shelikhoow> instead of the default root user
16:06:24 <shelikhoow> it would break the setup of some users
16:06:34 <shelikhoow> even if it is a nice thing to have
16:06:43 <shelikhoow> when it comes to least permission
16:07:03 <meskio> I'm not a big fan of setting the user inside the container, I prefer to set it on run time with --user (this is how I rund the proxy actually)
16:07:57 <shelikhoow> yes... additionally for users running rootless container
16:08:12 <shelikhoow> this would result in any file created in docker not accessible to the user running it
16:08:28 <meskio> but the proxy should not be creating any files, isn't it?
16:08:48 <shelikhoow> yes, I don't think it will create file...
16:08:58 <shelikhoow> other than log
16:09:36 <meskio> it does generate a log file? I thought it prints it in stdout only
16:10:13 <shelikhoow> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/blob/main/proxy/main.go?ref_type=heads#L27
16:10:26 <shelikhoow> there is a config to generate such a log
16:10:48 <meskio> ahh, if someone has configured to send a log we'll break their setup
16:10:50 <meskio> I see
16:11:20 <shelikhoow> and if they are listening on port < 1024 or so
16:11:33 <shelikhoow> for metrics-port
16:12:06 <meskio> I woudn't do the change, we could document instead how to run it with whatever user you want adding a 'user: uid:pid' into the docker-compose file
16:12:21 <meskio> but I don't have a strong opinion here
16:12:34 <meskio> WofWca[m]: are you around?
16:12:41 <WofWca[m]> Yes
16:12:50 <meskio> what do you feel about it?
16:13:25 <WofWca[m]> As I said, I haven't really went deep investigating this, so I can't contribute much to the discussion.
16:13:34 <meskio> :)
16:13:58 <WofWca[m]> I think I didn't remember the --user option when I wrote this MR.
16:14:26 <shelikhoow> I think we could update the deployment manual.... it should be sufficient...
16:14:32 <meskio> I did discover that option recently, I don't think is that common to use it, but I find it really handy
16:14:40 <meskio> so I can pick the uid I want for the files generated
16:14:50 <meskio> but it doesn't work with all existing containers
16:14:57 <meskio> it does with the proxy :)
16:15:52 <shelikhoow> yes... personally I just run rootless container
16:16:21 <shelikhoow> I think we have reached a consensus, let move to the next topic
16:16:33 <shelikhoow> Unreliable WebRTC mode really is faster! https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/315#note_3149069
16:16:39 <shelikhoow> hehe! but this is not from me
16:16:57 <WofWca[m]> Yep, it's from me! I don't know if there is a lot to discuss, just wanted to sort of announce it.
16:17:23 <dcf1> Thanks for the test, that's helpful.
16:17:31 <shelikhoow> yes, and thanks for the test!
16:17:32 <meskio> nice
16:17:55 <shelikhoow> the first announcement today is:
16:17:55 <WofWca[m]> Thanks to you all for working on it!
16:17:56 <shelikhoow> SQS rendezvous exceeded free tier limit
16:17:56 <shelikhoow> https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@lists.torproject.org/t
16:18:22 <meskio> SQS is a success :D
16:18:26 <shelikhoow> kind of victim of its own success
16:18:44 <meskio> we are configuring it for china over the circumvention settings API
16:18:58 <dcf1> Don't let cohosh pay for this alone
16:19:19 <shelikhoo> but yes, it is a success
16:19:20 <dcf1> It's common that TPO kind of ignores things like this and just lets individuals take on a burden, but that would be harmful and alienating
16:19:48 <dcf1> I am recalling the early history of meek CDN charges https://www.bamsoftware.com/papers/thesis/#tab:meek-costs
16:19:54 <dcf1> $0.56 😀
16:20:00 <dcf1> $4.66 😅
16:20:06 <dcf1> $8.61 😅
16:20:11 <dcf1> $171.14 😨
16:20:29 <meskio> wow, that is a progression in few months
16:20:56 <meskio> we should ask TPO to pay for it
16:21:15 <shelikhoo> yes I agree
16:21:17 <cohosh> haha yes i will write an email to accounting this afternoon
16:21:24 <meskio> AFAIK there is a limit configured there so there will not be a huge bill
16:21:42 <cohosh> but in the meantime i am glad the budget actions are there and working
16:21:50 <meskio> cohosh: thanks
16:22:27 <meskio> and in china we do distribute also domain fronting, so people is not left without options if SQS stops working because of the budget
16:23:34 <shelikhoo> yes....
16:23:40 <meskio> hopefully this will not be like meek, as we don't move real traffic, but we'll see
16:24:06 <shelikhoo> my fear is that censor could just ddos the endpoint
16:24:43 <shelikhoo> but let's hope it doesn't happen
16:24:55 <cohosh> yeah we'll deal with that when it happens
16:24:56 <shelikhoo> anything more we would like to discuss on this topic?
16:25:06 <meskio> not from me
16:25:12 <shelikhoo> Edgio Azure CDN was supposed to have shut down 8 hours ago, snowflake-broker.azureedge.net is still running for the moment
16:25:12 <shelikhoo> https://lists.torproject.org/mailman3/hyperkitty/list/anti-censorship-team@lists.torproject.org/message/ZKX7SUG432RHGSQAIYRRW3QSCQBK7LWS/
16:25:12 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40434#note_3149295
16:25:37 <cohosh> fwiw our meek-azure bridge is also still working
16:25:50 <dcf1> 2025-01-15 was supposed to be the shut down time (8.5 hours ago)
16:25:58 <dcf1> But I tried it just now and it is still working
16:26:06 <dcf1> But I would not be surprised if it stops working today
16:26:27 <meskio> :)
16:26:50 <shelikhoo> this sunday will be the big day for tiktok as well(BTW)
16:27:16 <dcf1> oh interesting
16:27:26 <dcf1> i wonder if many use circumvention to reach tiktok
16:27:41 <meskio> I read something that they only plan to remove the app from the stores
16:27:46 <meskio> not to block the traffic
16:28:01 <meskio> but I don't know if this newspaper had any good source of that information
16:28:03 <meskio> we'll see
16:28:36 <shelikhoo> there are news report that tiktok plan to just shutdown its US version
16:29:00 <dcf1> BBS thread about blocking *tiktok.com at the University of Texas (2023): https://github.com/net4people/bbs/issues/201
16:29:19 <shelikhoo> and banning all US users, making it inaccessible even if they already have tiktok on their phone
16:29:26 <shelikhoo> but that is just one report
16:29:34 <dcf1> but yeah, I agree, maybe circumvention is not so applicable in this case, outside of isolated environments like auniversity
16:30:13 <shelikhoo> circumvention cannot deal with account get banned, if it actually happens.
16:30:16 <shelikhoo> yes
16:30:40 <shelikhoo> and finally today we have a reading group
16:30:41 <shelikhoo> Discovering and Measuring CDNs Prone to Domain Fronting
16:30:50 <shelikhoo> https://dl.acm.org/doi/10.1145/3589334.3645656
16:31:42 <meskio> I can try to summarize it
16:32:01 <dcf1> [Funny, I just checked https://applecensorship.com/, and 国家反诈中心 (China "anti-fraud" app) is in trending searches, I wonder if it usually is in trending.]
16:32:09 <meskio> the authors created an automated way to discover what CDNs have domain fronting capabilities
16:32:48 <meskio> by analizing DNS the traffic of 2 universities ot discover domain names of services with content hosted in the CDNs
16:33:02 <meskio> finding static content on those domains
16:33:16 <meskio> and pairing the to try domain fronting against each CDN
16:34:03 <meskio> they found that some CDNs do have a complex setup where domain fronting works for some domains and not for others, probably because a mix of new and older infra
16:34:24 <meskio> we've seen that in fastly supporting our account's domain front for a while while they didn't support it for new accounts
16:34:59 <meskio> I find it a bit confusing on how the center so much into the posibilities of domain fronting for malware
16:35:03 <theodorsm> They also disclosed to all CDNs that supported domain fronting that they did
16:35:09 <meskio> and keep describing it as a security issue
16:35:37 <shelikhoo> yeah, I think for big CDN networks, whether to allow domain fronting is a policy issue, not tech issue
16:35:44 <meskio> theodorsm: yes, a usefull list, but maybe outdated, as akami and fastly doesn't support it anymore
16:36:38 <shelikhoo> for network operators and those who control the network, domain fronting is bad thing
16:36:44 <shelikhoo> not so much for its users
16:36:49 <dcf1> the survey of CDNs (e.g. Figure 2) was the most valuable part of this paper for me
16:36:51 <shelikhoo> for better or for worse
16:36:57 <meskio> malware attackers have better tools that domain fronting, I find very confusing that will be a real reason for CDNs to block it, if so why did cloudflare allow ECH?
16:37:30 <meskio> dcf1: and Figure 4 what theodorsm mentions of the list of supported CDNs
16:38:02 <meskio> I find interesting the tool they mention CDNFinder: https://www.cdnplanet.com/tools/cdnfinder/
16:38:06 <shelikhoo> I think what really happened is that when government block their CDN, they will block domain fronting
16:38:12 <dcf1> it is true that e.g. penetration testing red teams and infosec people latched onto domain fronting really hard
16:38:19 <cohosh> yeah i like the breakdown in figure 2 of website rank
16:38:26 <meskio> migth be useful to find domains to use for domain fronting inside be websites
16:38:30 <shelikhoo> but when some customer wants avoid their service get blocked, they will deploy ECH
16:38:36 <dcf1> there are several e.g. defcon and blackhat talks of varying quality, and it's interesting to see the completely different perspective the speakers are coming from
16:39:23 <meskio> I wonder if figure 2 is too US-centric, as they based it on their universities DNS requests
16:39:29 <dcf1> shelikhoo: hmm, that's an interesting way to think about it
16:39:33 <meskio> and might not be representative for the censored areas we care
16:39:36 <theodorsm> Does cloudflare terminate ECH for CDNs, so they could block domain fronting with ECH as well? They terminate TLS already right?
16:40:02 <dcf1> I think cloudflare generally terminates TLS, yes
16:40:44 <shelikhoo> yes, the L7 HTTPS? service from cloudflare will handle TLS and ECH
16:41:04 <shelikhoo> they have other service that forward tcp connection directly
16:42:08 <shelikhoo> there are difference between ECH and domain fronting
16:42:26 <shelikhoo> specifically browser are supposed to always send ECH extension
16:42:34 <shelikhoo> even if the server does not really support it
16:43:16 <shelikhoo> this is designed to defeat the attempts to block TLS connection based no whether it have ECH extension
16:43:39 <shelikhoo> when there is censorship, the thing get blocked will be end user's browser
16:44:05 <shelikhoo> in the domain fronting's case, it is the CDN that might or might not support domain fronting
16:44:17 <shelikhoo> so the thing will get blocked is the CDN network
16:44:46 <shelikhoo> by shifting from domain fronting model to ECH model, the risk of getting censored is shifted from CDN network to browsers
16:45:58 <dcf1> This is yet another paper where the authors treat other research teams as if they were some remote inaccessible artifact.
16:46:06 <dcf1> "This finding is also corroborated by third-party evidence suggesting that Fastly is being used as an alternate service in Tor plugins like Meek and SnowFlake [23]."
16:46:28 <shelikhoo> so it makes sense for CDN network to really like it, while big big browsers with little or no competition(name start with C and S) deploy it and accept the cost
16:46:31 <dcf1> It's like, instead of relying on third-party evidence, did you try, like, asking them?
16:46:43 <meskio> I guess people write those papers too fast and don't have the time to talk to others
16:46:47 <meskio> you have to produce papers...
16:46:59 <dcf1> I guess it's safe to assume that none of you Meek and SnowFlake developers were contacted by these researchers :)
16:47:19 <dcf1> I also thought it was funny that testing for domain fronting without actually registering a domain is treated like some great innovation.
16:47:23 <dcf1> "without the need for registering any new domain names or hosting any new services behind each CDN"
16:47:27 <meskio> but they did "responsible disclouse" to CDNs...
16:47:35 <dcf1> "Fifield et al. were the first to introduce Domain Fronting in [20]. To test whether domain fronting was possible, the authors registered their own domains and manually subscribed them to small number of CDNs being tested. Unlike their mostly manual testing approach…"
16:47:46 <dcf1> I feel I am qualified to speak on behalf of Fifield et al.
16:47:54 <shelikhoo> hahahaha
16:48:00 <meskio> XD
16:48:20 <dcf1> And I can say that we (I, at first) did just what they did here: found two existing customers of a CDN, and tried fronting one with the other.
16:48:22 <meskio> maybe they consider you a dangerous actor inveting this evil tool
16:48:29 <dcf1> https://www.bamsoftware.com/papers/fronting/#sec:survey
16:48:39 <cohosh> lol
16:49:09 <dcf1> By the time we published the paper, of course we had deployed on several CDNs and bought domains and become customers, but it's not necessary to do all that just to test for support, obviously.
16:50:10 <meskio> I guess the extra thing they did in this paper is to automatize it and scale it up
16:50:11 <dcf1> anyway, yeah, it's nothing new, I just keep wishing scientists would talk to each other more
16:50:27 <meskio> but I haven't found the code :(
16:50:40 <theodorsm> Ofc, dangerous hacking tool!!
16:52:38 <shelikhoo> okay, is there anything else we would like to discuss in this meeting?
16:52:54 <meskio> not from me
16:53:00 <theodorsm> cohosh: what is the status on the tor build ?
16:53:43 <cohosh> ah thanks for the reminder, i again completely forgot about it
16:54:05 <cohosh> the linux build has finished
16:54:18 <cohosh> i'll do a windows build too
16:54:26 <cohosh> and i can do an osx build
16:55:11 <cohosh> i'll update the issue
16:55:18 <theodorsm> Nice! Then I will try it out and write a setup guide
16:56:08 <shelikhoo> okay... I feel it is end of text stream...
16:56:20 <shelikhoo> Thanks!!!
16:56:20 <shelikhoo> #endmeeting