- tor-dev - lists.torproject.org

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

24 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 23 Aug '15

23 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

6th status report for OnioNS
by Jesse V 21 Aug '15

21 Aug '15

This status report covers three main points of progress for the Onion Name System (OnioNS) project. 1) Since my last report, I opened up this project for beta testing. The server logs show that a number of people opened and ran servers for some time, and a number of individuals claimed names for their hidden services. S7r was extremely helpful in beta testing, we had a very productive private conversation on IRC. He helped me identify bugs and several areas of improvement. He also reproduced a few show-stopping issues that I had considered closed, so I'll be taking care of those as soon as I can. It was a thorough test and I very much appreciate the help. 2) I spent a significant amount of time over the last few weeks rewriting my design paper. I applied two suggestions that I heard during PETS and the Arlington HS meeting: a) to switch from using the consensus for a global source of entropy to the new commit-and-reveal proposal, and b) to select members of the Quorum (the authoritative set of OnioNS nodes) with selection weight proportional to their consensus weight, rather than with even probability. Both of these turned out to be excellent ideas. The dirauth commitment protocol is far more resistant to attacks than my original scheme and the new Quorum selection technique is highly resistant to Sybil attacks. In fact, even if all Fast and Stable routers in the lowest 70 percentile by consensus weight are malicious, it's still extremely unlikely that a random Quorum selection will result in a situation where the attacker wins. 3) There's an upstream change that I forgot to mention in my last report: the fact that Tor 0.2.7 now creates and manages Ed25519 keys brings OnioNS one step closer towards integration with Tor: my design documents call for OnioNS servers to manage Ed25519 signatures. It's a stronger and faster cryptosystem than RSA and has much smaller signatures, which reduces the overhead of my data structures. Down the road, I should be able to use the online signing key, so I won't need to touch the offline identity key. As we come closer to the end of the Summer of Privacy timeline, I'm going to concentrate on addressing the bugs that s7r identified, finish implementing some security protocol, and try to move to a fully decentralized setup. Jesse V.

1 0