January 2017 - tor-dev - lists.torproject.org

[collector] CollecTor Release 1.1.2
by iwakeh 17 Jan '17

17 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! another CollecTor version is available: https://dist.torproject.org/collector/1.1.2/ The release provides the following changes * CollecTor now uses the correct type annotation "@type tordnsel 1.0" for exit lists again [0], and * The build process now complies to a Metrics java standard build environment [1]. In addition, the main CollecTor instance and collector.sky-ip.org mirror provide correct exit-lists again as of today. See our mirror list [2]. Other mirror operators should upgrade and process their mirrors exit-lists. A script for the latter is available in the release tarball. Please direct comments and questions to the metrics-team mailing list [3]. And, of course, bug reports [4] or feature requests [5] can be filed in trac. Cheers, iwakeh [0] https://trac.torproject.org/projects/tor/ticket/21195 [1] https://trac.torproject.org/projects/tor/ticket/20596 [2] https://trac.torproject.org/projects/tor/wiki/org/teams/MetricsTeam/Operati… [3] https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team [4] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… [5] https://trac.torproject.org/projects/tor/newticket?component=Metrics/Collec… -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJYfk1MAAoJEPeEx9Sa/gvijAwQAII81X0vWPLA7YbecHQLZJTA LJqH3ODOpJAZZIrLuk+W4QUlyA/W1EmvSFCbDjUabnsc5d76lKzKJLGu9DlPDJSw Gwb4UBQp+9Gi8wyaYLqHCoRJiGf+JvZnHAQK9/FvBQUDYkyz0ghTuGHLn/JGmNPV w220fdPOZ7kEfYzuqFT8vY4eZBKxL7uLbaiU2GbYfykV3be34q9rUjmDtWoPHQ5u FfFbzdQxDFaeRTKiWhXOG1He2epKeZezxZJBUQTotpSotaTjH3NFP+oJCsPUmPej G5td1glJ2kBcl+b61TXtVMaCUVgw9otx9bsogQnY2ceTCL8iR5M2eNP1queI6gZ8 NgPh8KGsjXMmYlPmER1UedaBgf8YcYdlKchUtMLuWVPPX0QTaAdC3eLtuLNPxOWX +lbFkCiH9hJ+1i4TktJ/XiBf0lBBvZCzkSBA5U0N0LEMTSkBIv9oh5wnP/AtoFLN DFAtnHsOLXPz8mTtvBivHzTurwIL83FHs64Bm4nh2uPQ4iX/P1JzWLaIo8tGOVEO pAJtEZGAzKMWTb96kIsLehXKgRTPAR+LAeWirwa+yY65YuhKNCKWz0jbG9s/6NAv HggzcltuHibgr64D8LhlgSY6om9zwtEGH3NG26Zcd1pZAbQkIlr4c6qcKQF4C0AB s+YXdtoVFpOfc3TiEEli =DvuO -----END PGP SIGNATURE-----

1 0

txtorcon 0.18.0
by meejah 12 Jan '17

12 Jan '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 txtorcon 0.18.0 is released, improving error-reporting when you have SAFECOOKIE or COOKIE authentication turned on but can't read the file. * https://github.com/meejah/txtorcon/issues/200 You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.18.0 https://github.com/meejah/txtorcon/releases/tag/v0.18.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.18.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.18.0.tar.gz.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check 12be80f1d5e2893378c6e8c752cf159479f868f8424e16b34b75cd679a0ab171 dist/txtorcon-0.18.0.tar.gz cffe063dbcedd9d344e88a572c0de39b0390562165a865efa27019260c2119f6 dist/txtorcon-0.18.0-py2-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJYdp4sAAoJEMJgKAMSgGmnxCIH/iiFJdYtbSnShAktDrwMuL6K tJN+AALrr6zIydjIVG4pNuGydoxqtmrpb/12xNn/c7noEWZpuuHd+hn/PRn+XNaA Gh+q4922VKs3ZCFYFClVAkZFtT5iug7EKnB6n0IKt4Z+rVAzRTCpHqgnCmmavHP1 s55jkYc+emC/jzGag22sD7HnPYHjkuKV+qy1Y6mF1//oD9FFhJUXvn5FVjf9cNb/ xta7HB3AMXp/8qdpURPJaJBjWOg1BxSVBngZXYiUJkkoOReOJU1ngDoU0J7VjQJq Uyi2ijwylUnK6/7qLLS8pwyX/UmWgV7NeQgIr00Shsm7Jv+zkk0QhXbnwJo8pRQ= =oJqn -----END PGP SIGNATURE-----

1 0

txtorcon 0.18.0
by meejah 12 Jan '17

12 Jan '17

1 0

SipHash Impact on TCP ISN skew fingerprinting
by bancfc＠openmailbox.org 11 Jan '17

11 Jan '17

