15:58:32 <meskio> #startmeeting tor anti-censorship meeting
15:58:32 <MeetBot> Meeting started Thu Jun 23 15:58:32 2022 UTC.  The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:32 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:36 <meskio> hello everybody
15:58:39 <meskio> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:58:49 <meskio> feel free to add what you've been working on and put items on the agenda
15:59:11 <meskio> first I have an announcement:
15:59:20 <meskio> next week is hackweek!!!!
15:59:35 <meskio> we'll not have this meeting over that week
15:59:35 <anarcat> exciting!
15:59:42 <shelikhoo> yeah!
15:59:52 <meskio> so our next meeting is July 7
16:01:08 <cohosh> hi
16:01:48 <meskio> I kept in the agenda the point about the fingerprint in snowflake from last week
16:02:16 <meskio> is there anything else to talk about it today?
16:02:22 <meskio> I mean on this topic
16:02:58 <meskio> shelikhoo I saw you created a buch of issues with ideas to do around that
16:03:34 <shelikhoo> arma and I have a discussion about this after last week's sync meeting
16:03:49 <shelikhoo> so there was 2 ideas
16:04:00 <meskio> I have put thos issues in the canvan board, I hope I did prioritize them right, but feel free to change them as I'm not sure I have clarity on the topic
16:04:33 <shelikhoo> first is create a test to show the connection result between different kind of proxy
16:05:04 <shelikhoo> instead of our current approach that cannot tell the difference between different kind of proxies
16:05:09 <shelikhoo> the second is that
16:05:21 <shelikhoo> create a connection feedback system
16:05:30 <shelikhoo> result feedback system
16:05:52 <meskio> great, and will you be working on this?
16:05:52 <shelikhoo> that allow client to report whether connection is successful
16:06:11 <shelikhoo> which will give us real world usage data
16:06:20 <shelikhoo> in addition to vantage points
16:07:22 <shelikhoo> I can work on this, but things like having additional brokers & machines that run browsers might not be a simple task...
16:07:34 <shelikhoo> (for the first idea)
16:07:42 <shelikhoo> so maybe we can have some discussion
16:07:53 <shelikhoo> about the exact way to proceed
16:07:58 <shelikhoo> before go ahead
16:08:05 <meskio> I see, so you are proposing to set up a test broker so you control what client connects to what proxy?
16:08:27 <shelikhoo> that is one way to move forward the first idea
16:08:40 <shelikhoo> or we will need to have multi-pool support at broker
16:09:50 <meskio> mmm, I'm worried that this will require a lot of effort
16:10:03 <shelikhoo> so regardless how we do that, this would require a lot of effort
16:10:12 <shelikhoo> so maybe have some discuss first
16:10:18 <shelikhoo> before go ahead
16:12:32 <meskio> I'm not sure what will be the best approach here
16:12:54 <meskio> will be nice that if we do that is something that we can reuse in the future
16:14:15 <meskio> do we have other options to investigate this problem?
16:14:31 <shelikhoo> right now I have a docker image to test distributed snowflake support, that will setup a separate server, broker, and clients
16:14:55 <shelikhoo> we can create something based on this
16:15:06 <shelikhoo> that do not includes long running machine
16:15:12 <shelikhoo> but this have the issue of
16:15:22 <shelikhoo> unable to detect the real world censorship
16:15:51 <shelikhoo> so maybe we can have a discuss at that issue first about all the options we have
16:16:05 <meskio> could we run the client in our vantage point in russia and the others in a temporary server somewhere?
16:17:02 <shelikhoo> that means we need to have something to spin up & down the server dynamically
16:18:24 <shelikhoo> we can do that, but that would take some effort
16:18:44 <meskio> I'm wondering if the effort is needed
16:19:19 <meskio> we could test valdkss patch or see another workaround pion upstream is providing (making the encryption algos configurable)
16:20:10 <shelikhoo> no meskio, I think these two ideas are more or less about long term monitoring about the connectivity
16:20:17 <shelikhoo> not about this particular issue
16:20:29 <shelikhoo> we already discovered supported_group censorship
16:20:35 <shelikhoo> so we can ask users to test it
16:20:40 <meskio> ahh, ok, that makes more sense
16:21:00 <meskio> yes, putting some effort on geting a nice testing infra I think is worth it
16:21:05 <shelikhoo> this two ideas are more about discovering censorship as soon as it happens
16:22:09 <meskio> do I understand correctly that we have two options here?
16:22:13 <meskio> * set up another broker
16:22:19 <meskio> * add multi-pool support
16:23:07 <meskio> we do want multi-pool support at some point, we could start working on it
16:23:26 <shelikhoo> yes, add brokers(one for a configuration) and its proxies
16:23:36 <shelikhoo> yes, add brokers(one for a configuration) and their proxie
16:23:41 <meskio> do you have any idea of the work needed in the multi-pool support?
16:24:01 <meskio> are we talking about a week of work or a month?
16:24:16 <shelikhoo> I need to do some research first. I can write a ticket about this as a start
16:24:24 <meskio> +1
16:24:42 <meskio> let's move it to a ticket and see after some research what it makes sense
16:25:12 <shelikhoo> yes. I will write my analysis in the ticket
16:25:31 <meskio> great, thanks
16:25:37 <meskio> should we move to the next topic?
16:25:56 <shelikhoo> nothing more from me in this topic
16:26:01 <meskio> snowflake spike on metrics
16:26:04 <meskio> https://metrics.torproject.org/userstats-bridge-combined.html?start=2022-03-24&end=2022-06-22&country=af
16:26:20 <meskio> I added there as ggus mentioned it in #tor-project
16:26:29 <meskio> but might be a bug on the metrics side
16:26:43 <meskio> there is a huge spike on every contry, that doesn't look normal
16:27:20 <ggus> https://gitlab.torproject.org/tpo/network-health/metrics/website/-/issues/40057
16:27:40 <meskio> ahh, good, we might not need to discuss anything here
16:27:41 <ggus> geko and hiro are taking a look ^
16:27:54 <meskio> I'm happy to help them if they need help
16:28:17 <meskio> thanks
16:29:07 <meskio> I see someone added a link to an issue in actions, I did assign it to myself, and plan to work on it over Q3
16:29:31 <meskio> is a bridgestrap issue for recognizing obfs4 version incompatibility
16:29:46 <meskio> anything else before we move to the reading group?
16:30:58 <meskio> for this week we have: Even Censors Have a Backup: Examining China's Double HTTPS Censorship Middleboxes
16:31:03 <meskio> https://dl.acm.org/doi/10.1145/3473604.3474559
16:31:50 <meskio> using generative algorithms (geneva) the found out there are more than one middlebox in the GFW
16:32:07 <meskio> I did propose it expecting to get some more inside on the GFW
16:32:25 <meskio> but I don't see much there that can be applied to us
16:32:48 <meskio> is pretty cool to see all the nifty networking tricks geneva is finding to avoid middleboxes
16:33:11 <meskio> and interesting to see how they do have duplicated infraestructure there
16:33:40 <meskio> I'm wonder if the blockade of bridges is also duplicated or just https traffic
16:34:11 <shelikhoo> yeah, there are existing tools to bypass censorship with packet manipulation, but we cannot easily incorporate them into tor browser
16:34:43 <meskio> and at least for the GFW they do often block by IP address and not DPI
16:34:52 <shelikhoo> https://github.com/850710247liu/TCPioneer
16:36:05 <shelikhoo> and
16:36:06 <shelikhoo> https://github.com/ValdikSS/GoodbyeDPI/
16:36:15 <meskio> yep, I was searching for that link
16:36:22 <meskio> people in russia uses that one
16:38:21 <meskio> something from the paper I didn't know is that they do monitor all ports for HTTPS/SNI packets, not just 443
16:40:53 <shelikhoo> yes...
16:40:54 <shelikhoo> these kind of TLS SNI censorship is quite easy to bypass so long as the device have raw socket access
16:41:29 <meskio> what do you mean with raw socket access?
16:42:05 <shelikhoo> can send L2/L3 packet directly
16:42:23 <shelikhoo> instead of use os tcp socket api
16:43:10 <meskio> ahh, you mean breaking the packets and all those techniques like GoodbyeDPI?
16:43:16 <shelikhoo> yes
16:43:34 <meskio> yes, is pretty hard to make DPI machines that reasemble packages
16:43:54 <meskio> is cheaper to expect the SNI part to be in a single package
16:44:50 <shelikhoo> no, sometime you can construct the packets in a way that make the middle impossible to parse the packets into a stream
16:45:05 <shelikhoo> but all of these would require raw socket
16:45:21 <shelikhoo> that mobile and ordinary user program does not have
16:45:30 <shelikhoo> that mobile app and ordinary user program does not have
16:45:59 <meskio> couldn't you use androids VPN API for that?
16:46:39 <shelikhoo> i don't think so, android VPN API only give you access to the tun interface, not the interface to internet
16:46:55 <meskio> ahh, I see, never played with it
16:47:36 <meskio> you could somehow DPI the packets over your tun interface and repackage them
16:48:06 * meskio is talking without a clear idea of how that works...
16:49:44 <shelikhoo> I think you have to send the crafted packet over internet interface...
16:50:31 <shelikhoo> at least for some countermeasures
16:50:52 <meskio> I see
16:51:34 <meskio> anyway, anything more on this paper?
16:51:42 <meskio> or should we finish the meeting?
16:51:55 <shelikhoo> nothing more from me
16:52:08 <meskio> great, I guess I can end the meeting
16:52:11 <meskio> #endmeeting