tor

Tor 0.3.0.6 is released: a new series is stable!

Tor 0.3.0.6 is the first stable release of the Tor 0.3.0 series.

With the 0.3.0 series, clients and relays now use Ed25519 keys to authenticate their link connections to relays, rather than the old RSA1024 keys that they used before. (Circuit crypto has been Curve25519-authenticated since 0.2.4.8-alpha.) We have also replaced the guard selection and replacement algorithm to behave more robustly in the presence of unreliable networks, and to resist guard- capture attacks.

This series also includes numerous other small features and bugfixes, along with more groundwork for the upcoming hidden-services revamp.

Per our stable release policy, we plan to support the Tor 0.3.0 release series for at least the next nine months, or for three months after the first stable release of the 0.3.1 series: whichever is longer. If you need a release with long-term support, we recommend that you stay with the 0.2.9 series.

If you build Tor from source, you can find it at the usual place on the website. Packages should be ready over the next weeks, with a Tor Browser release in late May or early June.

Below are the changes since 0.2.9.10. For a list of only the changes since 0.3.0.5-rc, see the ChangeLog file.

Changes in version 0.3.0.6 - 2017-04-26

  • Major features (directory authority, security):
    • The default for AuthDirPinKeys is now 1: directory authorities will reject relays where the RSA identity key matches a previously seen value, but the Ed25519 key has changed. Closes ticket 18319.
  • Major features (guard selection algorithm):
    • Tor's guard selection algorithm has been redesigned from the ground up, to better support unreliable networks and restrictive sets of entry nodes, and to better resist guard-capture attacks by hostile local networks. Implements proposal 271; closes ticket 19877.

  read more »

Tor 0.3.0.5-rc is released: almost stable!

Tor 0.3.0.5-rc fixes a few remaining bugs, large and small, in the 0.3.0 release series.

This is the second release candidate in the Tor 0.3.0 series, and has much fewer changes than the first. If we find no new bugs or regressions here, the first stable 0.3.0 release will be nearly identical to it.

You can download the source code from the usual place on the website, but most users should wait for packages to become available over the upcoming weeks. There should be a new Tor Browser alpha release containing Tor 0.3.0.5-rc some time later this month.

Please note: This is a release candidate, but not a stable release. Please expect more bugs than usual. If you want a stable experience, please stick to the stable releases.

Changes in version 0.3.0.5-rc - 2017-04-05

  • Major bugfixes (crash, directory connections):
    • Fix a rare crash when sending a begin cell on a circuit whose linked directory connection had already been closed. Fixes bug 21576; bugfix on 0.2.9.3-alpha. Reported by Alec Muffett.
  • Major bugfixes (guard selection):
    • Fix a guard selection bug where Tor would refuse to bootstrap in some cases if the user swapped a bridge for another bridge in their configuration file. Fixes bug 21771; bugfix on 0.3.0.1-alpha. Reported by "torvlnt33r".

  read more »

Updates for old Tor stable release series: 0.2.4.28, 0.2.5.13, 0.2.6.11, 0.2.7.7, 0.2.8.13

Hi! We've just tagged and uploaded new versions for the older 0.2.4 through 0.2.8 release series, to backport important patches and extend the useful life of these versions.

If you have the option, we'd recommend that you run the latest stable release instead of these. They are mainly of interest to distribution maintainers who for whatever reason want to track older release series of Tor.

You can, as usual, find the source at https://dist.torproject.org/. For a list of the backported changes in each release, see one of the nice handcrafted links below:

Please note that these releases are larger than we expect most future old-stable releases to be, because until recently we didn't have an actual policy of which releases should receive backports and support. You can learn more about our plans for "regular" and "long-term support" releases of Tor on the wiki.

Tor 0.3.0.4-rc is released

Tor 0.3.0.4-rc fixes some remaining bugs, large and small, in the 0.3.0 release series, and introduces a few reliability features to keep them from coming back.

This is the first release candidate in the Tor 0.3.0 series. If we find no new bugs or regressions here, the first stable 0.3.0 release will be nearly identical to it.

You can download the source code from the usual place on the website, but most users should wait for packages to become available over the upcoming weeks.

Please note: This is a release candidate, but not a stable release. Please expect more bugs than usual. If you want a stable experience, please stick to the stable releases.