SipHash a fast PRF by DJB has been adopted upstream across the Linux networking stack landing in 4.11. It deprecates a lot of ancient and broken crypto like MD5 for initial sequence number hashes. Its my guess that that timer values added in ISNs should now be indistinguishable from the rest of the hashed secret outlined in RFC-6528.[1] Can anyone knowledgeable in reading kernel code [2] please confirm that this kills clock skew extraction [3] and fingerprinting [4] described in Steven Murdoch's papers? Its one of the advanced attacks we've been following for some time now and would be good to write it off. *** [1] https://tools.ietf.org/html/rfc6528 [2] http://lkml.iu.edu/hypermail/linux/kernel/1701.1/00076.html [3] http://sec.cs.ucl.ac.uk/users/smurdoch/papers/ih05coverttcp.pdf (pages 7-8) [4] http://sec.cs.ucl.ac.uk/users/smurdoch/papers/ccs06hotornot.pdf

2 1

ExcludeExitNodes and ExcludeNodes but no "ExcludeEntryNodes"?
by nusenu 09 Jan '17

09 Jan '17

Hi, is there a possibility to blacklist guard relays (only in that position) from a client perspective? I didn't find one in the torrc man page. It is generally a bad idea to create custom tor client footprints by excluding relays but maybe it is less bad to exclude a certain relay just in the guard position than to exclude it completely via ExcludeNodes + StrictNodes since guards are used for a longer timeperiod. thanks, nusenu

2 1

Remaining 4 bits in prop224 addresses
by Jesse V 06 Jan '17

06 Jan '17

Hello all, I've been closely following the other Proposal 224 threads regarding the next-generation of onion services. I'm glad to see that we have a timeline and plan for migrating the network. One unresolved point is what to do with the remaining 4 bits in the longer addresses. Section 1.2 in the 224 document states "Note that since master keys are 32 bytes long, and 52 bytes of base 32 encoding can hold 260 bits of information, we have four unused bits in each of these names." It seems a waste for these to be zeroed out. The four bits could also be used to hold client-side flags, but I'm not aware of any applicable client settings that could be used here. I suggest that we use them as a checksum. (wasn't this proposed in Arlington?) Since speed isn't a priority, aside from Adler-32 or some CRC function, we could also hash the 32-byte key and use the first four bits of the hash. I think a checksum is best because it helps ensure data integrity when the address is shared online, copy/pasted, or physically written down. Bitcoin addresses contain a checksum as well for exactly this reason. They use a combination of SHA-256 and RIPEMD-160 to compute the checksum component. Source: 1) https://en.bitcoin.it/wiki/Technical_background_of_version_1_Bitcoin_addres… 2) https://bitcoin.stackexchange.com/questions/32353/ What do we think about a checksum, or do we have other plans here? I ask because once we nail down the address format, I can add support for 224 into my Onion Name System. -- Jesse

4 7

Re: [tor-dev] blacklisting relays with end-to-end correlation capabilities?
by nusenu 03 Jan '17

03 Jan '17

Sebastian Hahn wrote (2016-12-08): >> On 08 Dec 2016, at 14:03, nusenu <nusenu(a)openmailbox.org> wrote: >> >> Dear tor directory authorities, >> >> TLDR: Would you blacklist relays with end-to-end correlation capabilities? > > > I do not think that this is worthwhile. It establishes a precedent where > setting your contact info is something that gets you banned, potentially > incorrectly because it's unauthenticated, whereas we're unable to identify > people who actually maliciously run several relays without such indicators. > > Additionally, it's yet one more thing to update the dirauths' configs > for, but with rather more overhead as we might get multiple mails back > and forth about how MyFamily is annoying to maintain, how they're just > trying to help, etc. All not so bad arguments. > > If we did this, also why would we blacklist the nonexit relays? That > seems to not make sense, as a relay operator could have multiple relays > that act as guard and exit simultaneously. I think we'd need to > blacklist at least all the exit relays, if not all of them. BadExiting > them would then be the more sensible choice. Scarcity of resources has > in the past led us to bad designs like Valid/Invalid relays etc, which > causes way more annoyances than good things. I understand dir auth operators have limited resources, but if you (most of the dir auths) agree that blacklisting specific relays to protect tor end users makes sense: Would you agree on handling a limited amount (6?) of such 'end-to-end' cases per year? I.e. one case every 2 months if the operator has a guard probability >0.1% and exit_probability >0.1% and didn't fix the problem within a month after getting contacted? Note: Luckily the list of such known potential operators is currently very short (<5). In the past month I had some positive effect when trying to contact relay operators [1], but unfortunately the biggest operators (by consensus weight) are not to motivated to fix their configuration in a reasonable time frame. thanks, nusenu [1] https://lists.torproject.org/pipermail/tor-relays/2016-December/011520.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011507.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011476.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011486.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011521.html https://lists.torproject.org/pipermail/tor-relays/2016-December/011426.html

1 0