15:59:00 <shelikhoo> #startmeeting tor anti-censorship meeting
15:59:00 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:59:03 <shelikhoo> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:59:19 <shelikhoo> Hi~
15:59:25 <meskio> hello
15:59:55 <keroserene> hi all
16:00:01 <itchyonion> hello
16:00:14 <shelikhoo> please add things you are working on
16:00:24 <shelikhoo> and things to discuss to the pad
16:04:35 <shelikhoo> okay now is the announce time
16:04:37 <shelikhoo> Next snowflake bridge migration scheduled for next week https://gitlab.torproject.org/tpo/tpa/team/-/issues/40716
16:04:48 <shelikhoo> thanks dcf1 ~
16:04:54 <meskio> nice \o/
16:05:48 <shelikhoo> is there something we need to discuss about this announcement? other than monitoring the situation when the transition happens
16:05:52 <keroserene> dcf1 amazing work!
16:06:31 <dcf1> 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 <cohosh> :D
16:07:48 <keroserene> 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 <dcf1> 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 <hiro> we still have the issue of the bridges with the same fingerprint
16:08:33 <hiro> yes that
16:09:28 <shelikhoo> okay, anything more on this topic?
16:09:35 <keroserene> ah, I see.  should we solve that sort of metric thing / is someone already on it?
16:09:38 <dcf1> 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 <keroserene> cool
16:10:19 <shelikhoo> okay, anything more on this topic?
16:10:55 <shelikhoo> Now move on to the discussion phase
16:10:56 <shelikhoo> Nickname for second bridge site? https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40122
16:10:59 <dcf1> 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 <shelikhoo> I have reorder the item now that we are already talking about that bridge
16:11:39 <dcf1> 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 <shelikhoo> sorry dcf1 I didn't mean to interrupt you....
16:11:50 <meskio> hehe, naming things, the hard problem in computer science
16:12:06 <dcf1> 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 <shelikhoo> Yes that's correct
16:12:18 <dcf1> The client will choose which bridge fingerprint it wants to use
16:12:30 <dcf1> So with a new fingerprint there should be a new nickname :D
16:13:14 <dcf1> 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 <dcf1> 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 <keroserene> guys, you know what we're doing? we're creating a snowstorm with all these snowflakes ;)
16:14:24 <hiro> xD
16:14:30 <shelikhoo> Yeah~
16:15:06 <itchyonion> ql`v`lp
16:15:12 <shelikhoo> Let's say Sr2's bridge name are like Sr2ZincReno
16:15:24 <shelikhoo> Sr2 is the family name
16:15:43 <shelikhoo> Zinc show the group of the bridge
16:15:45 <meskio> is the plan to keep with the snow names? powdery?
16:16:07 <dcf1> Hmm I like powder
16:16:20 <meskio> https://en.wikipedia.org/wiki/Classifications_of_snow
16:16:36 <shelikhoo> and finally each one have a final word that is different for each bridge
16:16:37 <dcf1> 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 <meskio> :)
16:17:41 <shelikhoo> Yes. let's paste name candidate and suggestion to the ticket
16:17:54 <shelikhoo> now move on to the next topic for discussion
16:17:56 <shelikhoo> Discuss about cooperation with Greatfire
16:18:22 <shelikhoo> keroserene do you wants to lead the discussion?
16:18:43 <keroserene> Yes, we had a great call with them a few hours ago
16:19:21 <keroserene> shel helped prepare a list of questions, and we went through as many as we could
16:19:41 <keroserene> the timezone over there is too late so they will follow up with more soon,
16:20:01 <keroserene> here's the initial notes q&a:  https://pad.riseup.net/p/greatfire-snowflake-notes
16:22:42 <keroserene> there was "martin", tech lead,  and one other greatfire dev on the call with us
16:24:33 <dcf1> It looks like the subject was collaboration btw tor and greatfire, specifically with FreeBrowser and Snowflake?
16:24:52 <keroserene> yes, one of the topics was FreeBrowser + Snowflake
16:25:49 <cohosh> 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 <keroserene> yes indeed
16:26:37 <keroserene> 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 <keroserene> capacity meaning the snowflake network & performance,  but also number of devs able to help the project
16:27:32 <shelikhoo> Oh? There are other interested projects? sorry for mistake in one of my email...
16:28:05 <meskio> yes, I know leap/riseup has being looking into it
16:28:22 <gaba> and we have collaboration with guardian project for them integrating snowflake
16:28:41 <cohosh> gaba: the guardian project situation is a little different because they are using snowflake + tor
16:28:45 <keroserene> 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 <meskio> 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 <cohosh> these other projects don't want to use it with tor (as i understand it)
16:28:59 <gaba> 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 <keroserene> I am happy to bring in more capacity
16:29:43 <dcf1> 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 <gaba> i see
16:30:04 <gaba> 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 <itchyonion> 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 <keroserene> gaba: yes let's sync up, and definitely we will have review process
16:30:36 <meskio> there are some troublesome answers in the pad, related to greatfire MitM all https traffic
16:31:00 <meskio> ups, I see itchyonion already raised the problem
16:31:33 <dcf1> 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 <dcf1> More lightweight and efficient, but you lose end-to-end security through the circumvention proxy
16:32:05 <keroserene> they may be open to improving it so it's actually e2e
16:32:09 <dcf1> That's just my guess, I haven't tried FreeBrowser
16:32:18 <meskio> but if they were using snowflake they would not need to do that
16:32:25 <keroserene> yes :)
16:33:10 <shelikhoo> Yes, I have confirmed that is is currently request to request proxy in the meeting.
16:34:08 <keroserene> meskio: agreed on public pool of proxies, where there are choices of which service
16:34:16 <keroserene> it gives the users the choice
16:34:32 <gaba> 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 <keroserene> understood on the current capacity at Tor,
16:35:38 <gaba> Sorry to say it again. I just want to be clear :)
16:35:44 <meskio> I agree, we should not do any development in our side beside being part of the planning and do code review
16:35:49 <keroserene> no problem :)
16:36:38 <keroserene> 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 <gaba> kerosene: can this proposed work be used by other projects too?
16:37:28 <keroserene> I believe so, it would extend snowflake into a more generalizable global circumvention tool
16:38:02 <gaba> ok
16:38:36 <keroserene> 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 <gaba> sounds good
16:39:49 <gaba> it would be fine to review and discuss any proposal
16:40:55 <shelikhoo> Okay, is there anything more on this topic?
16:41:30 <keroserene> the greatfire dev(s) will look more closely at snowflake soon and offer more feedback when they can
16:41:43 <keroserene> will keep everyone posted
16:42:17 <gaba> thanks
16:42:31 <shelikhoo> 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 <shelikhoo> this is a paper about transporting information by intercepting TLS connection and replace connection content based on defined rule
16:44:32 <shelikhoo> The author claims that this method make it traffic identical to original one other than minor timing difference
16:44:52 <dcf1> Balboa has some similarities to another paper we have discussed, Protozoa https://github.com/net4people/bbs/issues/55
16:45:20 <dcf1> Which also has some conceptual ties to the Overt User Simulator of Slitheen
16:46:05 <dcf1> 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 <dcf1> 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 <meskio> 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 <dcf1> 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 <cohosh> 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 <shelikhoo> Yes, we have always used that for debugging, but live hijacking is something quite new to me
16:47:55 <cohosh> in terms of practicality
16:47:58 <itchyonion> 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 <dcf1> 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 <cohosh> itchyonion: symmetric key cryptography is pretty efficient
16:49:20 <dcf1> 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 <shelikhoo> however on mobile platform this kind of tool is difficult to deploy
16:49:43 <meskio> 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 <cohosh> yeah the presharing of files to me was the biggest weakness of this design
16:50:28 <dcf1> 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 <cohosh> i don't think it's necessary
16:50:33 <shelikhoo> There are some work that solve this by attaching an extra compression layer
16:51:22 <shelikhoo> This will, however, increase time difference signature
16:51:41 <meskio> 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 <meskio> or you mean readucing the bitrate of the ogg files or something like that?
16:52:08 <dcf1> 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 <dcf1> *"the traffic model need NOT be a model of the entire..."
16:53:23 <dcf1> 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 <meskio> yes, their examples look like that
16:54:54 <meskio> 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 <meskio> or have some nice generative music...
16:55:47 <meskio> anyway the streaming example is a bit limited being mostly unidirectional
16:56:12 <meskio> and for their other example of http browsing, I'm wondering if is not a better idea to just use HTTPT
16:56:13 <dcf1> 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 <meskio> sure, I think is great people is putting time into it
16:57:11 <dcf1> 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 <dcf1> 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 <dcf1> The introduction and related work sections show a good understanding of the problem and solution space, I think
17:00:02 <itchyonion> 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 <dcf1> itchyonion: yes, the difference is dynamic vs. static linking
17:00:31 <meskio> itchyonion: go doesn't use libc (sometimes)
17:00:35 <dcf1> It's the same reason that torsocks does not work with Go or Rust binaries, because they are statically linked
17:01:03 <itchyonion> Interesting. Will do a bit more reading on this.
17:01:07 <dcf1> torsocks does similar LD_PRELOAD tricks to intercept network function calls, I think
17:01:54 <shelikhoo> go often just run system call directly
17:01:56 <meskio> 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 <meskio> anyway, that is a detail, the problem is the same
17:02:22 <dcf1> 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 <shelikhoo> okay, is there anything else we wants to discuss in this meeting?
17:04:55 <itchyonion> thanks for the answers!
17:05:11 <cohosh> i think an interesting questions with this line of research is how fine grained to do the traffic replacement
17:06:22 <shelikhoo> I will send the content of pad to the mailing list after this meeting.
17:06:36 <shelikhoo> as we have always been doing
17:06:50 <cohosh> 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 <cohosh> and inject stub frames at the receiving side
17:07:42 <cohosh> 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 <cohosh> this was a route we were looking at with slitheen
17:09:02 <dcf1> hm, interesting, yes you can say that for "leaf" resources you don't have to reproduce the input precisely
17:09:07 <cohosh> 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 <cohosh> yup
17:09:21 <cohosh> i did some work on making extensible stub frames
17:09:59 <cohosh> we got it so that e.g., youtube playback "worked" for slitheen
17:10:10 <cohosh> but the playback was a blank white frame with null audio
17:10:28 <cohosh> which doesn't matter of course because it's cover traffic
17:11:09 <dcf1> 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 <dcf1> blank white video 10 hours (extended)
17:11:55 <dcf1> somehow has 43M views
17:12:14 <meskio> XD
17:12:19 <shelikhoo> hahahaha
17:12:23 <cohosh> lol
17:12:56 <cohosh> i haven't had much time to work on slitheen adjacent stuff for a while
17:14:37 <shelikhoo> Yes... a lot of research project will be left there once published
17:14:45 <shelikhoo> this includes utls...
17:15:48 <shelikhoo> okay last call for any additional content for this meeting
17:17:03 <shelikhoo> #endmeeting