Changes in version 0.3.0.4-rc - 2017-03-01

  • Major bugfixes (bridges):
    • When the same bridge is configured multiple times with the same identity, but at different address:port combinations, treat those bridge instances as separate guards. This fix restores the ability of clients to configure the same bridge with multiple pluggable transports. Fixes bug 21027; bugfix on 0.3.0.1-alpha.
  • Major bugfixes (hidden service directory v3):
    • Stop crashing on a failed v3 hidden service descriptor lookup failure. Fixes bug 21471; bugfixes on tor-0.3.0.1-alpha.

  read more »

Tor 0.2.9.10 is released

Tor 0.2.9.10 backports a security fix for users who build Tor with the --enable-expensive-hardening option. It also includes fixes for some major issues affecting directory authorities, LibreSSL compatibility, and IPv6 correctness.

The Tor 0.2.9.x release series is now marked as a long-term-support series. We intend to backport security fixes to 0.2.9.x until at least January of 2020.

You can download the source code from https://dist.torproject.org/ but most users should wait for next week's upcoming Tor Browser release, or for their upcoming system package updates.

Changes in version 0.2.9.10 - 2017-03-01

  • Major bugfixes (directory authority, 0.3.0.3-alpha):
    • During voting, when marking a relay as a probable sybil, do not clear its BadExit flag: sybils can still be bad in other ways too. (We still clear the other flags.) Fixes bug 21108; bugfix on 0.2.0.13-alpha.
  • Major bugfixes (IPv6 Exits, backport from 0.3.0.3-alpha):
    • Stop rejecting all IPv6 traffic on Exits whose exit policy rejects any IPv6 addresses. Instead, only reject a port over IPv6 if the exit policy rejects that port on more than an IPv6 /16 of addresses. This bug was made worse by 17027 in 0.2.8.1-alpha, which rejected a relay's own IPv6 address by default. Fixes bug 21357; bugfix on commit 004f3f4e53 in 0.2.4.7-alpha.

  read more »

Tor 0.3.0.3-alpha is released:

Tor 0.3.0.3-alpha fixes a few significant bugs introduced over the 0.3.0.x development series, including some that could cause authorities to behave badly. There is also a fix for a longstanding bug that could prevent IPv6 exits from working. Tor 0.3.0.3-alpha also includes some smaller features and bugfixes.

The Tor 0.3.0.x release series is now in patch-freeze: no additional features will be considered for inclusion in 0.3.0.x. We suspect that some bugs will probably remain, however, and we encourage people to test this release.

You can download the source code from the usual place on the website, but most users should wait for packages to become available over the upcoming weeks.

Please note: This is an alpha release. Please expect more bugs than usual. If you want a stable experience, please stick to the stable releases.

Below are the changes since 0.3.0.2-alpha:

Changes in version 0.3.0.3-alpha - 2017-02-03

  • Major bugfixes (directory authority):
    • During voting, when marking a relay as a probable sybil, do not clear its BadExit flag: sybils can still be bad in other ways too. (We still clear the other flags.) Fixes bug 21108; bugfix on 0.2.0.13-alpha.
    • When deciding whether we have just found a router to be reachable, do not penalize it for not having performed an Ed25519 link handshake if it does not claim to support an Ed25519 handshake. Previously, we would treat such relays as non-running. Fixes bug 21107; bugfix on 0.3.0.1-alpha.
  • Major bugfixes (entry guards):
    • Stop trying to build circuits through entry guards for which we have no descriptor. Also, stop crashing in the case that we *do* accidentally try to build a circuit in such a state. Fixes bug 21242; bugfix on 0.3.0.1-alpha.

  read more »

Tor 0.3.0.2-alpha is released

Tor 0.3.0.2-alpha fixes a denial-of-service bug where an attacker could cause relays and clients to crash, even if they were not built with the --enable-expensive-hardening option. This bug affects all 0.2.9.x versions, and also affects 0.3.0.1-alpha: all relays running an affected version should upgrade.

Tor 0.3.0.2-alpha also improves how exit relays and clients handle DNS time-to-live values, makes directory authorities enforce the 1-to-1 mapping of relay RSA identity keys to ED25519 identity keys, fixes a client-side onion service reachability bug, does better at selecting the set of fallback directories, and more.

