- tor-dev - lists.torproject.org

Mail Address Translation Protocol Tor>Internet, Internet<Tor
by Liste 06 Nov '15

06 Nov '15

Enter/Exit OnionMail SMTP servers connect the Internet and Tor. The addressed must be translated from hidden service address to Internet address ad viceversa. There are some way to do this: MAT = Mail Address Translation: localpart.hiddenservice.onion(a)internetServer.tld = localpart(a)hiddenservice.onion VMAT = Virtual Mail Address Translation: localpart1(a)internetServer.tld = localpart2(a)hiddenservice.onion (With public Database) SMAT = Scrambled Mail Address Translation: base32encryptedWithHC256Address-HiddenServiceIdAndSalt.so(a)internetServer.tld = localpart(a)hiddenservice.onion (With private hidden service salt and id; without database). VCMAT = Virtual circuit VMAT. localpart2.vc(a)internetServer.tld = (firstHop.vc(a)server.onion) = (secondHop.vc(a)server.onion) = ... (nHop.vc(a)server.onion) = localpart(a)hiddenservice.onion (False connection). (False connection). Available from OnionMail2. And others.... Valid characters of localpart: [a-zA-Z0-9\-\.\_] The last part after the character dot "." declare the type of address. *.onion = M.A.T. Address. *.list = Mailing list. *.news = Newsgroup. *.op = SysOp reserved. *.app = Applications / bot. *.sys = OnionMail system. *.so = Scrambled VMAT. *.vc or *.iam = Virtual circuit VMAT. *.o = VMAT 3 Reserved. *.tor (or other word with 3 ot less characters) = Old only Tor address protocol (Removed in OnionMail 1.8.1 Alpha). *.a = Anonymous remailer address. *.x = Reserved. sysop = SysOp System administrator. server = Server bot. All others *.* are free for user as normal address local part. Example: user.wxyz(a)hiddenservice.onion is a normal user's OnionMail address. (The MAT address is: user.wxyz.hiddenservice.onion(a)internetSevewr.tld ) Some address functions may be encapsulated. *.list.*.onion(a)internetServer.tld = A mailing list MAT address. OR *.list(a)internetServer.tld = VMAT address of a mailing list. VMAT Mail type must be the same of tor address type. The special characters: +~ and others, except -_ Reserved for future use. The special address: iam.onion The meaning of this invalid hidden service address is "the otherside address". Can be used to set the local addresses on the same server only for special users like: sysop(a)iam.onion, server(a)iam.onion This address is used by TORM IAM request by the OnionMail server's IAM/InterNos protocol. for example if you send a request "TORM IAM iam.onion V2" you will receive the server's manifest without reversed request. All IP addresses are set to [0.0.0.0]

1 0

Proposal 258: Denial-of-service resistance for directory authorities
by Nick Mathewson 06 Nov '15

06 Nov '15

