- tor-dev - lists.torproject.org

Feature freeze plans for Tor 0.2.7: Please read if you hack Tor!
by Nick Mathewson 25 Aug '15

25 Aug '15

Hi, all! Here's the schedule we worked out for the Tor 0.2.7 feature freeze. (These are defaults, not promises. We can make exceptions, but please remember that delaying a freeze will delay release, and every day we delay a release will delay all the _other_ features getting out into a stable Tor. We've been aiming to speed up our release cycle, and this represents the latest installment in that effort.) Sep 1: Last day to merge (most) feature patches into 0.2.7. I'll make an exception for small features that get permission in advance and don't seem likely to endanger stability. If you want to nominate a ticket as such a feature, **and you are going to implement it**, please add the PostFreeze027 tag to it ASAP. Make sure it's in before next week's dev meeting at the earliest. Also please don't drop a huge branch on me on August 27 and expect me to have it merged by Sep 1. :) Sep 15: Last day to merge non-critical patches into 0.2.7. After this date, we won't accept any more features for 0.2.7. We also won't accept most bugfixes: bugfixes will only be accepted for regressions, security bugs, stability bugs, documentation, and typos. When it's ready: we put out a stable 0.2.7. peace, -- Nick

3 2

request for advice regarding bug 15901
by starlight.2015q3＠binnacle.cx 23 Aug '15

23 Aug '15

Could someone familiar with consensus document downloading, manipulation and validation by the tor relay examine the most recent post to bug #15901 and comment with advice regarding an idea I have for isolating the problem? Tor #15901: apparent memory corruption -- very difficult to isolate https://trac.torproject.org/projects/tor/ticket/15901#comment:20 Thank You

1 0

"Seeing through Network-Protocol Obfuscation"
by Philipp Winter 22 Aug '15

22 Aug '15

<https://kpdyer.com/publications/ccs2015-measurement.pdf> They claim that they are able to detect obfs3, obfs4, FTE, and meek using entropy analysis and machine learning. I wonder if their dataset allows for such a conclusion. They use a (admittedly, large) set of flow traces gathered at a college campus. One of the traces is from 2010. The Internet was a different place back then. I would also expect college traces to be very different from country-level traces. For example, the latter should contain significantly more file sharing, and other traffic that is considered inappropriate in a college setting. Many countries also have popular web sites and applications that might be completely missing in their data sets. Considering the rate difference between normal and obfuscated traffic, the false positive rate in the analysis is significant. Trained classifiers also seem to do badly when classifying traces they weren't trained for. The authors suggest active probing to reduce false positives, but don't mention that this doesn't work against obfs4 and meek. Cheers, Philipp

3 7

Re: [tor-dev] Number of directory connections
by tordev123＠Safe-mail.net 21 Aug '15

21 Aug '15

-------- Original Message -------- From: Yawning Angel <yawning(a)schwanenlied.me> Subject: Re: [tor-dev] Number of directory connections Date: Fri, 21 Aug 2015 16:49:18 +0000 >> It looks like when the consensus is older than 5 days, a directory authority is used (and the >> UseEntryGuardsAsDirGuards setting basically ignored). >> >> I can't think of a good reason for that behavior. Is there a valid >> security issue using an old consensus to fetch the current one from >> the entry guard? > > Your entry guard being rejected as malicious by the DirAuths in the > intervening time period. But the new consensus would need to be signed by the directory authorities. Tor won't relay anything before it has the new valid consensus. So I don't see any issue with using a potentially malicious entry guard for obtaining the current consensus.

1 0

Re: [tor-dev] Number of directory connections
by tordev123＠Safe-mail.net 21 Aug '15

21 Aug '15

-------- Original Message -------- From: "l.m" <ter.one.leeboi(a)hush.com> Subject: Re: [tor-dev] Number of directory connections Date: Fri, 21 Aug 2015 09:31:25 -0400 > Oh I see, so they happened before. I wasn't sure about that. In that case the last consensus stored locally must have been many days old. If that's the case you would bootstrap from dirauths then use your guard for tunneling later directory request. I did some experiments. It looks like when the consensus is older than 5 days, a directory authority is used (and the UseEntryGuardsAsDirGuards setting basically ignored). I can't think of a good reason for that behavior. Is there a valid security issue using an old consensus to fetch the current one from the entry guard?

2 1

Re: [tor-dev] tor callgrinds
by coderman 21 Aug '15

21 Aug '15

On 2/16/07, Christopher Layne <clayne(a)anodized.com> wrote: > Thought you guys might find this interesting. I did a couple of callgrind > runs ... yes, really back to 2007 to find a callgrind on a relay. does anyone have a more recent profile of a busy relay, by chance? if none exist, what do i need to bribe you with? :) thank you! best regards,

1 0

Re: [tor-dev] Number of directory connections
by tordev123＠Safe-mail.net 21 Aug '15

21 Aug '15