You can download the source code from https://dist.torproject.org/ but most users should wait for the upcoming 7.0a Tor Browser alpha release, or for their upcoming system package updates.

Changes in version 0.3.0.2-alpha - 2017-01-23

  • Major bugfixes (security, also in 0.2.9.9):
    • Downgrade the "-ftrapv" option from "always on" to "only on when --enable-expensive-hardening is provided." This hardening option, like others, can turn survivable bugs into crashes--and having it on by default made a (relatively harmless) integer overflow bug into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001); bugfix on 0.2.9.1-alpha.
  • Major features (security):
    • Change the algorithm used to decide DNS TTLs on client and server side, to better resist DNS-based correlation attacks like the DefecTor attack of Greschbach, Pulls, Roberts, Winter, and Feamster. Now relays only return one of two possible DNS TTL values, and clients are willing to believe DNS TTL values up to 3 hours long. Closes ticket 19769.

  read more »

Tor 0.2.9.9 is released

Tor 0.2.9.9 fixes a denial-of-service bug where an attacker could cause relays and clients to crash, even if they were not built with the --enable-expensive-hardening option. This bug affects all 0.2.9.x versions, and also affects 0.3.0.1-alpha: all relays running an affected version should upgrade.

This release also resolves a client-side onion service reachability bug, and resolves a pair of small portability issues.

You can download the source code from https://dist.torproject.org/ but most users should wait for the upcoming Tor Browser release, or for their upcoming system package updates.

Changes in version 0.2.9.9 - 2017-01-23

  • Major bugfixes (security):
    • Downgrade the "-ftrapv" option from "always on" to "only on when --enable-expensive-hardening is provided." This hardening option, like others, can turn survivable bugs into crashes -- and having it on by default made a (relatively harmless) integer overflow bug into a denial-of-service bug. Fixes bug 21278 (TROVE-2017-001); bugfix on 0.2.9.1-alpha.
  • Major bugfixes (client, onion service):
    • Fix a client-side onion service reachability bug, where multiple socks requests to an onion service (or a single slow request) could cause us to mistakenly mark some of the service's introduction points as failed, and we cache that failure so eventually we run out and can't reach the service. Also resolves a mysterious "Remote server sent bogus reason code 65021" log warning. The bug was introduced in ticket 17218, where we tried to remember the circuit end reason as a uint16_t, which mangled negative values. Partially fixes bug 21056 and fixes bug 20307; bugfix on 0.2.8.1-alpha.
  • Minor features (geoip):
    • Update geoip and geoip6 to the January 4 2017 Maxmind GeoLite2 Country database.
  • Minor bugfixes (portability):
    • Avoid crashing when Tor is built using headers that contain CLOCK_MONOTONIC_COARSE, but then tries to run on an older kernel without CLOCK_MONOTONIC_COARSE. Fixes bug 21035; bugfix on 0.2.9.1-alpha.
    • Fix Libevent detection on platforms without Libevent 1 headers installed. Fixes bug 21051; bugfix on 0.2.9.1-alpha.

Tor 0.3.0.1-alpha: A new alpha series begins

Now that Tor 0.2.9.8 is stable, it's time to release a new alpha series for testing and bug-hunting!

Tor 0.3.0.1-alpha is the first alpha release in the 0.3.0 development series. It strengthens Tor's link and circuit handshakes by identifying relays by their Ed25519 keys, improves the algorithm that clients use to choose and maintain their list of guards, and includes additional backend support for the next-generation hidden service design. It also contains numerous other small features and improvements to security, correctness, and performance.

You can download the source from the usual place on the website. Packages should be available over the next weeks, including an alpha TorBrowser release some time in January.

Please note: This is an alpha release. Please expect more bugs than usual. If you want a stable experience, please stick to the stable releases.

Below are the changes since 0.2.9.8.