[Here's a new proposal from Andrea. See ticket 4581 for implementation details.] Filename: 258-dirauth-dos.txt Title: Denial-of-service resistance for directory authorities Author: Andrea Shepard Created: 2015-10-27 Status: Open 1. Problem statement The directory authorities are few in number and vital for the functioning of the Tor network; threats of denial of service attacks against them have occurred in the past. They should be more resistant to unreasonably large connection volumes. 2. Design overview There are two possible ways a new connection to a directory authority can be established, directly by a TCP connection to the DirPort, or tunneled inside a Tor circuit and initiated with a begindir cell. The client can originate the former as direct connections or from a Tor exit, and the latter either as fully anonymized circuits or one-hop links to the dirauth's ORPort. The dirauth will try to heuristically classify incoming requests as one of these four indirection types, and then in the two non-anonymized cases further sort them into hash buckets on the basis of source IP. It will use an exponentially-weighted moving average to measure the rate of connection attempts in each bucket, and also separately limit the number of begindir cells permitted on each circuit. It will periodically scan the hash tables and forget counters which have fallen below a threshold to prevent memory exhaustion. 3. Classification of incoming connections Clients can originate connections as one of four indirection types: - DIRIND_ONEHOP: begindir cell on a single-hop Tor circuit - DIRIND_ANONYMOUS: begindir cell on a fully anonymized Tor circuit - DIRIND_DIRECT_CONN: direct TCP connection to dirport - DIRIND_ANON_DIRPORT: TCP connection to dirport from an exit relay The directory authority can always tell a dirport connection from a begindir, but it must use its knowledge of the current consensus and exit policies to disambiguate whether the connection is anonymized. It should treat a begindir as DIRIND_ANONYMOUS when the previous hop in the circuit it appears on is in the current consensus, and as DIRIND_ONEHOP otherwise; it should treat a dirport connection as DIRIND_ANON_DIRPORT if the source address appears in the consensus and allows exits to the dirport in question, or as DIRIND_DIRECT_CONN otherwise. In the case of relays which also act as clients, these heuristics may falsely classify direct/onehop connections as anonymous, but will never falsely classify anonymous connections as direct/onehop. 4. Exponentially-weighted moving average counters and hash table The directory authority implements a set of exponentially-weighted moving averages to measure the rate of incoming connections in each bucket. The two anonymous connection types are each a single bucket, but the two non- anonymous cases get a single bucket per source IP each, stored in a hash table. The directory authority must periodically scan this hash table for counters which have decayed close to zero and free them to avoid permitting memory exhaustion. This introduces five new configuration parameters: - DirDoSFilterEWMATimeConstant: the time for an EWMA counter to decay by a factor of 1/e, in seconds. - DirDoSFilterMaxAnonConnectRate: the threshold to trigger the DoS filter on DIRIND_ANONYMOUS connections. - DirDoSFilterMaxAnonDirportConnectRate: the threshold to trigger the DoS filter on DIRIND_ANON_DIRPORT connections. - DirDoSFilterMaxBegindirRatePerIP: the threshold per source IP to trigger the DoS filter on DIRIND_ONEHOP connections. - DirDoSFilterMaxDirectConnRatePerIP: the threshold per source IP to trigger the DoS filter on DIRIND_DIRECT_CONN connections. When incrementing a counter would put it over the relevant threshold, the filter is said to be triggered. In this case, the directory authority does not update the counter, but instead suppresses the incoming request. In the DIRIND_ONEHOP and DIRIND_ANONYMOUS cases, the directory authority must kill the circuit rather than merely refusing the request, to prevent an unending stream of client retries on the same circuit. 5. Begindir cap Directory authorities limit the number of begindir cells permitted in the lifetime of a particular circuit, separately from the EWMA counters. This can only affect the DIRIND_ANONYMOUS and DIRIND_ONEHOP connetion types. A sixth configuration variable, DirDoSFilterMaxBegindirPerCircuit, controls this feature. 6. Limitations Widely distributed DoS attacks with many source IPs may still be able to avoid raising any single DIRIND_ONEHOP or DIRIND_DIRECT_CONN counter above threshold.

2 1

Re: [tor-dev] stale entries in bwscan.20151029-1145
by starlight.2015q3＠binnacle.cx 06 Nov '15

06 Nov '15

aAt 20:56 11/5/2015 -0600, you wrote: >On 5 November 2015 at 16:37, <starlight.2015q3(a)binnacle.cx> wrote: >> By having a single thread handle >> consensus retrieval and sub-division, >> issues of "lost" relays should >> go away entirely. > >So I'm coming around to this idea, after spending >an hour trying to explain why it was bad. . . :-D happy to hear that It can be expressed and implemented various ways, but the core idea of centralizing this function is hard to escape. >So the >main problem as I see it is that it's easy to move >relays between slices that haven't happened yet - >but how do you do this when some slices are >completed and some aren't? >. . .if you used a work queue instead of a scanner. . . I'm thinking of it more as a set of circular work lists, since scanning never ends. Not then a question of "haven't happened yet" for new relays since regardless of where they're inserted they will be measured. More a question of giving priority to new relays and giving priority to relays that have exhibited a large change of bandwidth, particularly in the downward direction. If radical restructuring is on the menu (as the remainder of your comments imply) let me put out an idea I've come up with: I'm not enthusiastic about the current design where nine scanners blindly compete with each other for the local Tor client-router and link bandwidth. The goal should be to figure out what percent of the BWauth link's bandwidth should be consumed to minimize scanning time while ensuring quality measurement. Nine scanners could be replaced with one scanner that runs the entire list of relays sorted from fastest to slowest. This scanner would keep the slice approach of firing-up scans until a quota is filled. But instead of that quota being a somewhat arbitrary fixed value, the quota would be a minimum bandwidth target per the output of 'SETEVENTS BW'. A rough guess is that whatever bandwidth is available should be 35% subscribed, though the actual setting would require empirical determination. On a 100mbps link the target might then be a continuous 4.5 million bytes/sec of scanning. This might result in the 100 or so fastest relays being measured one-at-time, but of course it would happen rather quickly. As the scanner works down the list the number of concurrent scans would rise rapidly as the bandwidth of the targets decline and so perhaps several hundred of the slowest relays would be under measurement near the end of each pass. My belief is the end result would be dramatically faster than the current approach, have a low circuit-fail rate, and that the measurements would be far more reliable and consistent. >FWIW, looking at >https://bwauth.ritter.vg/bwauth/AA_scanner_loop_times.txt , it >seems like (for whatever weird reason) scanner1 took way longer than >the others. (Scanner 9 is very different, so ignore that one.) > >Scanner 1 > 5 days, 11:07:27 Yes noticed this a few days ago, examined ticket 17482 more closely and saw it was 6.5 days for scanner-one just before the 10/30 restart. The scanner-one log shows huge numbers of circuit failures. Observation partly inspired the above restructuring idea.

1 0

Re: [tor-dev] stale entries in bwscan.20151029-1145
by starlight.2015q3＠binnacle.cx 06 Nov '15

06 Nov '15

At 11:47 11/5/2015 -0600, Tom Ritter wrote: > . . . >So them falling between the slices would be my >best guess. . . Immediately comes to mind that dealing with the changing consensus while scanning might be handled in a different but nonetheless straightforward manner. Why not create a snapshot of the consensus at the time scanning commences then-- without disturbing the scanners-- pull each new update with an asynchronous thread or process. The consensus thread would diff against the previous state snapshot and produce an updated snapshot plus deltas for each scanner and/or slice as the implementation requires. Then briefly lock the working list for each active scanner and apply the delta to it. By having a single thread handle consensus retrieval and sub-division, issues of "lost" relays should go away entirely. No need to hold locks for extended periods. The consensus allocation thread would run continuously, so individual slices and scanners can complete and restart asynchronous to each other without glitches or delays. Consensus allocation worker could also manage migrating relays from one scanner to another, again preventing lost relays.

2 2

[proposal] New Entry Guard Selection Algorithm
by isis 06 Nov '15

06 Nov '15

Hello, For your reviewing pleasure, may I present you with a new (draft) proposal for a new entry guard selection algorithm, and associated data structures (with reference implementations!). [0] The bulk of it is based upon George Kadianakis' recent email and pseudocode. [1] [2] There are still a few XXXs which need elucidation and/or comment. Relevant tickets include: https://bugs.torproject.org/17261 https://bugs.torproject.org/17262 https://bugs.torproject.org/16120 https://bugs.torproject.org/12466 https://bugs.torproject.org/12450 https://bugs.torproject.org/12595 Assistance with the completion of #17262 (due 31 Oct) would be greatly appreciated, since my plan for tomorrow is to work with some of the cryptographers here to review my changes to the crypto in rBridge for #7520. [0]: https://gitweb.torproject.org/user/isis/torspec.git/commit/?h=bug17261-best… [1]: https://lists.torproject.org/pipermail/tor-dev/2015-August/009328.html [2]: https://gitweb.torproject.org/user/asn/tor.git/tree/src/or/guardlist.c?h=bu… Best regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

4 3

Re: [tor-dev] stale entries in bwscan.20151029-1145
by starlight.2015q3＠binnacle.cx 05 Nov '15

05 Nov '15

At 11:47 11/5/2015 -0600, Tom Ritter wrote: > . . . >So them falling between the slices would be my >best guess. . . Immediately comes to mind that dealing with the changing consensus while scanning might be handled in a different but nonetheless straightforward manner. Why not create a snapshot of the consensus at the time scanning commences then-- without disturbing the scanners-- pull each new update with an asynchronous thread or process. The consensus thread would diff against the previous state snapshot and produce an updated snapshot plus deltas for each scanner and/or slice as the implementation requires. Then briefly lock the working list for each active scanner and apply the delta to it. By having a single thread handle consensus retrieval and sub-division, issues of "lost" relays should go away entirely. No need to hold locks for extended periods. The consensus allocation thread would run continuously, so individual slices and scanners can complete and restart asynchronous to each other without glitches or delays. Consensus allocation worker could also manage migrating relays from one scanner to another, again preventing lost relays.

1 0

Re: [tor-dev] stale entries in bwscan.20151029-1145
by Tom Ritter 05 Nov '15

05 Nov '15

[+tor-dev] So... weird. I dug into Onyx primarily. No, in scanner.1/scan-data I cannot find any evidence of Onyx being present. I'm not super familiar with the files torflow produces, but I believe the bws- files list what slice each relay is assigned to. I've put those files (concatted) here: https://bwauth.ritter.vg/bwauth/bws-data Those relays are indeed missing. Mike: is it possible that relays are falling in between _slices_ as well as _scanners_? I thought the 'stop listening for consensus' commit would mean that for a single scanner would use the same consensus for all the slices in the scanner... -tom [0] https://gitweb.torproject.org/torflow.git/commit/NetworkScanners/BwAuthorit… On 5 November 2015 at 10:48, <starlight.2015q4(a)binnacle.cx> wrote: > Hi Tom, > > Scanner 1 finally finished the first pass. > > Of the list of big relays not checked > below, three are still not checked: > > *Onyx 10/14 > atomicbox1 10/21 > *naiveTorer 10/15 > > Most interesting, ZERO evidence of > any attempt to use the two starred > entries appears in the scanner log. > 'atomicbox1' was used to test > other relays but was not tested > itself. > > Can you look in the database files > to see if any obvious reason for > this exists? These relays are > very fast, Stable-flagged relays > that rank near the top of the > Blutmagie list. > > > > > >>Date: Thu, 29 Oct 2015 19:57:52 -0500 >>To: Tom Ritter <tom(a)ritter.vg> >>From: starlight.2015q4(a)binnacle.cx >>Subject: Re: stale entries in bwscan.20151029-1145 >> >>Tom, >> >>Looked even more closely. >> >>I flittered out all relays that are >>not currently active, ending up with >>a list of 6303 live relays. >> >>1065 or 17% of them have not be >>updated for five or more days, >>292 or 4% have not been updated >>for ten days, and 102 or 1% >>have not been updated for 15 >>days. >> >>In particular I know of a very fast >>high quality relay in a CDN-grade >>network that has not been measured >>in 13 days. My relay Binnacle >>is a well run relay in the >>high-quality Verizon FiOS network >>and has not been measured for 10 days. >> >>This does not seem correct. >> >> >>P.S. Here is a quick list of some >>top-30 relays that have have been >>seriously neglected: >> >>redjohn1 10/9 >>becks 10/15 >>aurora 10/20 >>Onyx 10/14 >>IPredator 10/15 >>atomicbox1 10/21 >>sofia 10/14 >>naiveTorer 10/15 >>quadhead 10/12 >>3cce3a91f6a625 10/13 >>apx2 10/14 >> >> >> >>>At 13:35 10/29/2015 -0400, you wrote: >>> >>>>The system is definetly active. . . .the most recent file has ten day old entries? >>> >>>Just looked more closely. About 2500 >>>of 8144 lines (30%) have "updated_at=" more >>>than five days ago or 2015/10/24 00:00 UTC. >>> >>>Seems like something that should have >>>an alarm check/monitor. >

1 1

Tor dev meeting times this week and beyond!
by Nick Mathewson 05 Nov '15

05 Nov '15

Hello all! As a reminder, we have a weekly patch workshop and a weekly developer's meeting on the #tor-dev IRC channel on OFTC. With the ending of DST in the US, these times are now convenient for even fewer people than before. With that in mind, we're changing! The new times will be effective starting NEXT WEEK, November 9. (My apologies; it's too late for me to change my schedule this week.) Primary meeting and patch workshop: Wednesday 1830 UTC (1:30pm EST , 10:30am PST) Secondary meeting time and patch workshop: Monday at 0100 UTC (8:00pm EST, 5:00pm PST) I'll always attend both whenever I can. For the primary meeting slot, we'll start with check-in, then discuss open issues, then move on to a patch workshop. The secondary slot will be a bit looser. For this week only, the times will remain as before, since I've already. The patch workshop will be tomorrow (Tuesday) at 1800 UTC, and the dev meeting will be on Wednesday at 1330 UTC. best wishes to all, -- Nick

3 2

An ANTLR 4 grammar for Tor bridge network statuses
by Karsten Loesing 05 Nov '15

05 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello developers, in the past few days I have been working on a grammar to parse Tor bridge network statuses and hopefully other Tor descriptors in the future. It's working, for some definition of working, but some issues remain and I need some help. I just uploaded my sources, consisting only of the grammar with a fair amount of documentation: https://people.torproject.org/~karsten/volatile/BridgeNetworkStatus.g4 Quoting from that file to facilitate discussion here: There are multiple goals of having a grammar for Tor descriptors available on CollecTor: 1. Translate descriptors to JSON for statistical analysis: Some tools and databases require Tor descriptors in a standard format like JSON. This grammar and a parser generated from it can help making that translation as easy as possible, also to keep future maintenance as low as possible. 2. Provide a basis for descriptor-parsing libraries: As of late 2015, there are three libraries for parsing Tor descriptors: metrics-lib for Java, Stem for Python, and Zoossh for Go. It would be beneficial to place as much knowledge about the descriptor format into a grammar shared by all those libraries and then generate parsers for different languages from that grammar. 3. Serve as documentation for the Tor directory protocol specification: Tor descriptors are already documented using a hand-written grammar, but that may contain slight inaccuracies because it's not verified. This grammar could fix that by either detecting inaccuracies while trying to rewrite it to an executable grammar form or by replacing the grammar in the specification documentation with this executable grammar. Open issues and questions: - Was it smart to explicitly include all those SP tokens in the rules, or should those be discarded right away by the lexer? The main reason for keeping them was to stay as close to the specification as possible, but maybe that has downsides on the other goals. - If a bridge uses a nickname (or other token that's supposed to be a STRING) that is also a keyword like "r" or "published", things get confusing. Try editing the input bridge network status and observe the result. But those are perfectly valid nicknames, so what can we do? - It would be really nice to use regular expressions in the grammar to match input more thoroughly than just ~[ \n]+, if only we can fix the lexer troubles. It's a pity that all that verification work would need to be duplicated in each of the language-dependent parsers. That kinda defeats the purpose. - Is it easy to walk the parse tree and output a JSON format *without* having to write code for each of the rules? Ideally, the translator would be 20 lines of code and not grow at all if we add 10 more descriptor types. Do we need to change the grammar for that? - The following may turn out to be a non-issue, but some descriptors require lines to be ordered, e.g., "accept" and "reject" lines in server descriptors, and we'll have to retain that order in the parse tree. This should be similar to how we parse entries, starting with "r" lines, but who knows. Feedback much appreciated! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWOcp+AAoJEJD5dJfVqbCrnQUH/2dp8ER6ZcEGBtHP+dPb/4p0 0tKb4eZobQhZNx3oQOc08nCJl3AEa+Vedep5Caa9MSNycopf7mBFEGtw2V5J3mKN w6D6cvSbSBoFhuh/+Q8oVj+6h0KkUaCVVMaTHefb63usM0EmjsEXvDjBXr+g5nhn q0RqM1Id3V38rs3pKi1JDwGU4w5X45gzUPOXbiNGig6wJuLN1e2cxfF4RdDmGzST JvjlH/KRV59NjMRvUAeTxZIXlz6fKwjTWWQ2PXUnuXAXNPVxYakzHNhiT7qXGro0 7ZFfIr7gwk9kZlF0oy6ltFC1mGgL4xk0vqlrOjvwrh+oAzIciurMcOddXEHwr3E= =DZ0Z -----END PGP SIGNATURE-----

2 2

A quick and dirty UX evaluation of Tor Messenger
by Greg Norcie 04 Nov '15

04 Nov '15

Hi all, First of all, great work on Tor Messenger - it's awesome to see Tor pushing to be more accessible to non-technical folks. I decided to take some notes when installing + using for the first time, hopefully this will be helpful. While there are some minor issues, I'd like to stress that this is a great first step and considering this is the first general public release it's a very good design. /////// I'm on an OSX machine, so the first thing I see after clicking on the icon is a message that Tor can't be opened because it's from an unidentified developer. This would raise an eyebrow at least for most users. (And lessens the effectiveness of the warning if we are going to train users to ignore it) I right click and select "open" and there is a longish pause (>10s) which could frustrate new users, then the wizard appears. I don't chat often - I usually text my friends, and I don't want to use FB chat since it's tied to my real name. I remember that Twitter now has no DM limit. But it's not on the main list. I don't have any data to support this intuition, but I suspect that after XMPP, Twitter would be a popular protocol. I click once on "show all protocols" and click continue. There's only a few additional, Twitter being one of them. Not sure why this list wasn't present from the beginning. I get options for a local alias and "tracked keywords". I have no clue what the latter is, but it sounds like the concept of a taboo in Harry Potter, so for a laugh I put in "Voldermort". Now I'm authorizing Instabird. Fairly straightforward. Now I'm receiving a texted 2f code from twitter and entering it. Now I'm in, and I can see my Twitter timeline, which is interesting. I was expecting just a buddy list to send DMs, not timeline access. I post a tweet to my timeline, then want to send my boss a test DM. But I follow >1500 people, and have to scroll a lot to find him. I locate his name and double click, but nothing happens. At this point, I suspect a less security minded user might abandon the app. (I end up digging around a bit to find the functionality I need) [1] ("Your security preferences allow installation of only apps from the Mac App Store and identified developers.") -- /***********************************/ *Greg Norcie (norcie(a)cdt.org <norcie(a)cdt.org>)* *Staff Technologist* *Center for Democracy & Technology* 1634 Eye St NW Suite 1100 Washington DC 20006 (p) 202-637-9800 PGP: http://norcie.com/pgp.txt Fingerprint: 73DF-6710-520F-83FE-03B5 8407-2D0E-ABC3-E1AE-21F1 /***********************************/

2 2

1-1-1 task exchange meeting on Thursday, Nov 5, 15:00 UTC in #tor-dev
by Karsten Loesing 04 Nov '15

04 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, we'll have another 1-1-1 task exchange meeting on Thursday, November 5, 2015, 15:00 UTC in #tor-dev https://www.timeanddate.com/worldclock/fixedtime.html?iso=20151105T15 Quick reminder: The idea of the 1-1-1 task exchange meeting is that participants get 1 minute to describe a task that would take somebody else roughly 1 hour and that they will do within 1 week. It could be to review a document, write some analysis code, fix a small bug, and so on. It's best to come prepared with a task or two to get the most out of this. In a perfect world people would give one task for each task they take, but that is not required. https://trac.torproject.org/projects/tor/wiki/doc/1-1-1-task-exchange Hint: I'll bring at least two fresh tasks to tomorrow's meeting, one about database optimization and one about grammars for parsing Tor descriptors. Talk to you tomorrow at 15:00 UTC. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWOjrpAAoJEJD5dJfVqbCrNgAIALHKS1JPtqhq6IGCRrgSIcuB 6Z8gJSc8KB7L/d89i3DwonNk3W0fzKZnLzT2FgUMFwfkL8ehEOw6rB86vL/d1K4o S+9Q71bvUWFP1BjRTCnFsOfC79Jz9aC3QvT69Q9/ULNGyRqsGypaop31h7Y6CE6d acUSSjvKiWxY+hFflZNq9RcugoSyDTasV7IlYulZduc/PMChOdR1FM5kBiXRVL40 Dgd3m71YILW8Ce9CWbwBVi6CD5lrVSRyDWG/I8dKBV206Y6z0BStj/wKrqnRvE9/ GOV0graoqh2kDSD2S3X81PuXlo+QcQU+lDy5nRKB5EcnTEiuXLz9Emph1GNUd2w= =Jwbg -----END PGP SIGNATURE-----

1 0

running a BWauth
by starlight.2015q3＠binnacle.cx 04 Nov '15

04 Nov '15

I am considering starting up a passive BWauth in order to understand how they work and fix bugs. What is the minimum and ideal hardware configuration for a BWauth? Have my eye on an OVH config with unmetered 1G, a fuzzy promise of 500mbps minimum bandwidth and a 3.4GHz 4core/8thread AES-NI CPU: http://ark.intel.com/products/80910 The server could be turned up in any of their facilities: https://www.ovh.com/us/about-us/datacenters.xml Or is 10G a requirement? (out of my league) Is all code here https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority or is there more? Are uncommitted fixes lying around anywhere? Thanks

4 4

[Fwd: UX Principles]
by Mike Perry 03 Nov '15

03 Nov '15

Nima sent this to me a while ago and I completely forgot to forward it on. Note the Google docs and the PDF at the bottom. Useful food for though for Tor Messenger, Tor Browser, and other user-facing stuff. ----- Forwarded message from Nima Fatemi <nima(a)torproject.org> ----- Date: Fri, 24 Jul 2015 03:39:31 +0000 From: Nima Fatemi <nima(a)torproject.org> To: Mike Perry <mikeperry(a)torproject.org> Subject: UX Principles Hi Mike, sorry for late email. I was meaning to send you this sooner but I've had a big pile of email, I had to take care of. So the forwarded message below includes an attachment, which is the Yee's principles and then there's another paper that linda has mentioned, which is worth reading I think. Here's that talk from Google Chrome's Elisabeth Morant that I mentioned to you: https://news.yahoo.com/video/yahoo-trust-unconference-security-ux-161037378… Here are the slides: (the good stuff start from page 12) https://docs.google.com/presentation/d/1i2Pwennj8PcsigACPA1oLpRNLd7BVC0oils… And here are my notes from the talk + my thoughts added to them: - 1st principle: Don't annoy users, even with updates. - People (even infosec ppl) ignore updates - users are often worried that updates would change the interface, it took them time and energy to get used to current things, they dont want it to change (even if it's a good change) - Enable auto-update by default with an option to opt out - Give devs and users tools to time permission requests - 2nd principle: allow mistakes!!! let them change their settings easily if they've changed their minds - settings windows doing similar thing should look similar and if they do the exact things, they should look identical. - make settings easy to discover - 3rd principle: combat jerks [malicious-HS_maybe?] - danger is hard to communicate - how to tell users about the danger they're facing - infrastructure for detecting and reacting to badness - how to do this in a decentralized way?! - karma! tie user engagement to resource allocation (maybe useful for HiddenServices?) (okay, right after writing this sentence, I started a conversation in #tor-project. see the backlog, you might find it interesting) - crowd consent Let me know if I can be of any help. Bests, -- Nima -------- Forwarded Message -------- Subject: Yee's principles Date: Wed, 1 Jul 2015 05:51:05 -0700 From: Linda Naeun Lee <lnl(a)berkeley.edu> To: Tor Project <nima(a)torproject.org> Nima: Here are notes. And another paper. http://zesty.ca/pubs/yee-sid-ieeesp2004.pdf -- Linda Naeun Lee Graduate Student Researcher Department of Computer Science University of California, Berkeley ----- End forwarded message ----- -- Mike Perry

2 1

UX tag
by Nima Fatemi 02 Nov '15

02 Nov '15

Hello devs, May I encourage you to add "UX" tag (keyword) to the tickets you're filing or working on that are related to usability in any ways? This is to get a sense of how many tickets and what workload is related to usability in tor-related products. So I want to humbly ask you to use the tag regardless of the help you may or may not need for that ticket. And if you've any suggestions/ideas to measure this better, this is a great time to talk about it :) Peace ✌ -- Nima 0XC009DB191C92A77B | @mrphs "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall

4 4

Re: [tor-dev] Update of prop#250: Random Number Generation During Tor Voting
by Jesse V 02 Nov '15

02 Nov '15

David, I'm in the midst of reworking my OnioNS design around prop250 (and the security analysis therein) and as far as I can tell these changes make sense. I like the 00:00 -> 24:00 change as it's more intuitive as you said. I was at first very concerned that you removed the majority requirement as that is the assumption made during consensus generation, but I think your argument for the new conflict resolution make sense. I'm excited that the implementation is nearly complete and I look forward to seeing it in Tor infrastructure! Jesse V. On 10/28/2015 10:26 AM, David Goulet wrote: > First, period have been changed from 12:00 -> 12:00 (24 hour) to 00:00 > -> 24:00 so the protocol run is not over two days. Seemed more logical > and less confusing :). > > Second, we've removed the need of having majority for a commit to be > considered for the shared random computation. Yes this sounds intense!! > so it needs your attention.

3 2

Tor logo
by Philip Lammert 01 Nov '15

01 Nov '15

Hi, I wasn’t lucky with the Tor logo, its design qualities in general, especially its performance in small sizes and its inconsistent applications (different shades of purple and green, outlines, gradients and glossy effects …). So I made a redesign. I would offer all file types needed. I hope this mailing-list is the right place to present it and discus it. Please, have a look at the PDF-file: http://www.file-upload.net/download-11010886/_logos_overview.pdf.html The whole developing system here seems decentralised and an implementation might be a bit cumbersome, but if it doesn’t exhaust me too much, I could also offer further design advice, (re-)designing app icons, making mockups for Tor websites, apps etc. and give it a consistent and professional appearance. Regards Philip

3 4

Pluggable Transports v1 spec rewrite.
by Yawning Angel 31 Oct '15

31 Oct '15

Hello all, In an attempt to make Pluggable Transports more accessible to other people, and to have a spec that is more applicable and useful to other projects that seek to use Pluggable Transports for circumvention, I have drafted a re-write of the spec. This is not intended to alter existing behavior, but instead make it clear that the whole "Pluggable Transports" thing isn't just for Tor. Unless people have serious objections, this will replace the existing PT spec, to serve as a stop-gap while the next revision of the PT spec (that does alter behavior) is being drafted/implemented. Regards, -- Yawning Angel

3 3

Bridge Guards (prop#188) & Bridge ORPort Reachability Tests
by isis 30 Oct '15

30 Oct '15

Hey all, I have a working implementation of proposal #188, [0] which specifies a mechanism by which tor's (rather accidental) loose-source routing feature is utilised by Bridges in order to transparently inject a Bridge Guard into all client circuits. (See #7144. [1]) Currently, I am updating the text in proposal #188 to match my implementation, and I am trying to decide what to do about the two types of Bridge ORPort reachability testing. Here's the text I've written so far to explain the issues: (In the following, "Alice" is an OP, "Bob" is a Bridge, "Guillaume" is Bob's chosen Entry Guard, and "Charlie" is a random Middle node.) > 4.4. Bridge Reachability Testing > > Currently, a Bridge's reachability is tested both by the Bridge > itself (called "self-testing") and by the BridgeAuthority. > > 4.4.1. Bridge Reachability Self-Testing > > Before a Bridge uploads its descriptors to the BridgeAuthority, it > creates a special type of testing circuit which ends at itself: > > Bob -> Guillaume -> Charlie -> Bob > > Thus, going to all this trouble to later use loose-source routing in > order to relay Alice's traffic through Guillaume (rather than > connecting directly to Charlie, as Alice intended) is diminished by > the fact that Charlie can still passively enumerate Bridges by > waiting to be asked to connect to a node which is not > contained within the consensus. > > We could get around this option by disabling self-testing for bridges > entirely, by automatically setting "AssumeReachable 1" for all Bridge > relays… although I am not sure if this is wise. > > 4.4.2. Bridge Reachability Testing by the BridgeAuthority > > After receiving Bob's descriptors, the BridgeAuthority attempts to > connect to Bob's ORPort by making a direct TLS connection to the > Bridge's advertised ORPort. > > Should we change this behaviour? One the one hand, at least this > does not enable any random OR in the entire network to enumerate > Bridges. On the other hand, any adversary who can observe packets > from the BridgeAuthority is capable of enumeration. So, my current questions are: 1. Bridges only do reachability self-testing in order to warn their operators that the Bridge (or firewall or whatever) might be misconfigured, correct? Is there any other reason (or future reason) why self-testing is important/useful? 2. How should the self-testing be changed? 2.a. First, if there aren't any other reasons for self-testing: Is Bridge reachability self-testing actually helpful to Bridge operators in practice? Don't most Bridge operators just try to connect, as a client, to their own Bridge to see if it's working correctly? (This is what I usually do, at least…) If it's not useful to most Bridge operators, can we just disable self-testing for all Bridges? (And, should we disable it only for Bridges who are using Bridge Guards, or all of Bridges regardless?) 2.b. If it is useful to people, then the best way I can think of so far to keep it, but refactor it to be safer, would be to create a circuit like: Bridge → Guard → Middle → OtherMiddle → Guard → Bridge Clearly, that circuit is just a little bit insane… but we can't do: Bridge → Guard → Middle → Guard → Bridge because the Middle would refuse to extend back to the previous node (all ORs follow this rule). Similarly, it would be stupid to do: Bridge → Guard → Middle → OtherMiddle → Bridge because, obviously, that merely shifts the problem and accomplishes nothing. But is there something smarter I could do? 3. Should we change how the BridgeAuthority tests Bridge ORPort reachability? If so, how? 4. If I'm going to refactor all of this, are there other (future) things I should take into account? For example, if self-testing is disabled for Bridges, and, due to #7349, [2] the BridgeAuthority isn't testing reachability either, then how will the BridgeAuthority know if (any of) the Bridge's PTs are reachable? (One solution might be to, in that case, have the BridgeAuthority lie and tell BridgeDB that such Bridges were reachable, letting BridgeDB do the PT reachability testing.) Please help me brainstorm a way out of this mess! [0]: https://gitweb.torproject.org/torspec.git/tree/proposals/188-bridge-guards.… [1]: https://bugs.torproject.org/7144 [2]: https://bugs.torproject.org/7349 Best Regards, -- ♥Ⓐ isis agora lovecruft _________________________________________________________ OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

4 8

Tor Messenger Beta: Chat over Tor, Easily
by Sukhbir Singh 30 Oct '15

30 Oct '15

Hi, Today we are releasing a new, beta version of Tor Messenger, based on Instantbird [0], an instant messaging client developed in the Mozilla community. * What is it? Tor Messenger is a cross-platform chat program that aims to be secure by default and sends all of its traffic over Tor. It supports a wide variety of transport networks, including Jabber (XMPP), IRC, Google Talk, Facebook Chat, Twitter, Yahoo, and others; enables Off-the-Record (OTR) Messaging [1] automatically; and has an easy-to-use graphical user interface localized into multiple languages. * What it isn't... Tor Messenger builds on the networks you are familiar with, so that you can continue communicating in a way your contacts are willing and able to do. This has traditionally been in a client-server model, meaning that your metadata (specifically the relationships between contacts) can be logged by the server. However, your route to the server will be hidden because you are communicating over Tor. We are also excited about systems like Pond [2] and Ricochet [3], which try to solve this problem, and would encourage you to look at their designs and use them too. * Why Instantbird? We considered a number of messaging clients: Pidgin, Adam Langley's xmpp-client, and Instantbird. Instantbird was the pragmatic choice -- its transport protocols are written in a memory-safe language (JavaScript); it has a graphical user interface and already supports many natural languages; and it's a XUL application, which means we can leverage both the code (Tor Launcher) and in-house expertise that the Tor Project has developed working on Tor Browser with Firefox. It also has an active and vibrant software developer community that has been very responsive and understanding of our needs. The main feature it lacked was OTR support, which we have implemented [4] and hope to upstream to the main Instantbird repository for the benefit of all Instantbird (and Thunderbird) users. * Current Status Today we are releasing a beta version with which we hope to gain both usability and security related feedback. There have been three previous alpha releases to the mailing lists that have already helped smooth out some of the rougher edges. * Downloads Linux (32-bit) https://dist.torproject.org/tormessenger/0.1.0b2/tor-messenger-linux32-0.1.… Linux (64-bit) https://dist.torproject.org/tormessenger/0.1.0b2/tor-messenger-linux64-0.1.… Windows https://dist.torproject.org/tormessenger/0.1.0b2/tormessenger-install-0.1.0… OS X https://dist.torproject.org/tormessenger/0.1.0b2/TorMessenger-0.1.0b2-osx64… sha256sums https://dist.torproject.org/tormessenger/0.1.0b2/sha256sums.txt https://dist.torproject.org/tormessenger/0.1.0b2/sha256sums.txt.asc The sha256sums.txt file containing hashes of the bundles is signed with the key 0x6887935AB297B391 (fingerprint: 3A0B 3D84 3708 9613 6B84 5E82 6887 935A B297 B391). * Instructions - On Linux, extract the bundle(s) and then run: ./start-tor-messenger.desktop - On OS X, copy the Tor Messenger application from the disk image to your local disk before running it. On all platforms, Tor Messenger sets the profile folder for Firefox/Instantbird to the installation directory. - Note that as a policy, unencrypted one-to-one conversations are not allowed and your messages will not be transmitted if the person you are talking with does not have an OTR-enabled client. You can disable this option in the preferences to allow unencrypted communication but doing so is not recommended. * Source Code We are doing automated builds [5] of Tor Messenger for all platforms. The Linux builds are reproducible: anyone who builds Tor Messenger for Linux should have byte-for-byte identical binaries compared with other builds from a given source. You can build it yourself [6] and let us know if you encounter any problems or cannot match our build. The Windows and OS X builds are not completely reproducible yet but we are working on it [7]. * What's to Come Our current focus is security, robustness and user experience. We will be fixing bugs and releasing updates as appropriate, and in the future, we plan on pairing releases with Mozilla's Extended Support Release (ESR) cycle. We have some ideas on where to take Tor Messenger but we would like to hear what you have to say. Some possibilities include: - Reproducible builds for Windows and OS X (#10942) - Sandboxing (#10943) - Automatic updates (#14388) - Improved Tor support (#10950) - OTR over Twitter DMs (#13312) - Produce (and distribute) internationalized builds (#10945) - Secure multi-party communication (np1sec) [8] - Encrypted file-transfers - Usability study * How To Help Give it a try and provide feedback, requests, and file bugs [9] (choose the "Tor Messenger" component). If you are a developer, help us close all our tickets [10] or help us review our design doc [11]. As always, we are idling on IRC in #tor-dev (OFTC) (nicks: arlolra; boklm; sukhe) and subscribed to the tor-talk/dev mailing lists. Please note that this release is for users who would like to help us with testing the product but at the same time who also understand the risks involved in using beta software. Thanks and we hope you enjoy Tor Messenger! [0] - http://instantbird.com [1] - https://otr.cypherpunks.ca [2] - https://pond.imperialviolet.org [3] - https://ricochet.im [4] - https://github.com/arlolra/ctypes-otr [5] - https://gitweb.torproject.org/tor-messenger-build.git [6] - https://gitweb.torproject.org/tor-messenger-build.git/tree/README [7] - https://trac.torproject.org/projects/tor/ticket/10942 [8] - https://github.com/equalitie/np1sec [9] - https://trac.torproject.org/projects/tor/newticket [10] - https://trac.torproject.org/projects/tor/query?status=!closed&component=Tor… [11] - https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger/DesignDoc

2 3

[Applications Team] First meeting next Tuesday 19:00 UTC
by Georg Koppen 29 Oct '15

29 Oct '15

Hi, just a reminder that the applications team is starting the monthly meetings next week on Tuesday, November 3 at 19:00 UTC[0] in #tor-project on irc.oftc.net. The proposed topic is still talking about UX/internationalization issues. If there are other things worth discussing we can easily amend the agenda at the beginning of the meeting. See you there, Georg [0] Originally I had written "18:00 UTC" but I forgot to take the end of the summer time into account.

1 0

Re: [tor-dev] Pluggable Transports v1 spec rewrite.
by Nathan Freitas 29 Oct '15

29 Oct '15

On Thu, Oct 29, 2015, at 09:19 AM, Yawning Angel wrote: > Hello all, > > In an attempt to make Pluggable Transports more accessible to other > people, and to have a spec that is more applicable and useful to other > projects that seek to use Pluggable Transports for circumvention, I have > drafted a re-write of the spec. > > This is not intended to alter existing behavior, but instead make it > clear that the whole "Pluggable Transports" thing isn't just for Tor. > > Unless people have serious objections, this will replace the existing > PT spec, to serve as a stop-gap while the next revision of the PT spec > (that does alter behavior) is being drafted/implemented. > Any small or big changes to highlight that push us to the more accessible goal?

2 1

Re: [tor-dev] Pluggable Transports v1 spec rewrite.
by Hugo Maxwell Connery 29 Oct '15

29 Oct '15

Hi, A commendable effort. It is both deserved and pleasant that Tor hold the "gold standard" for a low latency, privacy enhancing, distributed, collaborative network. A perhaps more crowning achievement could be the fostering of a diverse ecosystem of related technologies. This effort continues to signal the Tor community's belief in open, free(dom), collaboration in the space. Hats off ! Hugo ________________________________________ Date: Thu, 29 Oct 2015 13:19:01 +0000 From: Yawning Angel <yawning(a)schwanenlied.me> To: tor-dev(a)lists.torproject.org Subject: [tor-dev] Pluggable Transports v1 spec rewrite. Message-ID: <20151029131901.3bbe0a20(a)schwanenlied.me> Content-Type: text/plain; charset="us-ascii" Hello all, In an attempt to make Pluggable Transports more accessible to other people, and to have a spec that is more applicable and useful to other projects that seek to use Pluggable Transports for circumvention, I have drafted a re-write of the spec. This is not intended to alter existing behavior, but instead make it clear that the whole "Pluggable Transports" thing isn't just for Tor. Unless people have serious objections, this will replace the existing PT spec, to serve as a stop-gap while the next revision of the PT spec (that does alter behavior) is being drafted/implemented. Regards, -- Yawning Angel

1 0

Reminders: this week's Tor dev meeting is still at 1330 UTC today
by Nick Mathewson 28 Oct '15

28 Oct '15

Hi! Reminder 1: There is a weekly meeting where we talk about development progress on the program "tor". Reminder 2: It has been at 1330 UTC; it is still at 1330 UTC for this week. (Remember, some of the world has made DST changes, but not all of the world.) Reminder 3: It will be at a different time (TBD) next week. Thanks, all! -- Nick

1 0

TB 5.0.3 for OpenBSD released
by attila 28 Oct '15

28 Oct '15

The Tor BSD Diversity Project (TDP) is proud to announce the release of Tor Browser (TB) version 5.0.3 for OpenBSD. TDP (https://torbsd.github.io) is an effort to extend the use of the BSD Unixes into the Tor ecosystem, from the desktop to the network. The 5.0.3 release is the sixth release of the Tor Browser from TDP. To install TB for OpenBSD, please see http://mirrors.nycbug.org/pub/snapshots/packages/amd64/README if you are running OpenBSD -current on amd64. TDP is focused on diversifying the Tor network, with TB being the flagship project. Additional efforts are made to increase the number of *BSD relays on the Tor ntwork. Since its launch in March 2015, TDP has made significant contributions. In addition to the TB releases, both BSDCan and BSDCon Brasil featured TDP-focused meetings. In early October, the TDP focused presentation (http://www.queair.net/br-pres) prompted a significant increase in Tor relays in Brazil. Before the presentation, there were around 22 Tor relays, all of which were Linux in addition to two Windows nodes. In the weeks after the presentation, several new *BSD Tor relays appeared, accounting for up to 35% of bandwidth provided by new Tor relays in Brazil. Finally, TDP is working to convince BSD-using businesses to follow Mozilla's December 2014 example to run Tor relays. At this point, New York Internet has commited to running two high-bandwidth relays, one FreeBSD and the other OpenBSD, at its facility in Bridgewater, New Jersey. TDP's source code repository resides at http://github.com/torbsd. If you want to build the ports from source under OpenBSD-current the current tarball is available at http://bits.haqistan.net/~attila/tbb.tgz Feel free to bug me if you need help (contact infos on my home page: http://trac.haqistan.net/~attila) TDP is seeking funding to continue and extend its efforts. Please contact us if interested in assisting TDP, allowing us to dedicate more time to the project. Pax, -A -- http://trac.haqistan.net | attila(a)stalphonsos.com | 0xE6CC1EDB

2 1

Feedback on CollecTor web redesign
by Karsten Loesing 28 Oct '15

28 Oct '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi devs, I just finished a redesign of the CollecTor website and would appreciate your feedback: https://metrics.torproject.org/index2.html For reference, the old CollecTor website is still available here: https://metrics.torproject.org/index.html https://metrics.torproject.org/formats.html Let me add that I'm not a web designer, and let me prove that statement by telling you that <i>all</i> HTML on that website was written using vim. I'm more than happy to accept patches or suggestions, though I'll likely ask you to explain them to me. Thanks! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJWJpaaAAoJEJD5dJfVqbCr8/YIAIimH7j5Z2qr7OwfhBrH20MJ fNoBEdFBjSveWTYsB/77yZx1mEtDTXI/FCCQM5AURmE82SUJQ1Ocumn+J2mVgdmh hobxFrQBnsSWdK0qDtyNc7U5oDX7P6ruoBdfwBtFppXpp/VHkFsU0TIiMxcqGcUH yuHzRlaSIUpOXzaFl4STeEM9zmFqaR8+qayteWrWQpLMHf3SOksXKcr14+8CZmsl C7YopnoLqglo0dQA9FjM3U+w9MnEoHHskN4Yl4ZkQFGYPziqNRFTHmvCoKEMUz3u 0o1Emcmxc9jaZbyBU8Vbh474uEXM2ZtWSlMUt9M3dBRkIyuHy6lcBMS5q3i2wXc= =hHc4 -----END PGP SIGNATURE-----

5 9