16:04:54 #startmeeting pts 16:04:54 Meeting started Wed Sep 24 16:04:54 2014 UTC. The chair is Yawning. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:04:54 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:05:16 Hihi, I see dcf1 and blanu, anyone else here for the pet meeting? 16:05:56 n8fr8: Are you around for the PT meeting? 16:06:01 *tumbleweeds* *crickets* 16:06:07 Let me talk. 16:06:11 I don't have too much. 16:06:12 go for it 16:06:12 Haha, oh yes! It was on my calendar thing. 16:06:19 Great! 16:06:28 oh good n8fr8 is here 16:06:29 karsten: Your 'if event.purpose == [tons of stuff]' conditional should instead be 'if event.purpose in (foo, bar, other thing):'. 16:06:45 I got meek working on Microsoft Azure, which is Microsoft's cloud thingy, kind of like AWS. 16:07:04 Similar pricing, flexibility, etc? 16:07:04 well done! 16:07:17 (Does it also set X-Forwarded-For?) 16:07:18 Yawning: can you have a look at my libscrypt_trunnel branch some time? It adds trunnel. 16:07:22 https://trac.torproject.org/projects/tor/wiki/doc/meek#MicrosoftAzure 16:07:24 https://trac.torproject.org/projects/tor/ticket/13189 16:07:32 nickm: after the pt meeting sure 16:07:38 The nice thing about Azure it it's going to be free for a year because I applied for a special grant. 16:07:40 thanks! 16:07:41 ah i'm here too 16:07:52 oh nice 16:07:56 The bad news is it won't be free after a year. 16:08:22 it's a trap! 16:08:29 So far I'm not sure we'll add it to the TBB with a "meek-azure", as long as meek-google and meek-amazon are working for people. 16:08:53 I think Azure is the most "industrial strength" of the ones we have working so far. 16:09:01 karsten: Your three lines around 'if id not in self.circuits: self.circuits[id] = Circuit(id)' can be replaced with one: 'self.circuits.setdefault(id, Circuit(id)).add_event(event.hs_state, arrived_at)'. 16:09:11 In the CDN world, App Engine and AWS are still regarded as kind of hobbyist affairs. 16:09:38 If you want to try it, the bridge line is 16:09:42 Bridge meek 0.0.2.0:3 url=https://az668014.vo.msecnd.net/ front=ajax.aspnetcdn.com 16:09:46 do you have a rough idea on what pricing will be after a year? 16:10:09 https://azure.microsoft.com/en-us/pricing/details/cdn/ 16:10:22 $0.12 to $0.19 per GB, about the same as the others. 16:10:34 dcf1: have you learned how much load that bridge can handle? like, 10k users from china? 16:10:49 karsten: Around 'isinstance(event, stem.response.events.CircuitEvent) or...' the isinstance() function can accept multiple types. For example: 'isinstance('hello', (int, str))'. 16:11:04 Which reminds me, I put out a call for an experienced bridge operator to run the bridge that the CDN forwards you to. 16:11:16 dcf1: on a kind of related note, the per-country per-pt usage stats is probably going to be a SponsorS deliverable :/ 16:11:17 did that work out? we can get one at waterloo or umn if not. 16:11:19 karsten: EOF. That's all I'm spotting off the top of my head. 16:11:19 I think we'll be fine on that front as I got a few replies. 16:11:32 atagar: wow, thanks! 16:11:42 (at least I put that in my e-mail to armadev) 16:12:05 I think the meek-server part of it will be fine, as Psiphon is already using it at quite a large scale. 16:12:42 Speaking of users, the other interesting thing we found is that it turns out your stats get mixed up if you run two pluggable transports on one descriptor. 16:12:48 https://lists.torproject.org/pipermail/tor-dev/2014-September/007483.html 16:13:08 I fixed that about a week ago for websocket and meek. 16:13:11 https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&start=2014-06-26&end=2014-09-24&transport=websocket&transport=meek#userstats-bridge-transport 16:13:21 See if you can guess where it changed. 16:13:43 karsten says the right way to fix the problem is to fix #8786. 16:13:57 But for now I just started running two tor processes 16:14:02 which actually is not even hard to do. 16:14:02 *adds to my list of stuff to do* 16:14:19 That is all I have to say. 16:15:11 Yawning, to answer your question about X-Forwarded-For, no Azure does not set it, because 16:15:48 you have to make your own outgoing connections (with e.g. Python, Curl); Azure's CDN is not one you can just point at an arbitrary domain. 16:15:52 It's like App Engine in that regard. 16:16:02 ahh gotcha 16:16:15 The Azure installation is running this WSGI: https://gitweb.torproject.org/pluggable-transports/meek.git/blob/e28a053e89b9fbdf83283203c26053a39fa72038:/wsgi/reflect.py 16:16:18 for my PT part: i've just been signed up to do a one-hour keynote this coming tuesday, at a gathering of darpa / academics in dc. 16:16:22 It also works great with Arlo's PHP. 16:16:35 the topic is "the arms race in censorship technologies" 16:16:42 oh boy 16:17:15 do you need anything from us for that? 16:17:57 i'm not sure yet. if you have something, yes please. :) 16:18:11 dfc: I'm just a happy little coder. 16:18:16 aight 16:18:27 So, we've moved Orbot over to 0.2.5.x so we can now do ScrambleSuit, I believe. Haven't done extensive testing on that front yet, but we will. 16:18:36 ok. 16:18:43 it should just work 16:18:53 I am still waiting/hoping/dreaming for QR code support on bridges.tpo to make it easy to provision 16:19:00 with the caveat that brridgedb is handing out bridges that do not work 16:19:05 due to missing password 16:19:13 ah 16:19:13 approx 1/7th of them will be broken this way 16:19:15 n8fr8: you might like #13213 (won't be in tor until 0.2.6 though) 16:19:36 n8fr8: do i remember correctly that orbot turns on 'disablenetwork' sometimes? 16:19:49 yes. there was an issue fixed with that recently? 16:19:56 n8fr8: oh, there was a blog question: where should orfox tickets go? 16:20:01 regarding circuit construction. 16:20:07 but it's something that we'll address and doesn't directly affect orbot. 16:20:50 * asn is around 16:20:59 i think i will file a bug to ask tor to automatically use 4 hops for unauthenticated bridges 16:21:04 oh good, tag, you're it I'm not that good at running theese 16:21:26 infinity0: that's an interesting idea. 16:21:27 #2764 16:21:35 probably covers that 16:21:40 at the moment, meek is using an unauthenticated bridge, which means an mitm between the user and the bridge can figure out what the middle node is 16:21:41 a bit more generic. 16:22:04 there are two designs going forward on the PT side, but if tor automatically does a 4-hop for an unauthenticated bridge, both designs are possible 16:22:06 and I'm in the camp that all bridge circuits should be 4 hop 16:22:14 armadev: that is a good question re: orfox bug tracking. i think I need to do some project clean up 16:22:43 (i can also do a bit of status report today) 16:22:59 uh, sure, go for it 16:23:00 infinity0: What is an unauthenticated bridge? 16:23:08 blanu: no fingerprint 16:23:10 blanu: Bridge line without fingerprint, tor doesn't check it 16:23:13 i mainly worked on little-t-tor stuff again, but 16:23:25 during the week I did some work with hellais on the bridge_reachability test 16:23:37 we could also examine the case for meek, where the reflector (e.g. google/azure) can be authenticated via x509, but i am not sure if it is worth the effort 16:23:49 i debugged one OONI in China, which was choking because the test was so parallel that the OOM killer was getting raised. 16:24:12 hellais solved the problem by making the test less parallel (test less bridges simultaneously) 16:24:28 also, (not my status report but) sysrqb sent a big categorized list of bridges to hellais 16:24:42 which will be imported to the OONI meters. 16:25:20 i also did some sysadmin work on my bridge which is getting super CPU stressed 16:25:20 infinity0: seems to me that you should want the "use a guard for your second hop 16:25:21 \o/ 16:25:29 armadev: brand new project here, to start separating it from orweb/orbot tickets: https://dev.guardianproject.info/projects/orfox-private-browser 16:25:33 asn: hmm, is that my fault? 16:25:36 i have a plan of putting a HAProxy in front of the bridge. 16:25:41 Yawning: no. 16:25:44 Yawning: for the 4-authenticated-hop scenario, you mentioned that you wanted the 2nd node to act as the guard. does that still satisfy all the security properties? i thought the trust you place in the guard is that it knows your IP address 16:25:51 Yawning: it's the same CPU usage as when obfsproxy was used. 16:26:08 infinity0: yeah, you pick the guard as normal 16:26:08 armadev: ah, what I just asked Yawning ^ 16:26:10 i might get help from a friend and put a haproxy in front of the bridge, which will allow it to scale some more. 16:26:17 and that's it from me. the show must go on. 16:26:51 so you get a bridge from god knows where, and make a circuit to 3 hops the client picks 16:27:02 past the bridge 16:27:09 anyway, mine is also quick 16:27:11 basically, you want the tor network to think you're a client 16:27:16 or rather, to think your bridge is you 16:27:31 wrote a bunch of e-mails to try to nail down the SponsorS stuff 16:27:41 if your circuits don't use guards, you're not acting like a tor user 16:27:43 obfs4proxy is in debian-unstable now 16:27:52 (yay) 16:27:58 thanks to Lunar^ 16:28:28 I did the fix for #13213 16:28:43 and I just pushed a minor change to obfs4proxy that makes it easier for people to give bridge lines out 16:29:05 my plans for the next bit are, do another round of tor browser + obfs4 snapshots 16:29:12 try to get bridge people to run obfs4 bridges 16:29:21 and SponsorS stuff 16:29:45 at the moment, you use the same few set of bridges, so they act as if they're your guards 16:29:59 I also still need to figure out what our answer to the mobile side of obfs4 is going to be 16:30:11 but that's just code so >.> 16:30:22 oh, it is so much more! 16:30:39 oh, obfs4 bridge lines are even more of a UX disaster than scramblesuit by the way 16:30:51 Yawning: What do you mean by the mobile side of obfs4? 16:30:51 Bridge obfs4 : node-id=1ecccfcb7bd67e3b0448210ea3d641911bfacd0f public-key=f59861f373c6ab174cb64a9c05af75a1b0cbbcacad33c9aa321117dbcf775d17 iat-mode=0 16:31:04 probably "how to build go code" 16:31:15 "for android" 16:31:16 Yawning: you could merge all the options up in a big blog. it's not like the users care. 16:31:25 nice. well, we have two plans related to easing adoption of bridges 1) device to device sharing of bridge configs between friends/trusted peoples 16:31:28 Yawning: that would make it smaller, and more suspicious looking. 16:31:33 I am hoping qrcodes will fix it 16:31:56 and 2) some other interesting mechanism that is better than email, but uniquely mobile somehow 16:32:11 i.e. push notifications, or SMS or something of that variety 16:32:41 and that very least, we should make it much easier to kick off the email to bridges@ 16:33:14 We are also investigating refactoring Orbot to be more modular 16:33:38 breaking out into a libAndroidTor and libAndroidPT for example 16:33:57 since there is using both by other apps, outside of just Orbot 16:34:13 asn: I might try to coerce base64 back in again somehow 16:35:54 I have some updates as well. Can I jump in now? 16:35:55 Yawning dcf1 will be reaching out to you in coming weeks/months on using obfsclient, meek, etc w/o Tor managing them 16:36:13 yeah, I was gonna write an externalizer 16:36:19 blanu: go for it 16:36:37 So I documented the Dust handshake protocol. In this process I found some places where it differs necessarily from the ntor paper, so it would be nice to have someone take a look at that. I will be sending that out soon for people to read. 16:37:01 Next step for documentation is the API. So that's what I'm working on now. 16:37:26 blanu: is there are project tracker/wiki for Dust? 16:38:01 On the code side, I have a couple of blockers. First, I am going to be getting another programmer, contracted through Guardian, to help on some of the PTs-on-Android stuff. 16:38:22 n8fr8: There is a github: https://github.com/blanu/Dust 16:38:45 pts on android should be in ok-shape right now 16:38:59 if not it's my fault and I'll fix things 16:39:20 The second is that we need some consensus between Yawning, n8fr8, and myself as to whether we will be using obfsclient or obfs4proxy. 16:39:54 python on android is still not a real possibility 16:39:57 Yawning: Well specifically I should have said "getting Dust to run on Android as a PT inside of obfsclient/obfs4proxy". I am going to work more on core Dust stuff. 16:40:05 ahh gotcha 16:40:16 n8fr8: This is why I'm glad you're here, because this is a surprising statement to me! 16:40:23 well, last time I looked hard. technically possible, but for end-user bundling/adoption is tricky. 16:40:45 last time I looked at it it seemed like ab it of a mess 16:40:49 i would love to be proven wrong and solve it, in a way that doesn't require a 20MB runtime 16:40:59 but that was a long time ago, before I wrote obfsclient 16:41:09 yes, and fortunate for us we have an angel (Yawning) that solved it for us :) 16:41:23 So then there are three possible platforms under consideration. We need to pick one before I can start building a PT. Also, for Dust we will need to provide a server, so that is part of the trade-offs in choosing the client platform. 16:42:26 maybe python-for-android has improved: https://github.com/kivy/python-for-android will do some digging 16:42:31 So I don't know how to move this decision process forward, but at least we have all of the stakeholders in a conversation about it now. 16:43:27 Ultimately Guardian has to decide what they want to ship, but it would be handy if I could be in that conversation since the choice of platform determines how hard my job of writing a Dust PT will be. 16:43:31 armadev: you need something for a presentation, right? how about something simple like https://people.torproject.org/~karsten/volatile/cells-pos-type.jpg ? 16:44:13 What would be easiest for you, blanu? 16:44:14 karsten: yeah that looks good 16:44:23 n8fr8: So what are you feelings on obfs4proxy? That's the new option that wasn't around the last time I considered PTs on Android. 16:44:47 blanu: well, Dust-as-a-PT is slightly differentiated from Dust-as-a-PT-that-works-on-Android, yes? 16:45:28 armadev: cool. I can write that graph code tonight. let me know when you have some numbers for me. 16:45:58 dcf1: Well obfsclient already works on Android, which is a plus, but there is no server side. obfs4proxy looks attractive. pyobfsproxy I am worried about getting to build on Android. 16:46:30 blanu: what do you mean there is no server side? 16:46:39 jcam: A Dust PT that works on Android should work everywhere. For purposes of this particular project I am only worried about Android. 16:46:46 well, obfsclient is "client" >.> 16:47:03 The server side doesn't necessarily have to be the same platform; i.e., doesn't have to run on Android. 16:47:45 Otherwise, I think we need to do some hands-on testing of the latest python-for-android schemes and see if A) it builds without too much hassle B) it doesn't add a huge amount of size to the resulting app and C) there is no performance impact 16:47:54 The server side could easily be pyobfsproxy if that's the easiest. 16:48:03 n8fr8: obfsclient is C++, but there is no C++ obfsserver. So for a Dust PT that uses obfsclient we will also have to write a server-side PT using py-obfsproxy. So that's twice the work implementing both sides of a PT. 16:48:21 right. 16:48:51 blanu: I'd need to see the wire protocol to really comment on a bunch of stuff 16:48:58 With obfs4proxy or py-obfsproxy, it is less work to implement both sides. 16:49:06 specs aren't availabel anywhere yet right? 16:49:12 Yawning: I will be sending you those docs today. 16:50:09 So let me just float this idea then: Why not obfs4proxy? It has some attractive qualities. 16:50:46 Builds on Android, has both client and server, and I think probably a smaller runtime than pyobfsproxy. 16:51:48 I guess once obvious downside is that it does not implement all of the same transports as obfsclient, which is what Guardian is using now. 16:51:56 well, that can be fixed 16:52:09 implementing scramblesuit as a client isn't hard 16:52:14 >.> 16:52:49 that's the only missing one 16:53:03 So I feel like what I'm hearing is 1) n8fr8 wants to try out py-obfsproxy and see how it does and 2) Yawning is down for anything. This all sounds good to me. 16:53:17 indeed 16:53:28 So I'll send out the Dust protocol docs to everyone and we can go from there. 16:53:31 That does it for me. 16:53:50 blanu, n8fr8: I'd encourage making the choice based on long-term value over the specifics of the sponsor here; there's flexibility if we need it in terms of specific PTs on Android. It'd be great to add Dust, but if Dust-on-Android is going to be very difficult, we can re-visit 16:54:03 my local time is kind of screwed up, so it may be a day ish before I can look at docs 16:54:10 (I feel like I need to curl my mustache or something when I say things like that) 16:54:18 (as in, localtime for me is Far East Asia) 16:54:38 oh sorry blanu, let me clarify. 16:54:44 jcam: it sounds like if we go with obfs4proxy we can consume all the cake 16:54:50 If obfs4proxy/golang is an option, then we should do that 16:55:25 I haven't looked at golang on android, but unless Dust is extremely exotic, obfs4proxy should be an ok base/framework 16:55:34 for a new pt implementation 16:55:47 jcam: I don't think Dust-on-Android is particularly challenging. I think the challenge is in the multiple PT platforms with different trade-offs. All PTs must face these same issues. 16:56:23 yeah, the reason obfs4proxy exists was "I need an elligator library" >.> 16:56:31 I have looked at Go on Android and it seems fine. 16:56:39 Yes, I agree. 16:56:40 Yawning: But you wrote an elligator library! In C++! 16:56:44 armadev: I am in favor of all the cake, and it does seem like obfs4proxy is particularly tasty cake, but it's not my place to decide on cake specifics (though, for the record, I prefer red velvet) 16:56:44 that's no longer an issue at this point 16:56:50 We can build binaries, and use them exactly was do obfsclient now. 16:56:52 blanu: after I finished obfs4 :P 16:56:57 Oh I see. 16:57:06 I ported agl's from go to C++ 16:57:28 n8fr8: oh, obfs4proxy will just work then 16:57:39 armadev: perhaps part of the PT roadmapping can be some guidance on the various PT library support paths? 16:57:49 as will meek we hope. 16:57:52 when using it as a client, it's basically exactly like obfsclient 16:57:53 expect! 16:57:57 yawning: what jcam said 16:58:03 yeah 16:58:16 yawning: in fact, a table alongside the PT designs should be a "PT framework" table 16:58:23 since we've got more than one now 16:58:43 i guess that could go pretty deep though, with "supporting libraries" and soon you're listing openssl and then it all goes messy 16:59:02 I was thinking about how to do meek correctly on android 16:59:04 so, cut it off at some reasonable point before it goes messy :) 16:59:04 n8fr8: Psiphon I believe is doing some meek+android work fwiw 16:59:16 Yawning: ^^ 16:59:22 okey doke. 16:59:28 just compiling meek-client may work but it'd look blatantly obvious 16:59:41 because of golang's tls implementation 16:59:57 Yawning: base32 maybe? 17:00:00 (no other client only supports ECDH suites) 17:00:25 So it sounds like next steps here are to get obfs4proxy to compile on Android. If it's not too much trouble, we can move forward with replacing obfsclient with obfs4proxy and all of the necessary things that need to happen to make that work. 17:00:32 asn: it's the stupid equal sign thing, was gonna just add them on myself and allow base64 as an option since it's most compact 17:00:38 In the meantime, I will maintain an agnostic attitude in developing the Dust API. 17:00:43 but tbh, and as needed 17:01:20 tor has a base64 without the padding 17:01:33 which means that maybe stem has a function for it too 17:01:36 blanu: my attitude towards this is, I am fundementally ok with anything, since I know all the codebases and protocols involved 17:01:38 ah no you are in golang 17:01:54 asn: it's easy if you know how bit the unencoded blob is supposed to be 17:02:04 I can just bolt on equal signs and see if it decodes 17:02:05 Yawning: That's a great attitude to have. 17:02:33 eventually I (and maybe arma?) will need clarification on the admin side of things 17:02:45 but that's more armadev's expertise than mine 17:02:54 I just poke at code >.> 17:03:33 also scramblesuit in obfs4proxy would take like, a week or two max since the bulk of the bits I need are already there 17:03:47 Oh I had an arma question. armadev: What is the sponsor code for this Guardian-Tor-Dust project? People are always talking about SponsorS and such. I wanted to get in on the lingo. 17:03:49 since obfs4 and scramblesuit are *really* similar under the hood 17:04:49 * dcf1 reins in the meeting to see if anyone else would like to speak. 17:05:05 I saw an infinity0 earlier, not sure if he's here now though 17:05:07 blanu: I'm pretty sure at this point it's Sponsor-oh-no-not-again ;) 17:05:26 oh yes, the 3/4 hops thing was the only thing i had in mind 17:05:30 going once 17:05:32 oh ok 17:05:47 going twice 17:05:47 i still don't like the fact that it's 5 hops, but i'll need to think about the problem a bit more 17:05:58 #endmeeting *baf*