-------- Original Message -------- From: George Kadianakis <desnacked(a)riseup.net> Subject: Re: [tor-dev] Number of directory connections Date: Fri, 21 Aug 2015 15:02:02 +0300 > There are many unlucky people whose guard is not a directory cache, so they have > to reach out to additional guards to get directory documents :x > > I think most powerful guards are directory caches, so most people are lucky in > the end. All people will be lucky when we finally implement and deploy #12538. Per the current consensus: Number of Guards: 1610 Number of V2Dir Guards: 1237 (77%) Total Guard Bandwidth: 27387966 Total V2Dir Guard Bandwidth: 22603019 (83%)

1 0

Re: [tor-dev] Number of directory connections
by tordev123＠Safe-mail.net 21 Aug '15

21 Aug '15

-------- Original Message -------- From: "l.m" <ter.one.leeboi(a)hush.com> Subject: Re: [tor-dev] Number of directory connections Date: Fri, 21 Aug 2015 08:02:22 -0400 > UseEntryGuardsAsDirGuards defaults to 1 in torrc. > > So if you did not change this default you will use entry guards for tunneling directory connections. Then there must be some bug given the 4 directory connections. The directory connections all happened before the entry node connection. torrc: ------------------------------------------------------------ DataDirectory [censored] GeoIPFile [censored] GeoIPv6File [censored] Socks5Proxy [censored] EntryNodes [censored],[censored],[censored] ------------------------------------------------------------

2 1

Number of directory connections
by tordev123＠Safe-mail.net 21 Aug '15

21 Aug '15

-------- Original Message -------- From: Mike Perry <mikeperry(a)torproject.org> Subject: [tor-dev] Proposal: Padding for netflow record resolution reduction Date: Thu, 20 Aug 2015 21:12:54 -0700 > Tor clients currently maintain one TLS connection to their Guard node to > carry actual application traffic, and make up to 3 additional connections to > other nodes to retrieve directory information. That doesn't seem to be the case. Tor from TBB 5.0 startup (directory info was a couple of days old): [GUARD] xxx.xxx.xxx.xxx:443 received: 17967 sent: 12865 [dizum] 194.109.206.212:443 received: 564549 sent: 19078 [Faravahar] 154.35.175.225:443 received: 253909 sent: 55616 [maatuska] 171.25.193.9:80 received: 132954 sent: 28519 [tor26] 86.59.21.38:443 received: 370630 sent: 80132 There were no other connection attempts.

3 2

Re: [tor-dev] Hash Visualizations to Protect Against Onion Phishing
by Jesse V 21 Aug '15

21 Aug '15

> Jacek Wielemborek <d33tah(a)gmail.com> writes: > >> George Kadianakis pisze: >>> Some real UX research needs to be done here, before we decide something terrible. >> >> Just curious, has anybody seen any cognitive studies on the SSH >> randomart visualisation? I always found them impossible to remember. >> Perhaps adding a bit more color could help... > Hm. Indeed. > > I can remember the general shape and edges of my SSH server's key, but not any > details. > > I doubt I would remember the randomart of like 10 onion websites, especially if > I didn't visit them regularly. But maybe I would remember the randomart of my > webmail better than my SSH server's. > The main issue is that there's always going to be a tradeoff between memorability and security. It's difficult to cram sufficient entropy into a visualization and expect people to remember it. I agree that coloring schemes or perhaps faces stand the best chance of memorability, but they are difficult to deploy. I wonder if a simpler scheme is sufficient. I suggest using a word-bank to generate a series of words. First, take the .onion address or the hidden service public identity key (basically the same thing for 224) and run it through scrypt or similar algorithm. Then, based on the output, select a series of words from the dictionary. Present the series of words in George's mockup (https://people.torproject.org/~asn/tbb_randomart/randomart_mockup.png) in lieu of the art. It's not a new idea to use a word-list for this purpose: I recall reading a paper suggesting to use a word-list to encode .onion addresses rather than base32. The scheme has also been deployed by websites; Gfycat, for example, shows a series of words in its URL to provide an identifier to user images. It's also successful in practice: everyone in the /r/globaloffensive subreddit recognizes the DelayedAutisticGuppy reference before they even open the gif. People remember random information best if it's grouped, but usually the maximum group size is about 4, which is why phone numbers are split with delimiters. To make it simple, I suggest showing one row of four words. Each character in a .onion address has 32 possible combinations. If you used a word-bank of 1,024 words, you cover two characters per word. If your dictionary consists of 32,768 words, you can capture three at a time. Assuming this latter case, if four words are used, you can cover 12 characters, or 60 bits. If you combine that with the number of characters in the address that users intrinsically check subconsciously, it's extremely difficult for an attacker to match all of them. The Shallot README indicates that it would take nearly 10 millenia to find a 12-character match, and this of course does not take into account a round of scrypt before the word-list is used. Everyone remembers "correct horse battery staple", right?

4 3