Posts by nickm

Tor 0.3.1.4-alpha is released (with security update for clients)

by nickm | June 29, 2017

Hello again! This post announces the fourth alpha in the 0.3.1.x series, which we just released today. There's a stable release too; I'll mention that in the next post.

Tor 0.3.1.4-alpha fixes a path selection bug that would allow a client to use a guard that was in the same network family as a chosen exit relay. This is a security regression; all clients running earlier versions of 0.3.0.x or 0.3.1.x should upgrade to 0.3.0.9 or 0.3.1.4-alpha.

This release also fixes several other bugs introduced in 0.3.0.x and 0.3.1.x, including others that can affect bandwidth usage and correctness.

Since this is an alpha release, you can expect more bugs than usual. If you'd rather have a more stable experience, stick to the stable releases.

If you build Tor from source, you can find Tor 0.3.1.4-alpha at the usual place (at the Download page on our website). Otherwise, you'll probably want to wait until packages are available. There should be a new Tor Browser release early next week.

Changes in version 0.3.1.4-alpha - 2017-06-29

  • New dependencies:
    • To build with zstd and lzma support, Tor now requires the pkg-config tool at build time. (This requirement was new in 0.3.1.1-alpha, but was not noted at the time. Noting it here to close ticket 22623.)
  • Major bugfixes (path selection, security):
    • When choosing which guard to use for a circuit, avoid the exit's family along with the exit itself. Previously, the new guard selection logic avoided the exit, but did not consider its family. Fixes bug 22753; bugfix on 0.3.0.1-alpha. Tracked as TROVE-2016- 006 and CVE-2017-0377.

 

Tor 0.3.0.8 is released, with a fix for hidden services! (Also As are 0.2.4.29, 0.2.5.14, 0.2.6.12, 0.2.7.8, 0.2.8.14, and 0.2.9.11)

by nickm | June 8, 2017

Hello!
Source code for a new Tor release (0.3.0.8) is now available on the
website. Among other things, it fixes two issues in earlier versions
of the hidden service code that would allow an attacker to cause a
hidden service to exit with an assertion failure.

If you're running a hidden service, you should upgrade to this
release, or one of the other versions released today.  Source is
available on the website now; packages should be available over the
next several days.

Concurrently with 0.3.0.8, the following versions are also now
available: 0.2.4.29, 0.2.5.14, 0.2.6.12, 0.2.7.8, 0.2.8.14, and
0.2.9.11.  You can find them all at https://dist.torproject.org/

One last reminder: Tor 0.2.4, 0.2.6, and 0.2.7 will no longer be
supported after 1 August of this year.  Tor 0.2.8 will not be
supported after 1 Jan of 2018.  Tor 0.2.5 will not be supported after
1 May of 2018.  If you need a release with long-term support, 0.2.9 is
what we recommend: we plan to support it until at least 1 Jan 2020.

Below are the changelogs for the new stable releases:


Tor 0.3.0.8 fixes a pair of bugs that would allow an attacker to remotely crash a hidden service with an assertion failure. Anyone running a hidden service should upgrade to this version, or to some other version with fixes for TROVE-2017-004 and TROVE-2017-005.

Tor 0.3.0.8 also includes fixes for several key management bugs that sometimes made relays unreliable, as well as several other bugfixes described below.

Changes in version 0.3.0.8 - 2017-06-08

  • Major bugfixes (hidden service, relay, security, backport from 0.3.1.3-alpha):
    • Fix a remotely triggerable assertion failure when a hidden service handles a malformed BEGIN cell. Fixes bug 22493, tracked as TROVE-2017-004 and as CVE-2017-0375; bugfix on 0.3.0.1-alpha.
    • Fix a remotely triggerable assertion failure caused by receiving a BEGIN_DIR cell on a hidden service rendezvous circuit. Fixes bug 22494, tracked as TROVE-2017-005 and CVE-2017-0376; bugfix on 0.2.2.1-alpha.
  • Major bugfixes (relay, link handshake, backport from 0.3.1.3-alpha):
    • When performing the v3 link handshake on a TLS connection, report that we have the x509 certificate that we actually used on that connection, even if we have changed certificates since that connection was first opened. Previously, we would claim to have used our most recent x509 link certificate, which would sometimes make the link handshake fail. Fixes one case of bug 22460; bugfix on 0.2.3.6-alpha.

Tor 0.3.1.3-alpha is released, with a security fix for hidden services.

by nickm | June 8, 2017

Hello again! This post announces the third alpha in the 0.3.1.x series, which I just released today. There were stable releases too; I'll go over them in the next post.

Tor 0.3.1.3-alpha fixes a pair of bugs that would allow an attacker to remotely crash a hidden service with an assertion failure. Anyone running a hidden service should upgrade to this version, or to some other version with fixes for TROVE-2017-004 and TROVE-2017-005.

