15:59:18 #startmeeting tor anti-censorship meeting 15:59:18 Meeting started Thu Feb 10 15:59:18 2022 UTC. The chair is meskio. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:59:18 Useful Commands: #action #agreed #help #info #idea #link #topic. 15:59:22 Hi~ 15:59:23 hello everybody 15:59:25 hi 15:59:36 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 15:59:47 feel free to add what you've been working on and put items on the agenda 16:00:52 hi 16:01:13 we have one point in the agenda for now, about SOCKS interface in snowflake 16:01:34 dcf1 you around? we might need your opinion for that point 16:01:45 https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/merge_requests/64 16:01:46 I am here 16:02:03 I can make any necessary change to get it merged 16:02:08 or we can close it 16:02:34 the current issue with it is when used on MacOS/iOS there will be DNS Leak 16:02:54 And there is a lot of changes to the code base 16:03:10 For this non-essential function 16:05:34 logs from the last time we discussed this in this meeting: http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-12-02-15.59.html 16:07:40 i think we reached an impasse because the changes were a bit disruptive, and we're unsure of whether we can get 100% of the traffic going through the proxy? 16:08:36 100% will be tunneled with proxy on non-iOS/Mac environment 16:08:47 100% of traffic will be tunneled with proxy on non-iOS/Mac environment 16:09:28 we can make additional change prevent dns leak on Mac/iOS 16:09:29 okay, and on ios/mac there will be unexpected behaviour because of domain name resolution? 16:09:32 i see 16:10:38 Yes, that is true to the best of my knowledge 16:11:47 so the main issues left here are that the changes to get it working on ios/mac are intensive 16:12:05 and that this will only work for a small number of clients anyway 16:12:19 could we just add a big warning on those platforms? 16:12:44 Yes, however most of Chinese proxy software support UDP over Socks5 16:15:48 Although these proxy will allow user to use uncensored network by itself 16:15:49 the DNS leak is for the domain front domain, isn't it? 16:16:12 No, it is for STUN server 16:16:20 ahh, I see 16:16:33 still, should not be an incriminating domain 16:16:44 did we discuss using IP addresses for stun servers and whether that would work? 16:17:01 sure, is not great to have that leak 16:17:34 I think the problem was internal packet forwarding loops? https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/-/issues/40069#note_2753859 16:18:23 The original reason for requesting proxy support was as a technical workaround, buy centralizing all a process's packets in one forward SOCKS port, all that process's packets could be easily identified. 16:18:37 dcf1: iOS have relaxed restriction on software so socks5 is no longer a blocker 16:18:57 "leaf could route traffic based on port numbers or address ranges." e.g. 16:19:29 There is used to be a 15 MB restriction on network extension memory usage 16:19:45 this restriction have been increased to 50 MB 16:20:01 So the technical issue was not DNS leaks per se, but the fact that some of Snowflake's packets (which are supposed to be exempt from the Network Extension) would end up circularly being forwarded back to the Network Extension 16:20:04 so iOS app no longer rely on SOCK5 to work 16:20:22 at least in the design that guardian project had set up 16:20:54 as shelikhoo says, this technical workaround is no longer needed on iOS 16:22:09 Yes, so this is just for those who need to use a SOCKS5 proxy 16:25:48 okay so regardless of whether or not this is needed, if it was implemented, would we still get these weird loops on iOS? 16:26:21 Currently yes, but I can make additional change to solve this 16:27:15 okay so we're still at the issue we had before which is the additional changes are intense and we don't know if they are worth it for the feature 16:27:57 Yes, I believe in fact this the only hard issue here 16:29:24 I think would prefer to keep it simple, document clearly the leaks or try other work arounds (like using IP addresses for stun servers) 16:30:03 shelikhoo: are the macos/ios changes already in the MR? 16:30:16 when we say 'intense' how long it would take to implement the additional changes? 16:30:35 cohosh: no, but it won't be hard 16:31:15 intense means there is a lot of change to the code, but I think it will take less than 8 hours to get iOS/Mac working 16:32:16 shelikhoo: i see this in the MR: 16:32:18 On some operating systems, Go standard library will ignore programmer's setting and always use System DNS resolution resulting in DNS Leak. We need to add this to documents. 16:32:27 is that still the case even with the change? 16:33:07 no, once I use a 3rd party library, this issue will be solved 16:33:46 okay, i think it would be helpful to see what the changes look like and then make a decision 16:33:52 especially if it won't take that long to try 16:34:27 it would also be helpful to know whether we can just fix this at the source by using IP addresses instead of domain names for stun servers 16:34:36 i suppose that will make the network traffic look different 16:35:40 I think a lot of stun server just solve to one IP address 16:35:46 so long as that address does not change 16:36:03 then there should have no issue with replacing it with IP 16:36:15 we do configure multiple servers, if one doesn't work the others should 16:36:19 I don't think there is a SNI like thing in STUN 16:36:28 cohosh: Yes 16:37:10 in the past I did manage to make go use my pinned IP address and keep the SNI header, but probably not needed for STUN 16:37:49 No, I don't think domain name is used in STUN protocol 16:37:54 :) 16:38:24 (I did that to avoid leap VPN being blocked in Iran, to discover they did block it by SNI and not DNS...) 16:38:58 shelikhoo: okay, let's see what the changes look like if you're okay with spending another 8 hours on it? 16:39:07 Yes! 16:39:11 sounds good 16:39:20 I will get it working and see what we should do next 16:39:33 and then perhaps we can work with tla/guardian project to also try out the existing MR with IP address STUN servers to see if there is a leak that way 16:39:49 because if that solves our problem it would be a lot nicer 16:40:13 (as long as the changes in network behaviour don't get snowflake blocked, which seems unlikely) 16:40:24 thanks shelikhoo :) 16:40:40 great :) 16:40:45 Yes 16:40:48 no problem 16:40:58 anything else for today? 16:41:20 * meskio is starting to miss the bridge load balancing conversations... 16:42:21 a reminder: next week we have reading group https://censorbib.nymity.ch/#Bock2021b 16:42:31 oh! i have a thing 16:42:40 I think our current setup will work for a while, but we might wants to start to think what is the next step for snowflake server 16:42:49 i was asked to this: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/48 16:43:22 and i wrote up something, idk, let me know thoughts, i will close the issue in the few days if there's nothing to add 16:43:34 https://gitlab.torproject.org/tpo/anti-censorship/team/-/wikis/Processes/Emergencies 16:43:42 ohh, yes, I saw it in my long pile of emails today, is in my queue to give it some thought 16:44:12 in a fast review it looks good, thanks 16:44:13 thanks meskio! feel free to make changes directly 16:44:27 :) 16:44:38 Yes, this definition looks awesome 16:45:04 thanks! 16:46:09 if nothing else pops up I'll close the meeting in 1 min 16:47:20 shelikhoo: if you have ideas for scaling the snowflake bridge, I think the existing issue is https://bugs.torproject.org/tpo/anti-censorship/pluggable-transports/snowflake/28651 16:47:56 or open a new one if your idea is something different 16:48:07 Yes, dcf1 16:49:13 #endmeeting