15:58:53 <shelikhoo> #startmeeting tor anti-censorship meeting
15:58:53 <MeetBot> Meeting started Thu Apr 28 15:58:53 2022 UTC.  The chair is shelikhoo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:53 <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:03 <shelikhoo> feel free to add what you've been working on and put items on the agenda
15:59:10 <shelikhoo> hi~
16:00:07 <itchyonion> hi
16:02:25 <meskio> hello
16:04:45 <shelikhoo> Okay, I think we can start with the meeting
16:04:55 <shelikhoo> the first section is announcements
16:05:04 <shelikhoo> polyanthum & gettor-01 will be upgraded next week, the servers where bridgedb,rdsys,gettor and other anti-censorship infra is hosted
16:05:31 <meskio> just to notice they will get upgraded to the latest debian stable
16:05:47 <meskio> I'm coordinating it with TPA to be watching that nothing breaks
16:05:55 <meskio> but please poke if you see some problmes
16:06:15 <shelikhoo> we don't have a rolling update, in which a set of inter exchangeable server are update in steps
16:06:31 <shelikhoo> so this will result in some down time
16:06:37 <shelikhoo> but this should be okay
16:07:02 <shelikhoo> we just need to make sure if something breaks after update
16:07:07 <shelikhoo> we should be there to fix it
16:07:29 <shelikhoo> so keep an eye on it during and after the upgrade should be enough
16:07:50 <shelikhoo> anything more on this topic?
16:07:55 <meskio> nothing from me
16:08:28 <shelikhoo> okay, now move on the the discussion part
16:08:31 <shelikhoo> Distributed Snowflake Server Support
16:08:50 <shelikhoo> I requested an internal testing of this change
16:09:02 <shelikhoo> I am aware it is working for meskio
16:09:19 <shelikhoo> and it is as expected works for me
16:09:32 <meskio> yes, first time I tried it didn't, until I noticed I was running both client and proxy in a restricted nat...
16:09:49 <shelikhoo> is there anything unexpected from anyone?
16:10:09 <shelikhoo> I am aware that rejection message for proxy maybe not there yet
16:10:30 <shelikhoo> so the proxy do not know why it is being rejected
16:10:43 <shelikhoo> is there any other issue discovered?
16:10:47 <itchyonion> sorry I didn't get around to test it. Got distracted by the s28 meeting and lost track of it.
16:11:06 <shelikhoo> it is okay
16:11:56 <shelikhoo> the issue here is that our update will require proxy to update their software
16:12:05 <shelikhoo> in an limited amount of time
16:12:13 <shelikhoo> without automatic update
16:12:32 <shelikhoo> we might wants to avoid this kind of thing happen frequently
16:12:49 <shelikhoo> so testing is necessary here
16:13:09 <meskio> could we first release the proxy code, ask people to upgrade and after some time upgrade the broker?
16:13:20 <meskio> so we have enough proxies with the support running around?
16:14:15 <meskio> I expect webextensions to upgrade fast as browsers do that automatically, but standalone proxies might take some time
16:14:37 <shelikhoo> no, the broker will be upgraded first, as is designed to deal with this kind of upgrade
16:14:53 <shelikhoo> we update the broker, then ask the proxy to update
16:14:57 <meskio> ahh, I see
16:14:58 <HugoArreNolifer[m]> upgrade broker for running both, and quiting one after time, switching to new at some occupation cos noise shouldnt be heard.
16:16:02 <shelikhoo> then we change the broker to reject old proxy
16:16:09 <shelikhoo> before we update the client
16:16:23 <itchyonion> :shelikhoo can you share the testing setup link again?
16:16:45 <shelikhoo> https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40129
16:16:47 <shelikhoo> it is here
16:17:05 <shelikhoo> I will proceed with this project without additional waiting
16:17:16 <itchyonion> 👍
16:17:18 <shelikhoo> but there is still chance to make comment or amendment
16:17:31 <shelikhoo> until we ask proxy operator to update
16:17:48 <shelikhoo> anything more on this topic?
16:17:53 <meskio> do we have already support on the webextension for it?
16:17:57 <shelikhoo> no
16:18:15 <shelikhoo> This is Implementing Web Proxy
16:18:21 <shelikhoo> part of the subtask
16:18:24 <shelikhoo> in that ticket
16:18:45 <meskio> I see it, thanks
16:19:03 <meskio> is looking good
16:19:15 <shelikhoo> Yes, other than it is a huge ticket...
16:20:08 <shelikhoo> Okay we can move on to the next topic
16:20:09 <shelikhoo> removed smallerRichard builtin server
16:20:11 <meskio> feel free to open other related tickets
16:20:18 <shelikhoo> yes... meskio
16:20:23 <meskio> I added that point to the agenda
16:20:50 <meskio> smallerRichard builtin bridge has being unreachable for months and the operator is MIA
16:21:14 <meskio> I started the process to remove it
16:21:36 <meskio> we'll need to find another builtin bridge to replace it, I'll poke ggus about it
16:21:53 <meskio> but we still have 14, so I guess is not a big deal if we live without it for a bit
16:23:31 <meskio> unless anybody has any comments on it, I guess is mostly an announcement
16:24:08 <shelikhoo> yes, anything more on this topic?
16:24:50 <meskio> not from me
16:24:55 <itchyonion> same
16:25:09 <shelikhoo> okay.... now we are moving to Reading group section
16:25:30 <shelikhoo> Blocking of HTTP/3 (QUIC) in Russia
16:25:30 <shelikhoo> https://dl.acm.org/doi/abs/10.1145/3487552.3487836
16:25:30 <shelikhoo> https://github.com/net4people/bbs/issues/108
16:25:44 <onyinyang> I just wanted to jump in to introduce myself at this point :)
16:25:46 <onyinyang> hello, I've attended the anticensorship meeting a few times in the past but usually stay pretty quiet. I've been working on a new bridge distribution system as part of my graduate work and i'm just starting out on a short project with the LEAP project to look into a UDP based censorship resistant pluggable transport which is related to this week's reading :)
16:26:22 <shelikhoo> Hi! welcome!
16:26:24 <meskio> onyinyang: wellcome
16:26:25 <itchyonion> :onyinyang awesome :)
16:26:47 <meskio> I'm curious to know more about both pieces of work, do you have any links for me to read?
16:27:20 <dcf1> onyinyang: is this the obfs4-over-KCP mentioned at the Pup Up PT implementers meeting?
16:27:22 <onyinyang> I'm still just getting familiar with the topic atm but I'm definitely interested in discussing this more going forward. Nice to meet everyone!
16:28:00 <dcf1> I am thinking of https://leap.se/git/leap_presentations.git/plain/2022-03-pt-lessons-learned/PT%20Presentation.pdf#page=16
16:28:19 <dcf1> which was in the context of https://www.pluggabletransports.info/blog/popup-ptim-leap-announcement/
16:30:01 <shelikhoo> I have no idea why they would use openvpn_tcp+obfs4-over-kcp
16:30:18 <onyinyang> dcf1: yes, I believe so
16:30:20 <shelikhoo> instead of something like openvpn_udp + https://github.com/wangyu-/UDPspeeder
16:31:01 <shelikhoo> which don't have head of line issue with TCP
16:31:24 <shelikhoo> or Packet in Stream issue
16:31:55 <shelikhoo> but we can move on to the reading group topic
16:32:10 <shelikhoo> anyone volunteer to summarize this paper?
16:32:30 <onyinyang> thanks for the links shelikhoo, I'll look into this
16:33:34 <shelikhoo> the second link is a discussion about an observed QUIC censorship in Russia
16:35:13 <shelikhoo> if you are typing the summary about paper please send out the first part....
16:35:36 <itchyonion> HTTP/3 is vulnerable to IP-based blocking, but overall it is less frequently blocked than HTTPS
16:37:18 <meskio> the paper does some mesurements on several censored countries to see if QUIC has being targeted by censors
16:38:12 <meskio> they found out some places like iran were it was blocked as they were basically blocking all UDP traffic to those hosts, but in most places or the censor was blocking all traffic to the IP address or QUIC was working
16:39:34 <meskio> reading the paper I was missing more information around what Iran is duing with UDP, how common is their blocking of UDP packets? do they block some IP addresses and most UDP works fine? are all UDP ports blocked or just some?
16:40:17 <itchyonion> "Thus, we believe that censors have deployed middle box soft- ware, which applies IP address filtering only to UDP traffic." I think this part is relevant
16:40:44 <dcf1> I think the authors leave that point open: Section 5.2: "Future work has to prove, if this filter specifically targets HTTP/3 traffic, i.e. UDP traffic on port 443, or UDP traffic to these IPs in general."
16:42:02 <itchyonion> "For each request pair, two measurements are performed sequen- tially, first using TCP, than using QUIC." This is how they test and I think it might introduce some bias. I've seen somewhere that GFW has a time-out policy: if you are suspected of connecting to a forbidden domain, then all your overseas connections will fail for a short while.
16:42:27 <itchyonion> because "There is no wait time between the two measurements"
16:43:09 <dcf1> itchyonion: that's a good observation.
16:43:11 <shelikhoo> we have moved to the first question naturally
16:43:11 <shelikhoo> What aspects of the paper are questionable?
16:44:10 <shelikhoo> if we were to do this experiment, we should run some experiment with QUIC first then TCP HTTPS then and other experiment TCP HTTPS first QUIC later
16:44:27 <shelikhoo> to see if there is difference in test result
16:44:27 <itchyonion> agree ^^
16:45:01 <meskio> I think they did a great first step, and created the tooling in OONI to improve those tests
16:46:55 <shelikhoo> Yes, but since QUIC also have SNI, it is not more censorship resistant
16:47:17 <dcf1> well, it is a little bit more resistant
16:47:46 <dcf1> SNI in QUIC is obfuscated, encrypted with a key that is effectively sent in the clear
16:47:46 <shelikhoo> dcf1: I know inserting packet won't work....
16:47:59 <dcf1> so middleboxes have to do more work to parse the SNI
16:48:07 <dcf1> https://www.ietf.org/archive/id/draft-ietf-quic-manageability-16.html#section-3.4.1
16:48:26 <shelikhoo> yes, more costly to block selectively
16:48:27 <shelikhoo> yes
16:48:32 <shelikhoo> I was wrong
16:48:32 * meskio wonders why they went that way instead of using ECH/eSNI
16:48:49 <shelikhoo> Issue is more or less about RTT
16:48:56 <meskio> is it just to make it easier to set up for providers?
16:49:14 <dcf1> meskio: it's not something specific to SNI, almost all parts of QUIC packets that are sent before shared keys are established are obfuscated in that fashion.
16:49:43 <shelikhoo> ECH or other ordinary TLS based protocol all need to send SNI info in the first client packet
16:49:50 <shelikhoo> encrypted or not
16:49:51 <meskio> interesting, I don't know much of QUIC
16:49:52 <dcf1> It's not intended as a real privacy measure, more an anti-ossification measure, as I understand it.
16:50:16 <shelikhoo> otherwise it will need to add an additional rtt
16:50:23 <shelikhoo> in protocol design
16:50:37 <dcf1> The key depends on the QUIC version, so middleboxes cannot pretend to understand a higher QUIC version than they actually understand
16:50:44 <shelikhoo> to run key agreement first, before sending actual data
16:51:32 <dcf1> (which has been a problem with TLS, middleboxes pretended to understand "TLS 1.3" when they really didn't, and broke tons of connections, which is why TLS 1.3 actually declares itself as TLS 1.2 plus a special extension indicating 1.3. they wanted to avoid a repeat of that with QUIC.)
16:52:02 <meskio> XD
16:52:20 <shelikhoo> so they design things in a way that reduce privacy but reduce rtt
16:53:00 <meskio> I see
16:53:04 <shelikhoo> okay let's move to the next question
16:53:05 <shelikhoo> Are there immediate actions we can take based on this work?
16:53:28 <dcf1> The 2017 SIGCOMM paper on QUIC is really good, I recommend it. It gets into a lot of these concerns about practical deployment realities. https://dl.acm.org/doi/abs/10.1145/3098822.3098842
16:53:29 <itchyonion> I don't know too much about QUIC either. I thought "established QUIC connections can not be easily terminated by an outsider" is interesting. So it has built-in resistance against reset attacks
16:54:35 <meskio> QUIC looks promising for anti-censorship, but it looks like we should wait for a wider adoption before start using it or we'll burn it
16:54:50 <shelikhoo> we are actually already using it
16:54:57 <meskio> how?
16:55:08 <shelikhoo> like V2Ray or hysteria
16:55:17 <shelikhoo> already have QUIC transport
16:55:24 <shelikhoo> or QUIC-mod transport
16:55:31 <dcf1> iCloud Private Relay is MASQUE which is QUIC
16:56:08 <shelikhoo> I think iCloud thing is more or less a VPN than anti-censorship
16:56:30 <dcf1> In this paper, they pre-screened the Citizen Lab test lists and the Tranco top 4000, and of those, 5% of domains had HTTP/3 support. But of course it is growing all the time.
16:57:40 <onyinyang> there was a pretty detailed paper on the QUIC protocol I started reading that I've found pretty helpful for undestanding how it works: https://eprint.iacr.org/2020/114.pdf
16:59:21 <itchyonion> 👍
16:59:34 <shelikhoo> Are there long-term actions we can take based on this work?
16:59:34 <shelikhoo> Is there future work that we want to call out, in hopes that others will pick it up?
16:59:40 <shelikhoo> Okay we are running out of time
16:59:52 <shelikhoo> anything about this two topic?
17:00:07 <meskio> I'm good
17:00:21 <itchyonion> same
17:00:34 <shelikhoo> we have already covered some of our idea about how to improve it should we do it ourself
17:00:37 <shelikhoo> okay
17:00:50 <shelikhoo> anything more we need to discuss in this meeting?
17:00:58 <shelikhoo> RKS hackathon
17:00:59 <shelikhoo> ?
17:02:55 <shelikhoo> any detail on this topic added into discussion section?
17:04:11 <shelikhoo> okay anything else?
17:04:54 <shelikhoo> #endmeeting