15:59:29 #startmeeting tor anti-censorship meeting 15:59:29 Meeting started Thu Jan 20 15:59:29 2022 UTC. The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:29 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:39 hi~ 15:59:40 welcome, here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:59:46 o/ 15:59:59 before we get started, i have a quick questions for people here 16:00:09 i stopped posting the meeting notes to our mailing list 16:00:17 if these were useful to people, can restart 16:00:42 i didn't really have a reason for it other than lots of meetings after this one and eventually just forgetting to do it 16:00:55 hi 16:01:42 (if nobody responds i will assume they weren't that useful) 16:02:14 I used the notes to find links to the meeting logs 16:02:23 I found out I can also get them from http://meetbot.debian.net/tor-meeting/ 16:03:27 hmm okay, i'm on the fence since we do a pretty good job of documenting links and discussions 16:04:06 like i saved the ones from last week in a pad locally because i felt bad just wiping it xD 16:04:16 i'll probably restart posting them then 16:04:31 haha 16:04:50 There is also the forum now, don't know if that will attract attention from low-effort commenters though 16:05:00 anyway, i just answered my own question >.< 16:05:02 yeah that's true 16:05:12 i like the forum for the (bi-) monthly reports 16:05:28 that's probably better than weekly notes 16:05:44 also there is a sync between the tor-project mailing list and the forum 16:06:16 ok let's move on with the agenda 16:06:51 i left the item about the kazakhstan shutdown up in case there were any developments there 16:07:40 the shutdown ended 2022-01-11 00:00 16:07:56 https://github.com/net4people/bbs/issues/99#issuecomment-1012425056 16:08:36 okay cool, thanks dcf1! 16:09:48 shelikhoo: i also left up the item about the new censorship in china in case there were new developments there 16:10:18 shelikhoo: if you are into the idea, this can be the subject of a good research paper or report 16:10:40 with ooni or censoredplanet or both 16:10:47 We have received reply from censored planet. https://gitlab.torproject.org/tpo/anti-censorship/censorship-analysis/-/issues/40026 16:10:59 ups, I was looking something else and forgot about the meeting, hi 16:11:44 I don't know it this can be a report since currently I don't have access to a impacted vantage point. 16:12:34 I will see if i can find a way to test the censorship from outside 16:12:35 I agree it will require more data, I mean that this topic is a good subject for a report 16:13:32 Have you used RIPE Atlas? Are there Atlas probes in the affected networks? 16:13:38 Yes, I don't know for sure, but this is a rare case the censorship is now directly visible 16:14:11 I haven't tried RIPE Atlas 16:14:16 I will try that later 16:14:43 we can also ask for interactive testers or shell accounts on the forums, possibly 16:15:16 Does researchers aware of regional or ISP based censorship in China, the one in addition to GFW? 16:15:30 what are you hoping to do with interactive testing? things like TTL-limited probes, testing specific match signatures? 16:16:15 There are some pieces of research that are about different censorship in different regions of China, but I do not think that injected blockpages are widely known yet 16:16:37 Right now, the thing we are currently not know is that the list of censored website. 16:16:38 "Analyzing the Great Firewall of China Over Space and Time" https://censorbib.nymity.ch/#Ensafi2015a 16:16:53 "Triplet Censors: Demystifying Great Firewall's DNS Censorship Behavior" https://censorbib.nymity.ch/#Anonymous2020a 16:17:02 Is that same for everywhere, or different for different region 16:17:51 I see. You want to test a larger list of candidate websites, not just haphazard reports from people using the internet casually. 16:18:40 Yes, I will wait for the reply from Censored Planet first, while looking at RIPE Atlas 16:19:24 I think that Satellite and Hyperquack can run with a custom list of domains 16:20:02 good work shelikhoo 16:20:13 It is yet to know how common it is too get a website censored, for example, whether our fronting domain is censored 16:20:22 Thanks 16:21:21 nice :) 16:21:37 I could try to request assistance from V2Ray users, but they are not technological so it is much more difficult to conduct experiment smoothly. 16:22:29 Over 16:22:42 dcf1: i think the next item is yours? 16:23:31 I want to try and do a snowflake bridge upgrade for load balancing next week, if possible 16:23:54 I did the installation again and wrote clean instructions, though on a host with only 2 CPUs 16:23:56 \o/ 16:23:59 the onion key issue is solved? or still present? 16:24:23 which is because our host where the snowflake bridge is currently is having some kind of technical issues 16:24:59 I priced comparable VPSes (8 CPU) and they run about $100-200 per month 16:25:17 which is not a cost I want to take on long term without a plan, but for a week or so it's okay 16:25:40 do the technical issues affect the current bridge? 16:26:09 cohosh: no, not as far as I know. As I understand it, the Amsterdam data center (where the production bridge is) is full 16:26:17 ahh okay 16:26:19 The staging bridge we set up last week was in a Miami data center 16:26:59 When I went to reinstall the staging bridge from scratch, it didn't work after a reboot (no route to host) and they told me there was a problem with the hypervisor but did not yet have a fix 16:27:27 So I would not want to reinstall the current production bridge, but an upgrade in place should be fine 16:28:02 shelikhoo: no, there is no clear solution to the onion key problem, but there are several possible effective hacks 16:28:05 makes sense, fwiw tor project sometimes has funds to give to relay orgs/other people to run bridges 16:28:12 (as long as TPI is not maintaining them) 16:29:06 We can bump LastRotatedOnionKey in the state file, and then it's okay for a few weeks 16:29:33 for long run, we might wants to consider making it easier for other peoples to run relay as well 16:29:59 So I can set up a staging bridge again, then we'll need to make a DNS change, and be ready to switch it back in case something goes wrong 16:30:21 dcf1: do you want some of us around when the switch happens? 16:30:52 shelikhoo: yes, unfortunately it seems this kind of load balancing is pretty unprecedented and there's no systematic setup for it yet 16:31:16 first, I don't know how to go about changing the DNS record 16:32:00 oh right, that's the sysadmin team 16:32:12 i'd first change the TTL on the record to 60 seconds in advance of doing any changes, so that when you are doing stuff you're able to see changes happen quickly 16:32:14 you can make an issue here: https://gitlab.torproject.org/tpo/tpa/team/ 16:32:18 even before you change the address 16:32:34 for free haven you'll need arma2 16:32:38 thanks cohosh 16:32:44 good idea irl 16:33:00 freehaven and bamsoftware are CNAME for torproject.net, so I think we only need to change torproject.net 16:33:08 ah yes, you're right 16:34:11 dcf1: Also you may use iptables to route the "remaining" traffic of clients with cached DNS to the new server. 16:34:18 I don't know if we eactly need people to be "on call" at the time, but I can try to do it during hours when people are online and I can post updates in #tor-dev 16:35:42 anadahz: it's actually the proxies, not the clients, with cached dns that would be a problem, and they should not be a problem because if they connect to a bridge while it is undergoing an upgrade, they just won't serve any clients 16:36:48 but I'm thinking of leaving both bridge running concurrently for about 24 hours after making the DNS change, before starting to make any changes to the production bridge 16:36:54 anyway 16:37:57 sounds like a good plan 16:38:37 BTW, ACME won't work unless we also copied the key 16:38:44 TLS key 16:39:09 since the first the staging server don't have A record 16:39:49 and it would be too late to get the certificate after A record is pointed it already 16:40:02 it will have an A record by the time it starts receiving connections, though, I think? 16:40:18 getting a certificate only take a few seconds when the first TLS connection happens 16:40:47 Yes, but some client might have a shorter dns cache, and ACME server might have longer one 16:40:47 but you raise a good point, something could go wrong with the process. I'll make a note to make a copy of the TLS key and certificate. 16:40:52 Yes 16:41:00 just to be safe 16:42:40 okay the next item is about our reading group 16:42:58 before the holiday we discussed doing a reading in january, and then things got really busy 16:43:23 are we too busy still or do we want to get that going again? 16:43:29 (hello i am around, but distracted by being ready for ola's trial. it sounds from the backlog like we almost needed an arma but actually we don't?) 16:43:41 arma2: yeah you're good :) 16:44:14 woo thanks 16:44:23 (hope the trial goes well) 16:44:25 let's schedule reading group discussion for 3 February 16:44:38 Groundhog Day Reverse Eve 16:44:43 cool, two weeks form now sounds good 16:44:45 lol what 16:45:00 fancy 16:45:25 wishing you well arma2 16:46:04 anything else for today? 16:46:29 not from me 16:46:29 is it useful to implement Chacha20Poly1305 in pion/dtls 16:46:51 will be nice to have the link of the paper 16:46:58 * meskio searches for it 16:47:00 https://dl.acm.org/doi/10.1145/3460120.3484550 16:47:06 thanks :) 16:47:16 arlolra: oh wait 16:47:27 I mean meskio: oh wait 16:47:28 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40014#note_2764731 16:47:29 damn it 16:47:35 https://censorbib.nymity.ch/pdf/Ensafi2015a.pdf ? 16:47:54 I could have sworn this one was open access on dl.acm.org but now I see that it is not 16:48:10 :/ 16:48:28 arlolra: oh btw thanks for doing the alpn negotiation 16:48:29 maybe they did the sly ACM trick of making it available for download for 1 month or something 16:48:32 what a farce 16:48:40 the pdf link did work for me: https://dl.acm.org/doi/pdf/10.1145/3460120.3484550 16:48:43 s/negotiation/extension 16:49:05 oh am I overreacting 16:49:30 Anyway there is also an IACR eprint, https://eprint.iacr.org/2021/686 16:49:31 it didn't work for me 16:49:35 unless i'm missing something 16:49:51 cohosh: np. there's a second part to that, something needs to make use of it 16:50:04 yeah, that'd be a patch in pion/webrtc 16:50:07 mmm, it doesn't work over tor... 16:50:18 (i think, or one of the other repos) 16:50:29 meskio: hmm, maybe that's the difference 16:50:31 dcf1: thanks for the link 16:50:39 meskio: I sent the wrong link.... 16:50:49 sorry... 16:50:54 no prob 16:50:58 arlolra: for the ciphersuite, it would be useful, but i don't think there's a rush there 16:51:09 arlolra: is that a ciphersuite that's present in browser fingerprints? 16:51:32 the 2nd link dcf1 sent is accessible via Tor. 16:51:55 dcf1: see the link I posted above to 40014 16:52:34 cohosh: ok, if you can think of a better use of my time, let me know 16:52:43 Oh, they have a whole web page https://meteorfrom.space/ 16:53:04 oh arlolra can you review snowflake-webext!25? 16:53:11 my javascript isn't great 16:53:56 but other than that chipping away at the dtls fingerprinting issues sounds awesome :D 16:54:01 sure 16:54:10 thank you! 16:54:58 * cohosh waits a few mins to see if there is anything else for today 16:56:37 #endmeeting