18:00:51 #startmeeting anti-censorship checkin 2020-02-20 18:00:51 Meeting started Thu Feb 20 18:00:51 2020 UTC. The chair is cohosh. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:51 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:00 thanks cohosh! o/ 18:01:07 here is our meeting pad: https://pad.riseup.net/p/tor-anti-censorship-keep 18:01:38 okay starting with discussion, the one about translations was from last week so i removed it 18:01:52 oops i misfiled my link 18:01:52 the next one is about binary size, was that also from last week or do we have an update on that? 18:02:40 oh it's removed alright so no discussion/announcements today? 18:02:59 because it was from last week 18:03:06 ah thanks gaba 18:03:31 it seems we may not have discussion items? 18:03:33 dcf1: anything you want to discuss re: snowflake and turbotunnel? 18:04:00 I just wrote up some first impressions at https://trac.torproject.org/projects/tor/ticket/33336#comment:11 18:04:32 I'm going to recommend the experimental bundles to amiableclarity and maybe whatever cypherpunks are reading tor-talk. 18:04:52 nice! 18:05:25 this is making the snowflake dogfood much tastier 18:05:45 yeah it's somewhat usable, though still not as nice as I would like. 18:06:10 * cohosh nods 18:06:23 Occasionally your proxy disappears and then you may get stuck for several minutes with no feedback, or even get tor into the dreaded "No running bridges" state. 18:06:59 the multiplexing should help with that 18:07:27 maybe we should look into the no running bridges problem as well 18:07:30 yeah at least now it is plausible, though occasionally frustrating, to run a Snowflake browser all day 18:07:31 i don't think we have a ticket for that 18:08:14 I think there are many tickets that mention it but it's never been gotten to the bottom of 18:08:27 This experience with Snowflake is definitely not the first I've seen it 18:09:04 Even without pluggable transports, I occasionally need to briefly activate obfs4 then deactivate it, to get tor to reset something internally and start working again. 18:09:22 hmm interesting, i did not know about the problem with obfs4 18:09:45 It's not a problem with obfs4. That's just a conveniently available option that changes tor's state somehow. 18:09:55 i knew there was an issue with meek and local addresses (0.0.3.0) discussed at one point 18:09:58 ah ok 18:10:00 * phw wonders if ahf has any insight regarding the above 18:10:05 Makes tor change its guard context from "default" to "bridges" or something. 18:10:31 * arma2 catches up on backlog 18:10:57 Here's one comment on "No running bridges" (it turned out to be a false lead in that case, but there are links to others) 18:11:00 https://trac.torproject.org/projects/tor/ticket/28717#comment:11 18:12:14 the 'no running bridges' thing happens, i believe, because tor marks your first hop down if a circuit build fails before it gets its 'created' response. and that's smart for relays, and maybe smart for obfs4 style bridges, and definitely not smart for the hack where you have one bridge line that is secretly many bridges. 18:12:27 yeah it seems to me that #11301 was never really fixed 18:12:58 "Sometimes, after this problem has happened once, tor will cease building circuits even if the network remains available." certainly describes it 18:13:16 in theory tor is supposed to, when it gets a new stream request and all its guards/bridges/whatevers are down, mark them as retriable and give it another go. but i bet it does not do this reliably. 18:13:43 Anyway I don't think this is specifically related to the turbotunnel changes, except that the pluggable transport can now run long enough for the problem to become visible sometimes 18:14:00 my first thought is to argue for a flag or config option or something that says "this is not the kind of bridge that you can mark as being unreachable. just don't do it, tor.' 18:14:24 right 18:14:40 mhmm. thanks for the insight, arma2. 18:14:56 i'm trying to track down that ticket dcf1 linked once that talked about strategies for using multiple local addresses? 18:15:00 I've never been able to characterize the problem enough to make a useful bug report. 18:15:01 i think it was a meek ticket 18:15:07 and it would apply to meek and to snowflake, because those are the ones that use the "one bridge is secretly many bridges" hack 18:16:36 though, hm. we might want to instead replace it with...something...that would let tor realize that things are really not working. 18:16:39 this may be something we can hack around in the short term by increasing some timeout threshold in tor or something? 18:17:49 snowflake-client would signal a fatal error by closing its SOCKS connection, but I think tor is timing out or something earlier than that. 18:17:59 i am also curious about this timeout that seems to happen. specifically what is it and where does it live 18:18:09 it would be the "when do you give up on a circuit that is being built" parameter if so. 18:18:17 i kept running into it in #29206 18:18:47 periodically tor looks at all its pending circuits, and gives up on the ones that have been pending building for too long 18:18:48 cohosh: is #10429 the ticket you meant about multiple local addresses? 18:18:55 dcf1: yes, thanks! 18:19:06 and if a circuit it just gave up on never even made it to the first hop, it takes special action to blame that first hop 18:19:30 the goal is so it can rotate to a new entry guard if its current guard is being faily 18:19:33 i see 18:19:45 * ahf reads 18:20:06 I can see this happening with turbotunnel, even though technically tor doesn't see the circuit construction failure except by timeout. 18:20:12 and for bridges, if you have 10 obfs4 bridges, this is a solid feature still. you want to avoid even trying the ones that were failing. 18:20:20 That is, as long as proxies are reliable, you can switch between them and tor never even knows about it. 18:20:48 But when you hit a snag and there's a delay of a few minutes, then probably tor times out its circuit, then immediately tries to create a new circuit 18:20:52 yeah. from tor's perspective, it will be like "la la, not enough preemptive circuits, time to make a new one. woah, the new one failed -- and it's the bridge's fault!" 18:20:54 dcf1: maybe this is tor browser's socks proxy timeout then? 18:20:58 phw: nope, don't have a good answer to that one :-/ 18:21:18 Then, because there's there's still no available proxy, this new circuit construction fails at the early stage, leading to the aforementioned special behavior 18:21:43 ah i see 18:22:15 yep 18:22:23 so yes, maybe we can ameliorate the situation by tweaking some parameters in tor. It would also help if we could find out why such a large fraaction of snowflake proxies seem to just not work. I think cohosh had a ticket about that. 18:22:39 yeah i have some ongoing measurements 18:22:47 honestly, it seems to be doing a bit better lately 18:23:03 yep. i would suggest two hacks on the tor side: (a) loud logging when tor gives up on a first hop. so you know when tor made that choice and what choice it was. (b) a toggle switch to make tor never actually give up on the thing. 18:23:08 #32545 18:23:30 people wouldn't want to turn (b) on for normal use, because it would have bad side effects for all your non-snowflake use. but it would help in debugging this issue. 18:24:22 cohosh: speaking of snowflakes that don't work. do snowflakes check if they can reach the bridge, before advertising themselves as usable? i ask because i saw 45 snowflakes in china, where the bridge is blocked. 18:24:31 arma2: yes they do 18:24:34 great 18:24:48 they don't poll if they can't reach the bridge 18:25:03 that's actually how we found out about the recent bridge failure lol 18:25:12 but there's something else going on as well 18:25:12 good stuff 18:25:25 i am hoping to write up some results this week 18:25:29 dcf1: ok. i am finally taking a break from this nsf proposal (and handing it to cohosh), 18:25:46 so i will aim to do up my two hacks and give them to you in the next day or two (ha, famous last words) 18:25:50 and you can see if they make you happier 18:26:15 sure arma2 thanks, if you give me something I will try it. 18:26:28 let's make a ticket for it so we can track what works 18:26:33 it will be in the form of a diff on tor source code. which version of tor do you like? 18:26:40 i'm sure many people would be interested in this 18:27:05 0.4.3.2-alpha is the version in tor-browser-build that I used 18:27:21 sounds good 18:28:03 thanks for the discussion everyone 18:28:09 thanks 18:28:38 okay should we move on with needs help with? 18:29:01 i might be the only one in need of reviews 18:29:07 i can ping hiro about that later 18:29:15 (dcf1: also, for normal tor relays, they auto recover after a few hours, because the new consensus resets their "are they working" state. so there is automatic forgiveness built in, which bridges don't get.) 18:30:15 cohosh: are you looking for any feedback on #32938? 18:30:32 dcf1: not yet, i'll have something for next week 18:30:37 ok 18:30:37 unless you have some feedback to give now 18:30:43 on the general idea 18:30:49 that is welcome ofc 18:31:02 cohosh 18:31:07 I have that in my radar for today 18:31:08 hiro: hey! 18:31:12 I am going to do it tonight 18:31:25 ok, thanks! i have a few gettor reviews, i can add you as reviewer for them 18:32:19 alright, anything else? 18:32:43 i'll end the meeting in a minute if no 18:33:34 okay thanks everyone 18:33:37 #endmeeting