15:59:00 #startmeeting tor anti-censorship meeting 15:59:00 Meeting started Thu Apr 7 15:59:00 2022 UTC. The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:00 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:03 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:59:19 Hi~ 15:59:25 hello 15:59:55 hi all 16:00:01 hello 16:00:14 please add things you are working on 16:00:24 and things to discuss to the pad 16:04:35 okay now is the announce time 16:04:37 Next snowflake bridge migration scheduled for next week https://gitlab.torproject.org/tpo/tpa/team/-/issues/40716 16:04:48 thanks dcf1 ~ 16:04:54 nice \o/ 16:05:48 is there something we need to discuss about this announcement? other than monitoring the situation when the transition happens 16:05:52 dcf1 amazing work! 16:06:31 I think just monitor it when it happens. The last times we have done this it has been smooth, so I don't expect any problems. 16:07:17 :D 16:07:48 are the metrics going to be fully accurate now? I recall there was an issue when the sharding had shared keys, but now no longer? 16:08:25 The metrics will still be messed up because there will still be multiple instances of tor running with the same relay fingerprint 16:08:32 we still have the issue of the bridges with the same fingerprint 16:08:33 yes that 16:09:28 okay, anything more on this topic? 16:09:35 ah, I see. should we solve that sort of metric thing / is someone already on it? 16:09:38 hiro has been working on the tor metrics display, tpo/network-health/metrics/onionoo#40022 and tpo/network-health/metrics/website#40047 16:09:46 cool 16:10:19 okay, anything more on this topic? 16:10:55 Now move on to the discussion phase 16:10:56 Nickname for second bridge site? https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40122 16:10:59 The necessary information is there, it's a matter of interpreting and displaying it. The way the snowflake bridge is set up violates reasonable assumptions in the metrics code, so it requires more than minor refactoring. 16:11:20 I have reorder the item now that we are already talking about that bridge 16:11:39 So far with the singular bridge site we have kept the same fingerprint and nickname "flakey", even as it has moved across hardware 16:11:45 sorry dcf1 I didn't mean to interrupt you.... 16:11:50 hehe, naming things, the hard problem in computer science 16:12:06 As I understand it, the plan for https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/28651 is to set up multiple bridge sites, each with its own distinct bridge fingerprint 16:12:17 Yes that's correct 16:12:18 The client will choose which bridge fingerprint it wants to use 16:12:30 So with a new fingerprint there should be a new nickname :D 16:13:14 I don't want to take up too much time with non-important discussion, but let me know if you have a nice idea 16:13:53 This will follow the same pattern as the existing bridge, where there are nickname1, nickname2, etc., in order to distinguish the separate instances and make metrics recovery possible in the future 16:14:08 guys, you know what we're doing? we're creating a snowstorm with all these snowflakes ;) 16:14:24 xD 16:14:30 Yeah~ 16:15:06 ql`v`lp 16:15:12 Let's say Sr2's bridge name are like Sr2ZincReno 16:15:24 Sr2 is the family name 16:15:43 Zinc show the group of the bridge 16:15:45 is the plan to keep with the snow names? powdery? 16:16:07 Hmm I like powder 16:16:20 https://en.wikipedia.org/wiki/Classifications_of_snow 16:16:36 and finally each one have a final word that is different for each bridge 16:16:37 Okay, any ideas, leave them on the issue or something, like I said I don't want to take up too much meeting time 16:16:51 :) 16:17:41 Yes. let's paste name candidate and suggestion to the ticket 16:17:54 now move on to the next topic for discussion 16:17:56 Discuss about cooperation with Greatfire 16:18:22 keroserene do you wants to lead the discussion? 16:18:43 Yes, we had a great call with them a few hours ago 16:19:21 shel helped prepare a list of questions, and we went through as many as we could 16:19:41 the timezone over there is too late so they will follow up with more soon, 16:20:01 here's the initial notes q&a: https://pad.riseup.net/p/greatfire-snowflake-notes 16:22:42 there was "martin", tech lead, and one other greatfire dev on the call with us 16:24:33 It looks like the subject was collaboration btw tor and greatfire, specifically with FreeBrowser and Snowflake? 16:24:52 yes, one of the topics was FreeBrowser + Snowflake 16:25:49 we've had several projects express interest in integrating snowflake (riseup and i2p) for example. one thing that many don't realize is the effort involved with setting up the broker and getting a good proxy pool 16:26:08 yes indeed 16:26:37 an interesting question at hand is how to scale up snowflake, in collaboration with additional these use-cases & clients, in a way which actually increases capacity for everyone & fits the various constraints 16:27:18 capacity meaning the snowflake network & performance, but also number of devs able to help the project 16:27:32 Oh? There are other interested projects? sorry for mistake in one of my email... 16:28:05 yes, I know leap/riseup has being looking into it 16:28:22 and we have collaboration with guardian project for them integrating snowflake 16:28:41 gaba: the guardian project situation is a little different because they are using snowflake + tor 16:28:45 another thing GreatFire is very interested in is the "system wide" client, beyond the browser, and this could be a snowflake client. they actually have the resources to put at least 1 dev on that question 16:28:52 would be nice to have a public pool of proxies, where each proxy be able to configure wich service (bridge) they want to allow connections to 16:28:54 these other projects don't want to use it with tor (as i understand it) 16:28:59 the issue about capacity that we have is for the team. We do not have more hours that we can dedicate to other things other than what we already commited to in our current roadmap 16:29:33 I am happy to bring in more capacity 16:29:43 I think that is part of what keroserene is trying to address with her outreach, to increase the number of people who are capable of working on snowflake 16:29:49 i see 16:30:04 kerosene: if you have people that can work on it then i think it would be good to review any patch you bring 16:30:08 re "Server have access but does not store decrypted HTTPS traffic in plaintext." is it possible to verify? Would integrating with snowflake help de-centralize it? 16:30:35 gaba: yes let's sync up, and definitely we will have review process 16:30:36 there are some troublesome answers in the pad, related to greatfire MitM all https traffic 16:31:00 ups, I see itchyonion already raised the problem 16:31:33 I guess they are doing domain fronting on a request-by-request basis, rather than embedding a tunnel in HTTP as meek does 16:31:53 More lightweight and efficient, but you lose end-to-end security through the circumvention proxy 16:32:05 they may be open to improving it so it's actually e2e 16:32:09 That's just my guess, I haven't tried FreeBrowser 16:32:18 but if they were using snowflake they would not need to do that 16:32:25 yes :) 16:33:10 Yes, I have confirmed that is is currently request to request proxy in the meeting. 16:34:08 meskio: agreed on public pool of proxies, where there are choices of which service 16:34:16 it gives the users the choice 16:34:32 Reading the pad I see the question about dividing development between Tor and Greatfire. I want to clarify that we can not add any development work to this project other than what we are already doing and have planned in our roadmap for this quarter and next. 16:35:36 understood on the current capacity at Tor, 16:35:38 Sorry to say it again. I just want to be clear :) 16:35:44 I agree, we should not do any development in our side beside being part of the planning and do code review 16:35:49 no problem :) 16:36:38 I am willing and able to onboard devs, and even bring in funding, to scale things up beyond the current capacity, if you guys want me to 16:37:01 kerosene: can this proposed work be used by other projects too? 16:37:28 I believe so, it would extend snowflake into a more generalizable global circumvention tool 16:38:02 ok 16:38:36 it would also increase the size of the current snowflake network / help scale things and improve the tor-side performance too, if we approach it well 16:39:38 sounds good 16:39:49 it would be fine to review and discuss any proposal 16:40:55 Okay, is there anything more on this topic? 16:41:30 the greatfire dev(s) will look more closely at snowflake soon and offer more feedback when they can 16:41:43 will keep everyone posted 16:42:17 thanks 16:42:31 Okay, now is the reading group time: Balboa: Bobbing and Weaving around Network Censorship -> https://www.usenix.org/system/files/sec21-rosen.pdf 16:43:32 this is a paper about transporting information by intercepting TLS connection and replace connection content based on defined rule 16:44:32 The author claims that this method make it traffic identical to original one other than minor timing difference 16:44:52 Balboa has some similarities to another paper we have discussed, Protozoa https://github.com/net4people/bbs/issues/55 16:45:20 Which also has some conceptual ties to the Overt User Simulator of Slitheen 16:46:05 The thrust of all these works is: how to get a traffic signature (packet timing, size, volume) that is indistinguishable from some other flow 16:46:36 And they all work by traffic replacement: remove some part of the encrypted stream, and replace it with an encryption of covert data, of identical size 16:46:51 I found pretty interesting how they modify the traffic in and out the application rewritting TLS content using the session keys retrieved from the debug interface of the TLS implementation 16:47:31 Yes, the way Balboa works breaks a lot of abstractions, and it sounds like they had to take considerable care to deal with all the details 16:47:49 i like the end to end nature of both protozoa and this paper much better than the end to middle (decoy routing) deployment of slitheen 16:47:52 Yes, we have always used that for debugging, but live hijacking is something quite new to me 16:47:55 in terms of practicality 16:47:58 I liked that a Balboa-enabled server can function as a normal server to the public. I'm quite surprised that decrypting and re-encrypting traffic does not introduce significant overhead. 16:48:36 An interesting and different aspect of Balboa is that both ends are assumed to share not only a key (which is typical) but also a traffic model 16:48:58 itchyonion: symmetric key cryptography is pretty efficient 16:49:20 The traffic model could be something abstract (e.g. like in ScrambleSuit), but they also posit an extreme form of modeling: both ends actually pre-share traffic that they intend to exchange later 16:49:22 however on mobile platform this kind of tool is difficult to deploy 16:49:43 something that bothers me of balboas examples is that basically the model is as big as the data they manage to send, for example for the music streaming you can stream the size of the ogg files you preshared 16:50:07 yeah the presharing of files to me was the biggest weakness of this design 16:50:28 So like in an HTTP session, the client may already have some of the images it intends to request from the server. The server does traffic replacement and overwrites the images with other data; the client recovers the secret data and then re-replaces it with the pre-shared image data, before handing the stream to the browser or whatever 16:50:29 i don't think it's necessary 16:50:33 There are some work that solve this by attaching an extra compression layer 16:51:22 This will, however, increase time difference signature 16:51:41 for images or ogg you might not get much adding compression, and for html or css I will assume apache does compress it anyway before sending it 16:51:56 or you mean readucing the bitrate of the ogg files or something like that? 16:52:08 They do glancingly address the issue of the size of the model "the traffic model need to be a model of the *entire* interaction ... this allows parties to communicate N bytes of data without needing the model to be of size O(N)". But I don't think there was anything concrete in that regard. 16:52:30 *"the traffic model need NOT be a model of the entire..." 16:53:23 I did not extremely carefully, but to me it looked like the actual implementation in their two instantiations used O(N)-sized models 16:53:52 yes, their examples look like that 16:54:54 you could have models for music streaming where you fetch the stream from a third party broadcast, but that might be easy to notice from the censor 16:55:01 or have some nice generative music... 16:55:47 anyway the streaming example is a bit limited being mostly unidirectional 16:56:12 and for their other example of http browsing, I'm wondering if is not a better idea to just use HTTPT 16:56:13 I do like this vein of research into indistinguishable traffic signatures, even if (as the authors conceded) it is not a comprehensive solution to circumvention on its own 16:56:36 sure, I think is great people is putting time into it 16:57:11 meskio: agreed, currently it's a reasonable assumption that if you somehow have a TLS server that is unknown to the censor and not blocked, just use it as a normal proxy 16:57:51 I think these authors are designing for a world that does not really exist yet, where a censor sees only a large number of undifferentiated TLS connections, and has to make differences between them based on traffic signature 16:58:27 The introduction and related work sections show a good understanding of the problem and solution space, I think 17:00:02 I don't understand this part very well: "Because we use dynamic library injection, Balboa does not work on applications that do not use dynamic library calls to perform network operations (such as applications written in Go". So Go is very different in this regard? 17:00:19 itchyonion: yes, the difference is dynamic vs. static linking 17:00:31 itchyonion: go doesn't use libc (sometimes) 17:00:35 It's the same reason that torsocks does not work with Go or Rust binaries, because they are statically linked 17:01:03 Interesting. Will do a bit more reading on this. 17:01:07 torsocks does similar LD_PRELOAD tricks to intercept network function calls, I think 17:01:54 go often just run system call directly 17:01:56 I don't think go statically links libc (when at all), but for many things they have their own implementation instead of using libc 17:02:02 anyway, that is a detail, the problem is the same 17:02:22 That's the price they pay for the checkmark in the "Unmodified Binary" column in Table 1. Protozoa had to change the application source code, evidently. 17:04:42 okay, is there anything else we wants to discuss in this meeting? 17:04:55 thanks for the answers! 17:05:11 i think an interesting questions with this line of research is how fine grained to do the traffic replacement 17:06:22 I will send the content of pad to the mailing list after this meeting. 17:06:36 as we have always been doing 17:06:50 so it should be possible to get away with not presharing files, if you're willing to parse things at a finer level 17:06:58 and inject stub frames at the receiving side 17:07:42 if you're careful, these audio/video frames will be valid and still play correctly (just not with the original sound/images) 17:08:12 this was a route we were looking at with slitheen 17:09:02 hm, interesting, yes you can say that for "leaf" resources you don't have to reproduce the input precisely 17:09:07 but there's a tradeoff here with the complexity of the parser and how true you are to the original traffic patterns 17:09:10 yup 17:09:21 i did some work on making extensible stub frames 17:09:59 we got it so that e.g., youtube playback "worked" for slitheen 17:10:10 but the playback was a blank white frame with null audio 17:10:28 which doesn't matter of course because it's cover traffic 17:11:09 before the meeting ends I'll say that I'm not sure about LD_PRELOAD not working for Rust programs; the binaries are statically linked for the most part, but they may still link dynamically with libc. I'm not sure of the details. 17:11:36 blank white video 10 hours (extended) 17:11:55 somehow has 43M views 17:12:14 XD 17:12:19 hahahaha 17:12:23 lol 17:12:56 i haven't had much time to work on slitheen adjacent stuff for a while 17:14:37 Yes... a lot of research project will be left there once published 17:14:45 this includes utls... 17:15:48 okay last call for any additional content for this meeting 17:17:03 #endmeeting