Changes in version 0.3.0.1-alpha - 2016-12-19

  • Major features (guard selection algorithm):
    • Tor's guard selection algorithm has been redesigned from the ground up, to better support unreliable networks and restrictive sets of entry nodes, and to better resist guard-capture attacks by hostile local networks. Implements proposal 271; closes ticket 19877.
  • Major features (next-generation hidden services):
    • Relays can now handle v3 ESTABLISH_INTRO cells as specified by prop224 aka "Next Generation Hidden Services". Service and clients don't use this functionality yet. Closes ticket 19043. Based on initial code by Alec Heifetz.
    • Relays now support the HSDir version 3 protocol, so that they can can store and serve v3 descriptors. This is part of the next- generation onion service work detailled in proposal 224. Closes ticket 17238.
  • Major features (protocol, ed25519 identity keys):
    • Relays now use Ed25519 to prove their Ed25519 identities and to one another, and to clients. This algorithm is faster and more secure than the RSA-based handshake we've been doing until now. Implements the second big part of proposal 220; Closes ticket 15055.
    • Clients now support including Ed25519 identity keys in the EXTEND2 cells they generate. By default, this is controlled by a consensus parameter, currently disabled. You can turn this feature on for testing by setting ExtendByEd25519ID in your configuration. This might make your traffic appear different than the traffic generated by other users, however. Implements part of ticket 15056; part of proposal 220.
    • Relays now understand requests to extend to other relays by their Ed25519 identity keys. When an Ed25519 identity key is included in an EXTEND2 cell, the relay will only extend the circuit if the other relay can prove ownership of that identity. Implements part of ticket 15056; part of proposal 220.

  read more »

Tor 0.2.9.8 is released: finally, a new stable series!

Tor 0.2.9.8 is the first stable release of the Tor 0.2.9 series.

The Tor 0.2.9 series makes mandatory a number of security features that were formerly optional. It includes support for a new shared- randomness protocol that will form the basis for next generation hidden services, includes a single-hop hidden service mode for optimizing .onion services that don't actually want to be hidden, tries harder not to overload the directory authorities with excessive downloads, and supports a better protocol versioning scheme for improved compatibility with other implementations of the Tor protocol.

And of course, there are numerous other bugfixes and improvements.

This release also includes a fix for a medium-severity issue (bug 21018 below) where Tor clients could crash when attempting to visit a hostile hidden service. Clients are recommended to upgrade as packages become available for their systems.

You can download the source code from the usual place on the website. Packages should be up within the next few days, with a
TorBrowser release planned for early January.

Below are listed the changes since Tor 0.2.8.11. For a list of changes since 0.2.9.7-rc, see the ChangeLog file.

Changes in version 0.2.9.8 - 2016-12-19

  • New system requirements:
    • When building with OpenSSL, Tor now requires version 1.0.1 or later. OpenSSL 1.0.0 and earlier are no longer supported by the OpenSSL team, and should not be used. Closes ticket 20303.
    • Tor now requires Libevent version 2.0.10-stable or later. Older versions of Libevent have less efficient backends for several platforms, and lack the DNS code that we use for our server-side DNS support. This implements ticket 19554.
    • Tor now requires zlib version 1.2 or later, for security, efficiency, and (eventually) gzip support. (Back when we started, zlib 1.1 and zlib 1.0 were still found in the wild. 1.2 was released in 2003. We recommend the latest version.)
  • Deprecated features:
    • A number of DNS-cache-related sub-options for client ports are now deprecated for security reasons, and may be removed in a future version of Tor. (We believe that client-side DNS caching is a bad idea for anonymity, and you should not turn it on.) The options are: CacheDNS, CacheIPv4DNS, CacheIPv6DNS, UseDNSCache, UseIPv4Cache, and UseIPv6Cache.
    • A number of options are deprecated for security reasons, and may be removed in a future version of Tor. The options are: AllowDotExit, AllowInvalidNodes, AllowSingleHopCircuits, AllowSingleHopExits, ClientDNSRejectInternalAddresses, CloseHSClientCircuitsImmediatelyOnTimeout, CloseHSServiceRendCircuitsImmediatelyOnTimeout, ExcludeSingleHopRelays, FastFirstHopPK, TLSECGroup, UseNTorHandshake, and WarnUnsafeSocks.
    • The *ListenAddress options are now deprecated as unnecessary: the corresponding *Port options should be used instead. These options may someday be removed. The affected options are: ControlListenAddress, DNSListenAddress, DirListenAddress, NATDListenAddress, ORListenAddress, SocksListenAddress, and TransListenAddress.

  read more »

Syndicate content Syndicate content