15:58:33 <itchyonion> #startmeeting tor anti-censorship meeting
15:58:33 <MeetBot> Meeting started Thu Nov 17 15:58:33 2022 UTC.  The chair is itchyonion. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:33 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:37 <shelikhoo> hi~
15:58:44 <itchyonion> here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep
15:58:44 <itchyonion> feel free to add what you've been working on and put items on the agenda
15:58:45 <itchyonion> hello
15:58:52 <meskio> hello
15:59:27 <itchyonion> Looks like everyone's already updated their work items
15:59:50 <itchyonion> First topic in discussion:  security policy https://gitlab.torproject.org/tpo/core/team/-/wikis/NetworkTeam/SecurityPolicy
16:00:03 <meskio> I added that one
16:00:32 <meskio> there is some work being done to have a security policy for the whole organization
16:00:50 <meskio> like not the network team has this wiki page
16:01:07 <meskio> and the TROVE numbers to register incidents
16:01:20 <meskio> the idea is to extend it so it works for other teams as well
16:01:31 <cohosh> hi
16:01:33 <meskio> I think it will be pretty useful for anti-censorship
16:01:46 <meskio> we have recently handled several security incidents with obfs4
16:02:26 <shelikhoo> I think we should add one of our key and contact info to the contact page
16:02:28 <meskio> we'll need to review the policy from the network team, and see if we have proposals of changes to do to addapt it to our own needs
16:02:38 <meskio> like how does deofuscation bugs fit there?
16:03:27 <meskio> shelikhoo: yes, the plan is to change that, and have one single contact for all security incidents
16:03:43 <meskio> and that contact to be a list (or an alias) where we have people from all the teams that need to be there
16:03:52 <meskio> so, someone from ACT will be there
16:04:00 <meskio> but this is still in early stages
16:04:45 <meskio> so, if you want to have a look to the policy I'm happy to hear other comments, and I'll try to draft up changes for our needs and pass them around to review
16:05:26 <shelikhoo> there are more than one kind of software identification(deofuscation) vulnerability, like what if the CDN can see the bridgelines in plaintext, or when a network gateway can identify the anti-censorship tool
16:06:03 <shelikhoo> do we wants to have a lot of deofuscation categories
16:06:19 <shelikhoo> or a big one, plus a lot of smaller ones
16:06:23 <meskio> yes, I guess this is one of the hard questions
16:06:28 <shelikhoo> with different severity
16:06:41 <meskio> in the current policy they have different severity levels, will be nice to have an idea how they map to us
16:07:04 <meskio> but we don't need to have a full list of all the cases, obviously it will be a moving document that we can keep updating
16:08:20 <shelikhoo> Yes... I have no other comments...
16:08:23 <itchyonion> yea. the section title reads "What should I do if I find a security flaw in something Tor makes".  I wonder if something like a malicious relay count?
16:09:02 <meskio> itchyonion: maybe, I guess this is something the network health team will have to think about
16:09:49 <meskio> I just wanted everybody to know that this is happening and obvously I happy to hear feedback on it, nothing more from my side
16:10:50 <itchyonion> yes. So the actions from the discussion is: please read and review the doc, propose changes to include our needs if necessary?
16:11:04 <meskio> +1
16:11:24 <itchyonion> ok. Anything more on this topic?
16:11:28 <meskio> I can create an issue on our team repo for it
16:11:30 <meskio> EOF
16:11:55 <itchyonion> Next one:      domain fronting deprecation in azure https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/33#note_2853813
16:12:08 <shelikhoo> It finally arrives...
16:12:22 <meskio> yes, we have heard for years that azure will block domain fronting
16:12:37 <meskio> we got an email saying that there is a date for it: Nov 8 2023
16:12:46 <meskio> so we have a bit less than a year to do something about it
16:13:04 <meskio> we use azure domain fronting for meek
16:13:11 <meskio> but not for moat or snowflake
16:13:23 <meskio> (except for turkmenistan)
16:13:46 <meskio> I have some hopes that with all the improvements we are having on snowflake
16:13:56 <meskio> and with conjure and webtunnel on the working
16:14:07 <meskio> we will be able to deprecate meek by that time
16:14:29 <ggus> idk how useful is snowflake+meek in TM is at the moment: https://metrics.torproject.org/userstats-bridge-combined.html?start=2022-10-31&end=2022-11-17&country=tm
16:14:59 <cohosh> iirc in tm, there was a popular isp that was still not working with the domain front
16:15:09 <cohosh> and we think it's because of the STUN blocking
16:15:23 <cohosh> *with the azure domain front even
16:15:44 <meskio> ggus: doesn't look like it has much use :(
16:15:57 <cohosh> oof yeah that looks like 0
16:16:13 <meskio> so, our TM-azure fix didn't fix much
16:17:22 <shelikhoo> yes...
16:17:44 <itchyonion> so, do we have some immediate action items from this?
16:17:50 <meskio> unless someone has a better proposal I will reopen this conversation 6 months before azure starts blocking it, and we'll see if we need to find an alternative for meek or we can deprecate it
16:18:03 <meskio> (I had set a deadline in the issue for that)
16:18:27 <itchyonion> sounds good
16:18:28 <shelikhoo> I think we can try to find out who is still using meek, and why other method is still not working for them
16:18:54 <meskio> AFAIK meek is being used as last resort in many places
16:19:03 <meskio> is slow, but sometimes the only thing that works
16:19:27 <meskio> but conjure might fit that niche
16:19:41 <ggus> yep, it was useful in TM, for example
16:20:33 <meskio> mmm, conjure might not fit the TM niche, now that I think about it :(
16:21:13 <shelikhoo> TM's censor block ip blocks, if I recall correctly
16:21:38 <shelikhoo> so for conjure, that means the isp it run on it soon be inaccessible
16:22:16 <meskio> yes
16:22:49 <meskio> we can always decide to move meek to fastly, but we are putting all our apples in the same basket...
16:22:59 <meskio> (do that work in english?)
16:23:13 <itchyonion> i think it's eggs?
16:23:19 <meskio> :D
16:23:24 <itchyonion> lol
16:23:25 <ggus> i remember some obfs4 bridges running at universities that were working in TM
16:23:37 <shelikhoo> yes, in that way we are depending on fastly too much
16:24:22 <meskio> hopefully in snowflake we'll be using more and more other things besides domain fronting...
16:25:11 <itchyonion> Anything more on this topic?
16:25:27 <meskio> not from me, we'll talk more in some months
16:25:35 <shelikhoo> AMP is also something google can shutdown....
16:25:41 <shelikhoo> so..,
16:25:53 <meskio> yes :(
16:25:57 <shelikhoo> maybe we wants to look for something new...
16:26:01 <shelikhoo> EOF from me
16:26:22 <itchyonion> ok. Next topic in Interesting links:     https://news.ycombinator.com/item?id=33573477
16:26:22 <itchyonion> "It's been many years, and I am still angry and disappointed by Cloudflare's decision to block domain fronting and drop Lantern as a customer..."
16:26:50 <meskio> this is the hacker news post about the domain fronting being blocked in azure
16:27:09 <itchyonion> oh i see
16:27:13 <dcf1> it's just some interesting context on events that happened in 2015: https://news.ycombinator.com/item?id=9234367
16:27:43 <itchyonion> ok. Let's move on to the next one: WA-tunnel https://github.com/aleixrodriala/wa-tunnel
16:27:52 <meskio> yes, is a pity we can not do domain fronting in cloudflare :(
16:28:06 <meskio> about the wa-tunnel, I found it around, people moving data over whatsapp
16:28:22 <meskio> the idea is not for censorship circumvention, but to don't pay for mobile data
16:28:31 <meskio> (some countries have free traffic for whatsapp)
16:29:05 <meskio> I find it curious, maybe another alternative to domain fronting ;P
16:29:07 <meskio> ?
16:29:29 <ggus> meskio: we can check on OONI how whatsapp is blocked in some target regions
16:29:47 <shelikhoo> it is blocked in china BTW
16:30:19 <meskio> yes, I think it is blocked in many places, I was mostly joking, but I like how people get creative with those things
16:30:20 <ggus> https://explorer.ooni.org/chart/mat?test_name=whatsapp&since=2022-10-18&until=2022-11-18&axis_x=measurement_start_day&axis_y=probe_cc
16:31:09 <meskio> iran and china seem to block it
16:31:45 <meskio> but not kazakhastan :)
16:31:59 <meskio> ahh, wait I'm mixing it with TM
16:32:00 <ggus> tajikistan, yemen... probably places where people are using tor to use whatsapp and not the opposite :P
16:32:21 <meskio> TM is also blcoked
16:35:01 <meskio> nothing more from me on this topic
16:35:13 <shelikhoo> I don't think it would worth the cost of us actually shipping in tor browser, since the user will need to have a secondary mobile phone number...
16:35:45 <shelikhoo> and it is using nodejs
16:35:55 <dcf1> there have been many similar proposal and prototypes for tunneling over messaging systems, e.g. Facebook messenger, other zero-rated or even not zero-rated services
16:36:08 <shelikhoo> and don't work in china, iran...
16:36:14 <dcf1> it's pretty easy to make something like that work with a turbo tunnel design
16:36:55 <dcf1> because the reliability protocol does all the hard parts; you just need to define a way to encode packets into text messages (or whatever the service supports)
16:37:50 <dcf1> even easier than something like dnstt or meek, actually, because you don't have to poll: the other side can just send you a message whenever
16:38:16 <itchyonion> i think people used to do this with ssh tunnelling in China, but then GFW blocked it
16:38:46 <shelikhoo> this does remind us that we could use something like this with mqtt or other iot protocol
16:39:44 <shelikhoo> which would be easier for us to implement without external dependency
16:40:00 <shelikhoo> and blocking it would brick a lot of "smart" device
16:42:02 <shelikhoo> EOF for me
16:42:04 <itchyonion> hmm do these IOT protocol usually send a lot of data overseas? I think that's how they identify and block suspicious SSH traffic
16:42:46 <shelikhoo> we can use it as a control channel to supplement domain fronting
16:43:13 <itchyonion> i see
16:43:30 <itchyonion> I think that's the last topic we have. Just a reminder:  We will discuss "Measuring DoT/DoH Blocking Using OONI Probe: a Preliminary Study" on Dec 1
16:43:51 <itchyonion> if nothing else, I will end the meeting
16:44:04 <itchyonion> #endmeeting