Tor 0.3.1.3-alpha also includes fixes for several key management bugs that sometimes made relays unreliable, as well as several other bugfixes described below.

Since this is an alpha release, you can expect more bugs than usual. If you'd rather have a more stable experience, stick to the stable releases.

If you build Tor from source, you can find Tor 0.3.1.2-alpha at the usual place (at the Download page on our website). Otherwise, you'll probably want to wait until packages are available.

Changes in version 0.3.1.3-alpha - 2017-06-08

  • Major bugfixes (hidden service, relay, security):
    • Fix a remotely triggerable assertion failure when a hidden service handles a malformed BEGIN cell. Fixes bug 22493, tracked as TROVE-2017-004 and as CVE-2017-0375; bugfix on 0.3.0.1-alpha.
    • Fix a remotely triggerable assertion failure caused by receiving a BEGIN_DIR cell on a hidden service rendezvous circuit. Fixes bug 22494, tracked as TROVE-2017-005 and CVE-2017-0376; bugfix on 0.2.2.1-alpha.
  • Major bugfixes (relay, link handshake):
    • When performing the v3 link handshake on a TLS connection, report that we have the x509 certificate that we actually used on that connection, even if we have changed certificates since that connection was first opened. Previously, we would claim to have used our most recent x509 link certificate, which would sometimes make the link handshake fail. Fixes one case of bug 22460; bugfix on 0.2.3.6-alpha.

 

Tor 0.3.1.2-alpha is out (with notes about 0.3.1.1-alpha)

by nickm | May 26, 2017

Hello again! This post announces the second alpha in the 0.3.1.x series, which I just released today. And since the blog was down when the first alpha came out, I'm posting the changelog for 0.3.1.1-alpha below too.

Tor 0.3.1.2-alpha is the second release in the 0.3.1.x series. It fixes a few bugs found while testing 0.3.1.1-alpha, including a memory corruption bug that affected relay stability.

Since this is an alpha release, you can expect more bugs than usual.

If you build Tor from source, you can find Tor 0.3.1.2-alpha at the usual place at the Download page on our website. Otherwise, you'll probably want to wait until packages are available. The next Tor Browser alpha release with this version of Tor will likely come out in mid-June.

Changes in version 0.3.1.2-alpha - 2017-05-26

  • Major bugfixes (crash, relay):
    • Fix a memory-corruption bug in relays that set MyFamily. Previously, they would double-free MyFamily elements when making the next descriptor or when changing their configuration. Fixes bug 22368; bugfix on 0.3.1.1-alpha.
  • Minor bugfixes (logging):
    • Log a better message when a directory authority replies to an upload with an unexpected status code. Fixes bug 11121; bugfix on 0.1.0.1-rc.
  • Minor bugfixes (memory leak, directory authority):
    • When directory authorities reject a router descriptor due to keypinning, free the router descriptor rather than leaking the memory. Fixes bug 22370; bugfix on 0.2.7.2-alpha.

Changes in version 0.3.1.1-alpha - 2017-05-22

Tor 0.3.1.1-alpha is the first release in the 0.3.1.x series. It reduces the bandwidth usage for Tor's directory protocol, adds some basic padding to resist netflow-based traffic analysis and to serve as the basis of other padding in the future, and adds rust support to the build system.

It also contains numerous other small features and improvements to security, correctness, and performance.

Below are the changes since 0.3.0.7.

  • Major features (directory protocol):
    • Tor relays and authorities can now serve clients an abbreviated version of the consensus document, containing only the changes since an older consensus document that the client holds. Clients now request these documents when available. When both client and server use this new protocol, they will use far less bandwidth (up to 94% less) to keep the client's consensus up-to-date. Implements proposal 140; closes ticket 13339. Based on work by Daniel Martí.
    • Tor can now compress directory traffic with lzma or with zstd compression algorithms, which can deliver better bandwidth performance. Because lzma is computationally expensive, it's only used for documents that can be compressed once and served many times. Support for these algorithms requires that tor is built with the libzstd and/or liblzma libraries available. Implements proposal 278; closes ticket 21662.
    • Relays now perform the more expensive compression operations, and consensus diff generation, in worker threads. This separation avoids delaying the main thread when a new consensus arrives.
  • Major features (experimental):
    • Tor can now build modules written in Rust. To turn this on, pass the "--enable-rust" flag to the configure script. It's not time to get excited yet: currently, there is no actual Rust functionality beyond some simple glue code, and a notice at startup to tell you that Rust is running. Still, we hope that programmers and packagers will try building Tor with Rust support, so that we can find issues and solve portability problems. Closes ticket 22106.