[tor-dev] Two new Onionoo versions 2.4 and 2.5 add new effective_family and measured fields
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi devs, I was reminded by Harmony that I said a while back [0] that I would announce new Onionoo versions on this list and not only in private message to Harmony for including them in the next TWN issue. Oops. So, version 2.4 added a new effective_family field to details documents, listing all the relays with which the relay in question is in an effective, mutual family relationship. The main goal here is to make it easier to detect misconfigured relay families. This can be relay operators or friendly people watching over the Tor network and reminding relay operators to fix their configurations. [1] The new version 2.5 that I deployed this week adds the optional measured field to details documents. The main idea behind this new field is that relay operators and Tor network debuggers can now figure out easily whether a relay is affected by not being measured by a sufficient number of bandwidth authorities and as a result has lower usage than it could handle. This field is not yet displayed by the Onionoo clients Atlas or Globe, but it's accessible via Onionoo's API [2]. More details are on ticket #16020 [3]. All the best, Karsten [0] onionoo-announce@ posting from April 27, 2015 [1] https://lists.torproject.org/pipermail/tor-news/2015-August/000109.html [2] https://onionoo.torproject.org/protocol.html#details [3] https://trac.torproject.org/projects/tor/ticket/16020 -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJV1HYeAAoJEJD5dJfVqbCrFJAIAIQYIC0CiSx6GJJikQ6CTxgw +AljFxABfnLtHu58EtBLx1jRJo0u9fStCMA/YFWLiq3FmEhCb5YvoL4zwa92PwlN bIoEricgq3sXjOm6TxJ75/6OBeH8AVIsah6qxHFkVfCPwjmt0bsDyaE7VqlCv2tN tAunIZcDyhsStGOOErr5uc9FHgPquvb66Iy7YFwnJxioMRE3yp4GBTDv78WyUEuR TZOWBh/cbJYrwSu5b+vU3C+t9eAI9ErQ8BDYlwy0C6zgJO+paSUkxWkCvuI3nv2l e/Ol6M40c9syZEb5jexn3K3NTOpJCKKhjXoXtP7UHXz8ZSdhZw2gxi31ZXYrSkQ= =/rwg -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Feature freeze plans for Tor 0.2.7: Please read if you hack Tor!
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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Seeing through Network-Protocol Obfuscation
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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Seeing through Network-Protocol Obfuscation
NB: quickly responding before I go to bed. On Wed, 19 Aug 2015 14:13:03 -0400 Philipp Winter p...@nymity.ch wrote: 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. Not surprised for obfs3/4 since they're mounting an entropy attack which is explicitly outside of the stated threat model for both protocols. The FTE semantic attack they presented isn't the easiest one I know of (the GET request as defined by the regex is pathologically malformed). Haven't looked at the meek portion of the paper. 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. Dunno. Others probably have a better idea on what average internet traffic looks like these days. 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. Coming up with something better than obfs4/meek would be nice. At this point I'm viewing obfs4 as more of a minimum standard than anything else. It's worth noting that Dust2 (mostly done but not yet deployed) can reduce payload entropy to match a target distribution, but will have issues with protocol whitelist based DPI. Regards, -- Yawning Angel pgpFY2al5Ysy5.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Proposal: Merging Hidden Service Directories and Introduction Points
On 12/07/15 22:48, John Brooks wrote: 1.3. Other effects on proposal 224 An adversarial introduction point is not significantly more capable than a hidden service directory under proposal 224. The differences are: 1. The introduction point maintains a long-lived circuit with the service 2. The introduction point can break that circuit and cause the service to rebuild it Regarding this second difference: the introduction point (cooperating with a corrupt middle node) could potentially try to discover the service's guard by repeatedly breaking the circuit until it was rebuilt through the corrupt middle node. Would it make sense to use vanguards here, as well as on rendezvous circuits? Cheers, Michael 0x9FC527CC.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] bwauths: Are you publishing your output somewhere?
Hi, since a request to make bwauth output available has been closed as wontfix previously [1] I'm not going to ask whether this data would be added to CollecTor, but maybe bwauth ops are publishing it 'inofficially' (like Tom does [2]) for the dir auth to fetch already and would be willing to disclose the URI to the files? thanks! (one can also use the votes [3] to find out what the dir auth submitted but the raw bwauth files would include the timestamps/frequency) [1] https://trac.torproject.org/projects/tor/ticket/2532 [2] https://bwauth.ritter.vg/bwauth/ [3] https://collector.torproject.org/recent/relay-descriptors/votes/ signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
