- tor-dev - lists.torproject.org

log: ORPort/DirPort address does not match descriptor address
by nusenu 24 Jan '17

24 Jan '17

Hi, how bad is it to simply ignore ORPort/DirPort address mismatch log entry on a relay behind (1:1) NAT? I assume tor figures out the public IPv4 address anyway, no? The IPv4 ORPort address 192.168.1.1 does not match the descriptor address 1.2.3.4. If you have a static public IPv4 address, use 'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'. I'm explicitly specifying (private) IP addresses in ORPort/DirPort (and OutboundBindAddress) lines to avoid binding to the same ports when running >2 instances (with >1 public IP). https://github.com/nusenu/ansible-relayor/issues/101 thanks, nusenu

3 5

GAEuploader
by Katherine Li 23 Jan '17

23 Jan '17

Hello Tor-Dev Community, GAE(Google App Engine) uploader has just released v1.0-beta. GAEuploader enables clients to set up their own private meek-google in one easy step: just run it and paste the bridge line into Tor Browser. Background information: Meek <https://trac.torproject.org/projects/tor/wiki/doc/meek#Overview> is pluggable transport that uses domain fronting. Meek-google got suspended <https://lists.torproject.org/pipermail/tor-talk/2016-June/041699.html>, but clients can set up their own Google App Engine app and configure their Tor Browser accordingly. However, the process of creating and deploying the Google App Engine can be confusing. GAEuploader significantly simplifies this process for clients. I would really appreciate user testing on GAEuploader. You can download it at: https://github.com/katherinelitor/GAEuploader/releases README: https://github.com/katherinelitor/GAEuploader Tor wiki page, containing step-by-step screenshots of how to use: https://trac.torproject.org/projects/tor/wiki/doc/GAEuploader *GAEuploader runs on Mac or Linux, but currently does not support Windows. *GAEuploader uses the Google Cloud SDK <https://cloud.google.com/sdk/docs/#linux>. If you are interested in how GAEuploader works, the README contains the list of commands that were run. If you have any questions, feedback or bug reports, please email me at katherineli.tor(a)gmail.com. I will respond promptly. Best, Katherine Li

3 2

txtorcon support for Twisted 12, 13, 14
by meejah 20 Jan '17

20 Jan '17

I am considering dropping support for Twisted 12, 13 and 14 in the next txtorcon release. Also, TLS support (i.e. pyOpenSSL) will become mandatory as well (that is, the dependency will be on twisted[tls]). Twisted 12 is only there because of Debian wheezy. Twisted 13 is for wheezy-backports and 14 is for jessie ("stable"). jessie-backports has 16.2.0 and stretch has 16.6.0 Hence I do not believe upgrading this dependency will be a problem for Debian packaging. I do not know the implications for other distributions. Feedback requested if this will negatively affect you! -- meejah

2 2

Release: sandboxed-tor-browser-0.0.3
by Yawning Angel 18 Jan '17

18 Jan '17

Hello, I just tagged sandboxed-tor-browser 0.0.3. Binaries will be built when the next Tor Browser build happens (soon). The dependencies (both build and runtime) have changed, end users should install `libnotify` in the unlikely event that it is not already present, though basic functionality should not be broken even if it is missing. The major changes since last version are: * 32 bit x86 support has been deprecated. * Numerous installer/updater improvements including periodic background update checks (requires libnotify for notifications) and using `.onions` when fetching installer/updater metadata. * Fixes for various crash/functionality bugs, including problems relating to certain versions of bubblewrap failing to launch with errors related to `setsid`[0]. Full details are available in the ChangeLog, and the code is still at https://gitweb.torproject.org/tor-browser/sandboxed-tor-browser.git/ Regards, -- Yawning Angel [0]: If people are encountering this, particularly with the Debian package, either upgrade `sandboxed-tor-browser` to the new release, or update bubblewrap to 0.1.7 or later.

1 0

RFC: Tor long-term support policy
by Nick Mathewson 18 Jan '17

18 Jan '17

Hi, all! This is a draft for a tor long-term support policy for the program "tor". Please let me know what you think. It's based on earlier work and surveys, but it isn't final till we say it is, and it needs more commentary. Please keep in mind that dropping support for any old release is an inconvenience to some nice busy people, and that supporting any old release is an inconvenience to other nice busy people. Therefore, "don't inconvenience anybody" is not a viable goal here: instead we are stuck with a balancing act. Also please remember the bikeshed. ;) http://bikeshed.com/ == Background == In the past, Tor has had no actual policy for how long we support older releases of the core "tor" network program. We've aimed for informal rules like "support old releases as long as it isn't too much trouble," or "support old releases as long as a lot of people really need it," but these aren't working so well with our new release schedule. The good thing about our new release schedule is that we try to put out two stable release series per year, when previously we were finishing release series once every ~18 months. But this means that, to support the last N years of releases, we need to support three times as many older release series as we did before. This won't scale, and probably isn't a good use of our time. Therefore, we're adopting a practice from several other free software projects with a rapid release schedule: we are going to support some Tor releases for different amounts of time than others. == Levels of support == Here's the plan. * Every new release series will be supported for at least nine months after it becomes stable, and for at least three months after another release series becomes stable. Example: * The first 0.2.8.x stable release was released in August 2016. So it will be supported until at least 9 months later, in May 2017. But if the first 0.2.9.x stable release had not been released until April 2017, we'd keep supporting 0.2.8.x for another 3 months past that point, to July 2017. * Occasionally, we will designate some Tor release series as "long-term support" releases. These will be supported for an amount of time to be announced in advance -- typically, for 3 years. * For the release series that exist today, we will support them according to the schedule at the end of this document. == What does support entail? == For all supported releases, we intend: * Information needed to connect to the Tor network (directory authorities, fallback directories, geoip tables) will be kept up-to-date. * Important security issues will get fixed. * Major stability issues will get fixed. * Portability regressions will get fixed. * Portability bugs to major supported platforms will get fixed. For the most recent supported stable release only: * Misleading documentation will get fixed. * Smaller bugs that significantly impact user experience will get fixed. We do NOT expect: * That directory authorities will be able to run any but the two most recent stable releases. * That unsupported releases will all work on the Tor network. * That unsupported releases will all fail to work on the Tor network. * That older supported releases will provide the same privacy as the newer ones. == The obligatory disclaimer == This document is about plans, not promises. We'll try hard to follow through on these plans, but it's always possible that something unexpected will happen and we'll need to choose between following this policy to the letter and maintaining our users' security. If that happens, we'll aim for protecting our users. == Plan for current releases == 0.2.4.x, 0.2.6.x, and 0.2.7.x, will all receive at least one more stable release. Support for them will end on 1 August 2017. 0.2.8.x will be supported until 1 January 2018. 0.2.5.x is retroactively declared an LTS release, and will be supported until 1 May 2018. 0.2.9.x is an LTS release, and will be supported until at least 1 January 2020.

6 6

[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