15:59:23 #startmeeting anti-censorship team meeting 15:59:23 Meeting started Thu Jun 11 15:59:23 2020 UTC. The chair is phw. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:23 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:34 here's our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:59:46 hi 15:59:47 hi 15:59:51 hi 15:59:52 hi everyone 16:00:00 o/ 16:00:07 o/ 16:00:17 o/ 16:00:23 hi 16:00:24 Hi 16:00:32 today's announcement is that the trac -> gitlab migration is happening tomorrow, on friday 16:00:53 ahf sent an email to tor-project@ with everything we need to know about it 16:00:54 https://lists.torproject.org/pipermail/tor-project/2020-June/002866.html 16:02:06 hi 16:02:27 that's it for today's agenda :) anything else on anyone's mind? 16:02:53 there's the ooni internet measurement village talks 16:03:08 if anyone wants to join they are public 16:03:08 cohosh: yeah 16:03:15 https://ooni.org/post/2020-internet-measurement-village/#schedule 16:03:50 nice 16:04:09 Hi, I'm thinking of helping our for some small tasks similar to hanneloresx , are there any for me to take care of? (I studied BridgeDB and Twisted a bit in preparation for google SoC, so I could help for some small things there too) 16:04:45 juggy: awesome :) 16:05:33 i'm currently working on a distributor for gettor and i'm close to bringing up an "initial" version of the bot public in a few minutes. 16:05:51 do any of you have accounts on telegram right now? 16:05:54 juggy: by similar, do you mean translation tasks or are you looking for coding tasks? 16:06:06 Coding tasks :) 16:06:19 Originally I wanted to help beef out the docs with some sort of technical overview of BridgeDB for laymen, but there are talks of re-architecting it? So not sure if that would be the best use of my time 16:07:22 ah yeah this is a bit tricky since we are trying to decide how to move forward 16:07:51 (also nice work AlwaysLivid on the telegram distributor :D) 16:08:15 juggy: if you're interested in continuing to work on bridgedb, then i can compile a small list of tickets that can get you started 16:08:19 juggy: i think bridgedb (the current version) will still exist for a while even if we decide to work on a replacement 16:08:49 Bringing the bot live in a second. 16:08:56 phw: Thanks, that'll be great! 16:09:02 cohosh: Ah 16:09:40 It works! 16:09:41 juggy: i think the technical overview would still be useful. someone recently pointed out the sorry state of our current docs: https://blog.torproject.org/comment/288198#comment-288198 16:10:26 a good place to put extra documentation would be bridgedb's info page at https://bridges.torproject.org/info 16:10:43 but focus on whatever you find interesting. if that's programming instead of documenting, then that's totally fine 16:11:14 AlwaysLivid: :D can you update #22011 with info on how to try it out? 16:11:22 Hmm, I guess I could do programming tasks, and along the way gain enough knowledge to beef out the docs 16:11:38 cohosh, right now, I'm not hosting it on a server or anything, so I doubt that it'll be reliable in any way whatsoever. 16:11:40 juggy: sounds like a good plan! these things go hand in hand anyway 16:13:37 AlwaysLivid: that's okay. whatever updates/code you have would be great to see on that ticket 16:14:02 hanneloresx: hi! how's your "reading up on things" going? anything that we can help with? 16:14:47 Good. I just pushed a latest commit. I had a few interesting ideas regarding gettor and I think I've kept up cohosh up to date about them, not sure if this is interesting enough to the channel. 16:15:00 small point of order: I have someone trying to join for the reading group using https://webchat.oftc.net/?channels=tor-meeting , but it says "Cannot join channel (Need to be identified and verified to join this channel)" 16:15:51 phw, thanks for asking! i tried read up on everything on our pad and team page and all the links haha, so at least i know where all the info live now 16:16:05 dcf1: that may be a (temporary?) anti-spam thing. arma2: ^ 16:16:36 i took a look at our blog, seems straightforward enough, if you can send the June one to me in draft I can aim to translate with 2-day turnaround 16:17:18 agree that we could use more documentation for lay people though :) so happy to help on that front, too 16:17:39 maybe even tutorials or the like 16:17:45 hanneloresx: very nice, thanks! i've been working on a blog post that summarises the state of tor in china, ie, what it takes to get it to run. that would be a perfect post to translate too 16:18:24 perfect! please feel free send to me when you've got a draft. I'll email you so you have my contact 16:18:33 (we should also have a plan for where to publish it. blog.torproject.org won't be very helpful because it's blocked in china) 16:18:36 will do, thanks! 16:18:42 dcf1: it could be that the nick needs to be registered first to be able to join 16:18:42 AlwaysLivid: a good first place for gettor design ideas will be in tickets. we have this gitlab migration over the weekend so that might make it a bit chaotic until we've ironed out the gitlab workflow 16:19:05 understood 16:19:09 dcf1: i asked internally to lift the requirement, but am not sure how quickly that will be addressed 16:19:25 i think one of gitlab's biggest advantages is their integrated ci/cd 16:19:35 i think that's available in free tiers as well iirc 16:19:56 would be interesting to think how one could take advantage of that, considering that there are mechanisms put in place already 16:20:00 (afaik) 16:20:14 dcf1: here's the beginner resource on how to register https://trac.torproject.org/projects/tor/wiki/org/onboarding/IRC#Advancedbeginners 16:21:58 hi, can i quick update on some ux stuff for s30? 16:22:09 antonela: yes, i was about to ask. please do! 16:22:24 thanks for your review on #31282! i'll bring this to the browser meeting next week so we can get some reviews from the browser folks before moving forward. Given that this team capacity has been intact and the browser one has been reduced, i want to make sure we agree on what is doable for the next stable release 16:22:45 about #32811 besides the notes from the interviews, duncan did an amazing job linking ooni reports from the targeted countries to backup the information we are actually rendering in the profiles 16:22:52 it is a work in progress and he will probably join this meeting next week to share the progress and open it for feedback. 16:23:00 this one #31283 needs review and i wonder if you have any thoughts on it or if we can move forward with that framework/scope 16:23:07 and 16:23:13 also this week, as part of S58 i discussed with sysrqb how we can have a better workflow with tba bundles to improve the way we are calling for testing 16:23:20 I want to have this workflow in a good place for when we are going to call for testing for snowflake in tba 16:23:31 which we discussed to run after the tb release, probably this month 16:24:01 (i commented on #31283 yesterday) 16:25:34 okey, is the other one #31282 \ 16:25:43 tba = tor browser alpha or tor browser for android? 16:25:51 tor browser for android 16:25:53 okay, i'll take a look at #31282! 16:26:20 awesome, thank you 16:27:03 what meeting log should i read to catch up on your workflow discussion? 16:27:30 this one http://meetbot.debian.net/tor-meeting/2020/tor-meeting.2020-06-09-16.02.log.html 16:29:02 antonela: nice, thanks for reaching out about the workflow 16:29:58 is good, i hope we can make it works 16:30:49 ok, so my todo list is 1) read the workflow log and 2) review #31282. is there anything else antonela? 16:31:22 if you want to read our progress in personas, there is a wip .csv file on what we are thinking are the profiles emerged from the interviews 16:31:38 as i said, duncan will probably join us here next week to share a first version for review 16:31:44 where can we find the .csv? 16:32:03 https://trac.torproject.org/projects/tor/attachment/ticket/32811/new-persona-notes.csv 16:32:10 thanks 16:33:02 np 16:35:00 ok, anything else before we move on to assigning reviews? 16:36:13 im groot 16:36:14 thank you 16:36:38 moving on to reviews. i have #33835 and cohosh has #34129 16:36:48 i think that's it. agix, do you mind taking another look at #33835? 16:37:17 already did :) finished with the review about an hour ago 16:37:19 (it's just a small revision + unit tests) 16:37:28 oh, nice! 16:37:34 I will look at #34129 16:38:10 thanks 16:39:01 we're done with our anti-censorship agenda for today. next up is our meeting group about v2ray. is there anything else to discuss before we start the reading group? don't be shy! 16:40:22 *crickets* means we should start with our reading group 16:40:29 I can lead the discussion on V2Ray 16:40:32 dcf1: did your guest manage to join? 16:40:33 thanks 16:40:39 Hi, I am xiaokangwang aka Shelikhoo. I am currently one of the developers maintaining the V2Ray project. 16:40:43 Yes I think we are connected now. 16:40:49 Shelikhoo: very cool, welcome! 16:40:57 We are honored to have Shelikhoo with us, who knows more about V2Ray than I do. 16:41:09 Let me paste a short summary and a few links to get started. 16:41:16 V2Ray (or V2Fly) is a platform for deploying proxy protocols. It is possible to configure it for circumvention purposes. 16:41:25 There's a basic summary here: https://github.com/net4people/bbs/issues/36 16:41:37 V2Ray has an interesting layered architecture, divided into "proxy" and "transport" layers. 16:41:45 You can compose any proxy (SOCKS, Shadowsocks, VMess...) with any transport (TCP, QUIC, WebSocket...). Some transports have their own additional obfuscation op 16:41:48 tions. 16:42:03 VMess was the first proxy protocol supported by V2Ray. It is an authenticated look-like-nothing protocol similar to ScrambleSuit, obfs4, or Shadowsocks. 16:42:18 There are currently changes being made to VMess in response to recently discovered replay / active probing vulnerabilities: 16:42:29 https://lists.torproject.org/pipermail/anti-censorship-team/2020-June/000104.html https://pad.riseup.net/p/64MatYTvPX5_xvPCF-uz 16:42:45 (end summary) 16:43:24 So one thing you may notice is that both the name V2Ray and V2Fly are used. My understanding is that this is due to a github/domain ownership problem, and that future work is going ahead under the v2fly organization. 16:44:34 Yes, that's right. The original developer of V2Ray disappeared with a lot of management rights with her. 16:44:45 There's a large and active development and research community around it. Discussion threads with hundreds of comments, etc. It can be hard to follow without being a Chinese speaker, but there is a lot happening, e.g. at https://github.com/v2ray/discussion/issues/704 16:45:27 I get the impression that v2ray is starting to fill the space occiped by Shadowsocks, as detection attacks against Shadowsocks get more sophisticated. 16:45:48 But really it's not a 1:1 comparison, as v2ray can use Shadowsocks directly, as one of its supported proxy protocols. 16:46:38 I had only heard about v2ray before; I tried setting it up for the first time this week. 16:48:02 while reading the faq at , i noticed the following feature: "Dynamic port: dynamically change the communication port to combat the speed limit of long-term large traffic port" 16:48:04 i didn't get through as much of the beginners guide as i wanted, but i'm curious about what this PAC is? is it some kind of proxy distribution system? 16:48:06 So our usual questions are: what can we learn from this? What short-term or long-term actions can we take? What future work is advisable? 16:48:17 v2ray already fill the space occupied by Shadowsocks 16:48:50 I didn't use any PAC when I set it up. My understanding is that a PAC file (proxy auto-config) is a configuration file for browsers that control what proxy to use for what sites. 16:48:59 ahh okay 16:49:15 PAC is used for traffic diversion. It's generally a JavaScript script telling browsers if a target is applicable for a proxy outbound or not 16:49:17 so similar to mass browser, because they are one-hop proxies 16:49:23 studentmain: I am curious about this. I have heard that there is a large market for SS resellers in China, who install SS on a VPS in Japan or wherever, and then charge for access to it. 16:49:47 studentmain: Do you know if those resellers are switching to v2ray? Or is it something people normally set up for themselves? 16:49:50 Sure. We call proxy service resellers "Airport" (机场) in Chinese. 16:50:19 ducksoft - then what do mac users call airport? 16:50:22 english? 16:50:29 DuckSoft: aha, so that's what that term means, thanks :) I saw it used at https://github.com/v2ray/v2ray-core/releases/tag/v4.24.2 16:50:54 yes, many reseller are using v2ray and trojan 16:51:28 Dynamic port is used to bypass some kind network restriction that ban ports that have large amount of unrecognized traffic(like VMess). 16:51:32 only a few of them are using original shadowsocks 16:51:48 trojan is https://github.com/trojan-gfw/trojan btw, TLS-based system. 16:52:00 it's a steorotype that "airports" using ss are low in tech, and v2ray & trojan ones are more superior, afaik 16:52:26 Shelikhoo: that's interesting. can i learn more about this somewhere? 16:53:45 "Airport"'s name maybe come form the icon of SS which is a paper plane 16:53:56 "Airport"'s name maybe come from the icon of SS which is a paper plane 16:54:35 You can look into the specs of vmess protocol: https://www.v2fly.org/developer/protocols/vmess.html 16:54:39 Is the dynamic port thing a "balancer" as described at https://v2ray.com/en/configuration/routing.html ? 16:56:48 dcf1: i don't think so. dynamic port is a command defined in vmess protocol. given by the server, the client may use the dynamic port provided by the server in the following T minutes. It's in the specs. 16:56:54 And now VMess is experimenting with a new cryptographic construction using AEAD, possibly to replace the AES-CFB that is used currently (whose malleability contributed to the recent replay vulnerabilities) 16:57:17 and if you can read Chinese, here it is: https://www.v2fly.org/developer/protocols/vmess.html#%E5%8A%A8%E6%80%81%E7%AB%AF%E5%8F%A3%E6%8C%87%E4%BB%A4 16:57:31 I haven't looked at the new AEAD docs yet. 16:58:48 I want to talk a bit about V2Ray's layered design, which is very interesting to me. 16:58:49 No, I it not an "balancer". Sever will push the necessary setting with VMess protocol, and client don't need to configure it manually 16:59:12 The v2ray program itself is very flexible and configurable. The "client side" and "server side" are the same program, just configured differently. 17:00:06 It's based on a general notion of "inbounds" and "outbounds". On the client, you may have a "socks" inbound and a "vmess" outbound. On the server, you may have a "vmess" inbound and a "freedom" outbound ("freedom" means no further proxying). 17:00:23 v2ray is a platform, all protocols are designed to be pluggable 17:00:35 Each inbound and outbound is made up of a layered "proxy" and "transport" 17:01:09 It's no arbitrarily composable, though, afaik you can only do `proxy | transport`, not `proxy | transport | transport`. 17:01:17 So no TLS-in-TLS or things like that. 17:01:38 In the past, the Tor Project had a mostly failed experiment for composition of transports: https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports#Combiningpluggabletransports 17:02:14 The proxy/transport divide makes a lot of sense, basically saying you can replace a TCP connection with any other sort of reliable stream abstraction. 17:02:58 There are still some weird features of how the layering in V2Ray works, though. For example, different layers can be responsible for the traffic obfuscation. 17:03:02 hmm cool 17:03:32 Like in `vmess | tcp`, you are relying on vmess to be undetectable. 17:03:43 (the proxy) 17:03:44 (proxy |)+ transport is allowed to bounce traffic between different servers, but only the last hop can use non-tcp transport 17:04:06 But in `socks | quic-with-wechat-obfsucation`, you are relying on the transport for obfuscation. 17:04:28 Shelikhoo: like a chain of proxies? I see, that makes sense. I did not realize it could work that way. 17:05:14 this is interesting and related to some discussions we've had about using conjure and/or snowflake with a variety of obfuscation methods 17:05:35 Anyway, what I'm saying is that I know that composition of these interfaces is non-trivial and has a lot of unexpected difficulties, and v2ray's approach seems pretty good. 17:05:53 cool XD 17:06:20 I am so glad we are able to bring together some different development communities. 17:06:24 Yes, it is designed in that way so you can chain your proxies. Mostly used to bypass ISP rate limit and use public proxy safely 17:06:45 QoS 17:07:03 Shelikhoo, and others with experience: do you know if any of the discovered flaws in V2Ray protocols were being exploited by the GFW before being fixed? 17:08:06 for mKCP, mostly yes, since mKCP cannot even survive within one day when deployed across the Great Firewall 17:08:08 https://gfw.report/blog/gfw_shadowsocks shows that GFW *is* doing active probing against Shadowsocks, maybe it is already happening against V2Ray protocols too. 17:09:01 I don't have time to run the experiment this time, but we used to receive replay traffic long before this 17:09:08 Yes, we detected active probing on vmess protocol server, but we're not sure what's the payload 17:09:58 DuckSoft: ah, that's every interesting. mKCP is UDP too, not TCP, which is interesting because most active probing so far has been TCP. I noticed mKCP mentioned at https://github.com/v2ray/v2ray-core/issues/2542 17:09:58 If they are still probing, maybe we can tcpdump that 17:10:11 I mean, it's possible they're sending payload for shadowsocks to determine it's a shadowsocks server 17:10:42 The issue with mKCP is that it used to be encrypted before I patched it 17:10:43 studentmain: agreed, it may be that GFW cannot distinguish SS from VMess, for example, until it does some more detailed active tests. 17:11:04 We can get historical data from research for SS 17:11:04 studentmain: does the gfw block your vmess protocol server? or is it just probing? 17:11:10 The issue with mKCP is that it used to be UNencrypted before I patched it 17:11:51 personally I use shadowsocks with AEAD protocol 17:12:12 It is even possible that some of the probes seen by gfw.report and https://censorbib.nymity.ch/#Ensafi2015b were intended for v2ray, who knows. 17:12:46 we can investigate it, as we have samples 17:14:01 studentmain: I think that would be very interesting. 17:14:27 GFW active probing was already surprisingly sophisticated in 2015 and has only gotten more capable since then. 17:15:34 I think that covers most of the topics I have in my notes. 17:15:38 Any replay against V2Ray must happen within 60 seconds, since V2Ray will take time into consideration, with at least 16 bytes of head unchanged. 17:15:53 V2Ray devs, is there any specific help you are looking for from outside, or what would you want others to know? 17:16:23 I am planning to take a look at the AEAD proposal for VMess and see if I notice any flaws. 17:17:51 Any additional audit is appreciated, since I am not the original developer of this project, there could have a lot of weakness that I can't discover by myself 17:18:26 FYI, v2ray (and shadowsocks) are designing next generation protocol 17:18:36 i'm curious about how users add new proxies they discover to the client-side software 17:18:38 Personally I will appreciate if we can bridge across different censorship circumvention systems using a shared protocol, such as SIP003 in Shadowsocks and PT in Tor 17:19:08 perhaps we can share some usability work there with proxy distribution 17:19:47 as i understand it, users must set up their own v2ray instance, right? the devs don't provide users with ready-to-use instances? 17:20:09 that's my understanding too 17:20:21 phw: or users buy access from an "airport" that sets it up for them. 17:20:22 Correct. Either you deploy it yourself, either you get the service from a 3rdparty provider. 17:20:24 but we've had our own usability issues with people adding private bridges 17:20:29 Yes, they need set up by themselves 17:20:48 I'm looking for the trac ticket about obfs4 improvements 17:21:06 No, V2Ray team just wrote the software, users have to setup it or buy one themselves 17:21:08 #30716 17:21:09 I was reminded of it because studentmain mentioned a next-gen protocol 17:21:13 thanks phw 17:21:43 If we publish one proxy, it could be quickly blocked by IP 17:22:03 "Airport"s are using a simple mechanism called "subscription". After a user purchased the service, the provider gives user a link with token, which, when requested, returing all the nodes available for the user in encoded plaintext format 17:22:25 Yes, it's interesting to me, the SS/V2Ray reseller system is markedly different from the BridgeDB system. 17:22:40 DuckSoft: thanks 17:22:49 If you don't know, BridgeDB is the Tor Project's system for distributing secret proxy addresses. https://bridges.torproject.org/ 17:23:23 You can request a bridge address through HTTPS, email, or a few other ways. There is no monetary charge, but the system tries to rate-limit requests to prevent enumeration of all addresses. 17:23:38 (and doesn't do a great job at it right now) 17:23:47 It is more successful against some censors than others; for example the GFW is good at getting addresses from BridgeDB. 17:23:56 Resellers are commercial system 17:24:27 The reseller model has some nice advantages, it's naturally more distributed, bridges cost something to acquire (you pay for a subscrition). 17:24:29 so is the idea that the GFW just can't track them all down/it's too expensive for them to subscribe to all of them? 17:24:45 Also provide an incentive to run proxies. 17:24:58 i wonder if these resellers struggle with having their websites blocked by the gfw 17:25:36 They just can't track all of them. 17:25:47 Yes and no. Airports nodes are being blocked from time to time, and the operators may use different techniques to circumvent that thing. 17:26:21 Old server 'died', they switch to a new server 17:26:24 If they change the address fast enough, it can't be blocked. 17:27:41 I wonder if the commercial model could be merged with a system like Salmon (we discussed last time, https://github.com/net4people/bbs/issues/33) 17:27:47 Same for reseller itself, old reseller 'died', there will be a new reseller then, it's profitable. 17:27:48 They can use a server in the wall as a "relay". Since proxy programs preserve no data in the disk, they simply can't get busted. 17:27:50 And some darker theorists believe these resellers provide user info to government so that they can run indefinitely 17:28:07 this ability to spin up new servers seems really crucial. our set of bridges ends up being very static 17:28:49 > If they change the address fast enough, it can't be blocked. 17:28:57 Yeah my impression is that part of the day-to-day operation of Psiphon, Lantern, etc. is just burning through addresses and rotating them constantly. 17:29:20 Do you mean the reseller will change the domain name and IP addresses of their websites from time to time? 17:29:31 That's a good word, "dynamic". "Airport" mode is in a dynamic loop. Emerged, grown, famous, busted, broken, reborn... 17:30:27 rg1: yes. they will change the panel domain from time to time, if the panel using to provide "subscription" itself was blocked. 17:31:01 Do people buy airport subscription on Wechat? Is it save to do wall-jumping business on Wechat? 17:31:05 *safe 17:31:11 :D 17:31:26 if not a commercial model, some planning on how to devote resources to keeping the IP addresses of proxies/bridges dynamic would be a huge improvement 17:31:55 I believe if we wants to follow that model, server should be set up on VPS that can change IP easily 17:32:49 yes, resellers get paid on wechat and alipay 17:33:16 Shelikhoo: interesting. 17:33:20 We are getting close to 1 hour of discussion, so we should finish soon. 17:33:22 They have special payment gateway to wash their money 17:33:37 I will summarize the main points of the discussion at https://github.com/net4people/bbs/issues/36 17:33:47 thanks dcf1 17:34:16 This has been a very stimulating discussion. I'm glad that so many experts could take part. We are really benefiting from your knowledge. 17:34:42 Thanks you, we have a lot to learn from you too 17:34:54 yes, thank you very much for your time and for answering our questions 17:35:55 i hope we can talk again in the future :D 17:35:59 this is awesome work 17:36:14 If there is any more questions, I can answer them on email 17:36:18 yes, looking forward to that too 17:36:18 1:37 am (China Standard Time) 17:36:33 Good night 17:36:43 o/ 17:36:51 have a good night! 17:36:54 We're working on same goal, we need more contact. 17:37:55 #endmeeting