16:00:02 #startmeeting tor anti-censorship meeting 16:00:02 Meeting started Thu Jul 25 16:00:02 2024 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:02 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:00:05 hi! 16:00:06 hello verybody!! 16:00:06 hi~ 16:00:10 hola 16:00:12 here is our meeting pad: https://pad.riseup.net/p/r.9574e996bb9c0266213d38b91b56c469 16:00:14 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:16 I'll wait few minutes for everybody to add you've been working on and put items on the agenda 16:01:33 hihi 16:01:42 hello world 16:01:46 it doesn't look like we have much to discuss 16:01:59 I guess summer time in the north emisphere :) 16:02:13 let's give it some minutes to see if someone has something 16:04:15 Roger wrote up his Snowflake blocking experiment notes, https://lists.torproject.org/pipermail/anti-censorship-team/2024-July/000343.html 16:04:23 ^- from the announcements 16:04:33 pretty cool, I haven't fully readed yet 16:04:33 i spoke to dcf/cohosh/shel about that at pets, but figured i should write it up for the folks who didn't make it to pets too 16:04:39 but very interesting results 16:05:09 tl;dr i wrote a script to be my own little great firewall for snowflake, and when i censored myself very slowly and conservatively, snowflake still kinda worked 16:05:48 most interesting result, i believe we have a roadmap item for increasing enumeration-resistance of snowflake, 16:05:50 o/ 16:06:01 and we could do that well by finding a way to use more of our restricted-nat proxy pool 16:06:47 yes, that would be nice 16:07:01 (or getting a lot more proxies into the unrestricted pool, or finding a bug where it turns out more of our proxes are actually unrestricted, or etc) 16:07:25 i wonder how much effort worth it to do enumeration-resisance defense in snowflake. thinking of two other real world censorship events where they blocked snowflake by fingerprinting (iran and russia) 16:08:33 i figured the first step to answering the 'worth it' part was to understand how effective a really easy attack is. and it is not completely effective. 16:08:48 we could start with some initial steps such as rate limiting the requests by source IP 16:09:03 which is not that engineering intensive 16:09:21 which should just work once we moved to use new broker 16:09:36 finding a way to use more of our restricted-nat proxy => would be interesting to know how much is behind symmetric nat vs how much is behind various kind of cone 16:10:44 it does seem like some more investigation of the specific nat situation for our volunteers could be a big win if we find something 16:13:02 yep, next year we are supposed to improve the enumeration-resistance as part of a grant, we should explore a bit more what is needed there 16:13:19 I think is nice to make it hard so censors keep trying to fingerprint instead of enumerating 16:13:29 shelikhoo: yep! two notes on the rate limiting idea, (a) you might want to treat tor exits specially, like bridgedb does, and (b) some of the signaling channels let you know the ip address of the requestor, but some do not 16:14:39 meskio: agreed, this is a good goal (make sure enumeration is not the lowest hanging fruit) 16:15:32 yes, we will need to consider them 16:16:15 some future experiment i might do is simply: run snowflake on its own in a tight loop, scooping out the whole database from the broker. i expect that's what those jerks on github did / are doing. 16:16:45 (i didn't want to do that here, because i think done poorly this experiment would actually deny service to the real snowflake users.) 16:19:58 we should update https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Research-ideas 16:20:07 there is an entry about snowflake enumeration 16:20:30 yes... maybe just paste the irc log? 16:20:49 I think it is true that there is a lot of considerations we wants to make 16:21:17 and it would require a write up and issue, not something we could think up in irc meeting in real time 16:22:15 we can link this meeting logs and arma2 email 16:22:20 I'll do that after this meeting 16:22:42 I think even simple steps could make listing proxy with scripts much harder 16:23:45 yep 16:24:35 anything more on this topic? 16:24:46 not from me 16:24:53 eof on this topic 16:25:09 from the interesting links: 16:25:14 https://arxiv.org/abs/2405.13310 "Bytes to Schlep? Use a FEP: Hiding Protocol Metadata with Fully Encrypted Protocols" 16:25:16 update to https://censorbib.nymity.ch/#Fenske2023a "Security Notions for Fully Encrypted Protocols" from FOCI 2023 16:25:32 there are also this year FOCI papers out already 16:25:59 once more people is around we can look into our next reading paper 16:26:10 https://github.com/tst-race/raceboat/tree/documentation Raceboat source code 16:26:13 yes! nice! 16:26:22 there were also some censorship-related papers at pets, e.g. yeah raceboat 16:27:04 yes, cool to see raceboat published 16:27:05 I will have a look at the race boot source code, really curious how many language they used to create it 16:27:40 I will have a look at the race boat source code, really curious how many language they used to create it 16:27:42 is a weird mix 16:27:55 shelikhoo: part of their goal is to have hooks in a lot of different languages, so you can write your PT in go or python or C or etc 16:28:07 hopefully the core raceboat stuff is only one language :) 16:28:36 arma2: yes, and that would make it super super hard to get it on constraint environment like mobile 16:30:04 I chatted with them and they are not targeting iOS users 16:30:13 which we kind of do 16:30:22 are they targeting android? 16:30:53 I think they are, or kind of? 16:31:03 I see there are arm64-v8a targets 16:31:11 so it might work on android 16:31:46 wow, using python and go in android all together sounds complicated 16:31:58 yes, android was one of the big target architectures for race 16:32:16 and also cpp 16:32:18 and also yes, "what the hell why is this so complicated" is a very legitimate question :) 16:33:06 :D 16:33:07 I think they are hiring different people with different knowledge about their favorite language 16:33:10 lol 16:33:21 so as a result everyone kind of write their own thing 16:33:43 shelikhoo: it wasn't so much hiring as 'race had different teams each doing their own thing, and the raceboat people had to handle them all' 16:33:45 then someone else is tasked with glue them all together 16:33:57 yes 16:33:59 yes... 16:34:17 uff 16:34:51 which is not *too* different than the pluggable transport ecosystem 16:35:10 which grew goptlib, something in swift, something for py, etc 16:35:30 you could legitimately ask why *that* ecosystem is so complicated, too :) 16:35:39 yes, and we are using exec/fork/stdio and socket as interface 16:35:45 not dynamic library 16:36:00 except on ios where it all needs to be one big blob :) 16:36:08 so the runtime is not that kind of issue when Tor's PT spec was designed 16:36:30 I believe they designed their system after Android and iOS is a thing 16:36:52 yes,yes, but PTs were designed before mobile was a thing 16:37:11 and now we dream on a future where PTs are arti libraries, possibly just in rust 16:37:46 that was kind of a distant future... but I will use my friday to learn rust now 16:38:04 true, distant future 16:38:15 rust is fun, but I find it harder to learn than go 16:38:43 the last interesting link: 16:38:45 https://github.com/v2fly/v2ray-core/discussions/3096 16:38:47 V2Ray has received a security audit from 7ASecurity 16:38:49 https://www.opentech.fund/security-safety-audits/v2ray-security-audit/ 16:38:52 congrats for v2ray 16:38:54 pretty cool 16:39:04 hehe 16:39:04 nice 16:39:11 yes! the report is now public 16:39:48 and the security audit found no major issue in V2Ray 16:39:54 nice they didn't find anything major 16:40:43 anything more, should we close this meeting? 16:40:48 eof from me 16:41:17 fine by me 16:41:41 #endmeeting