New Release: Tor 0.4.0.4-rc

by nickm | April 11, 2019

There's a new release candidate available for download. If you build Tor from source, you can download the source code for 0.4.0.4-rc from dist.torproject.org (pgp signature). Packages should be available over the coming weeks, with a new alpha Tor Browser release by early next week.

Remember, this isn't the stable release yet. You should only run this if you'd like to find and report more bugs than usual.

Tor 0.4.0.4-rc is the first release candidate in its series; it fixes several bugs from earlier versions, including some that had affected stability, and one that prevented relays from working with NSS.

Changes in version 0.4.0.4-rc - 2019-04-11

  • Major bugfixes (NSS, relay):
    • When running with NSS, disable TLS 1.2 ciphersuites that use SHA384 for their PRF. Due to an NSS bug, the TLS key exporters for these ciphersuites don't work -- which caused relays to fail to handshake with one another when these ciphersuites were enabled. Fixes bug 29241; bugfix on 0.3.5.1-alpha.
  • Minor features (bandwidth authority):
    • Make bandwidth authorities ignore relays that are reported in the bandwidth file with the flag "vote=0". This change allows us to report unmeasured relays for diagnostic reasons without including their bandwidth in the bandwidth authorities' vote. Closes ticket 29806.
    • When a directory authority is using a bandwidth file to obtain the bandwidth values that will be included in the next vote, serve this bandwidth file at /tor/status-vote/next/bandwidth. Closes ticket 21377.

 

  • Minor features (circuit padding):
    • Stop warning about undefined behavior in the probability distribution tests. Float division by zero may technically be undefined behavior in C, but it's well defined in IEEE 754. Partial backport of 29298. Closes ticket 29527; bugfix on 0.4.0.1-alpha.
  • Minor features (continuous integration):
    • On Travis Rust builds, cleanup Rust registry and refrain from caching the "target/" directory to speed up builds. Resolves issue 29962.
  • Minor features (dormant mode):
    • Add a DormantCanceledByStartup option to tell Tor that it should treat a startup event as cancelling any previous dormant state. Integrators should use this option with caution: it should only be used if Tor is being started because of something that the user did, and not if Tor is being automatically started in the background. Closes ticket 29357.
  • Minor features (geoip):
    • Update geoip and geoip6 to the April 2 2019 Maxmind GeoLite2 Country database. Closes ticket 29992.
  • Minor features (NSS, diagnostic):
    • Try to log an error from NSS (if there is any) and a more useful description of our situation if we are using NSS and a call to SSL_ExportKeyingMaterial() fails. Diagnostic for ticket 29241.
  • Minor bugfixes (security):
    • Fix a potential double free bug when reading huge bandwidth files. The issue is not exploitable in the current Tor network because the vulnerable code is only reached when directory authorities read bandwidth files, but bandwidth files come from a trusted source (usually the authorities themselves). Furthermore, the issue is only exploitable in rare (non-POSIX) 32-bit architectures, which are not used by any of the current authorities. Fixes bug 30040; bugfix on 0.3.5.1-alpha. Bug found and fixed by Tobias Stoeckmann.
    • Verify in more places that we are not about to create a buffer with more than INT_MAX bytes, to avoid possible OOB access in the event of bugs. Fixes bug 30041; bugfix on 0.2.0.16. Found and fixed by Tobias Stoeckmann.
  • Minor bugfix (continuous integration):
    • Reset coverage state on disk after Travis CI has finished. This should prevent future coverage merge errors from causing the test suite for the "process" subsystem to fail. The process subsystem was introduced in 0.4.0.1-alpha. Fixes bug 29036; bugfix on 0.2.9.15.
    • Terminate test-stem if it takes more than 9.5 minutes to run. (Travis terminates the job after 10 minutes of no output.) Diagnostic for 29437. Fixes bug 30011; bugfix on 0.3.5.4-alpha.
  • Minor bugfixes (bootstrap reporting):
    • During bootstrap reporting, correctly distinguish pluggable transports from plain proxies. Fixes bug 28925; bugfix on 0.4.0.1-alpha.
  • Minor bugfixes (C correctness):
    • Fix an unlikely memory leak in consensus_diff_apply(). Fixes bug 29824; bugfix on 0.3.1.1-alpha. This is Coverity warning CID 1444119.
  • Minor bugfixes (circuitpadding testing):
    • Minor tweaks to avoid rare test failures related to timers and monotonic time. Fixes bug 29500; bugfix on 0.4.0.1-alpha.
  • Minor bugfixes (directory authorities):
    • Actually include the bandwidth-file-digest line in directory authority votes. Fixes bug 29959; bugfix on 0.4.0.2-alpha.
  • Minor bugfixes (logging):
    • On Windows, when errors cause us to reload a consensus from disk, tell the user that we are retrying at log level "notice". Previously we only logged this information at "info", which was confusing because the errors themselves were logged at "warning". Improves previous fix for 28614. Fixes bug 30004; bugfix on 0.4.0.2-alpha.
  • Minor bugfixes (pluggable transports):
    • Restore old behavior when it comes to discovering the path of a given Pluggable Transport executable file. A change in 0.4.0.1-alpha had broken this behavior on paths containing a space. Fixes bug 29874; bugfix on 0.4.0.1-alpha.
  • Minor bugfixes (testing):
    • Backport the 0.3.4 src/test/test-network.sh to 0.2.9. We need a recent test-network.sh to use new chutney features in CI. Fixes bug 29703; bugfix on 0.2.9.1-alpha.
    • Fix a test failure on Windows caused by an unexpected "BUG" warning in our tests for tor_gmtime_r(-1). Fixes bug 29922; bugfix on 0.2.9.3-alpha.
  • Minor bugfixes (TLS protocol):
    • When classifying a client's selection of TLS ciphers, if the client ciphers are not yet available, do not cache the result. Previously, we had cached the unavailability of the cipher list and never looked again, which in turn led us to assume that the client only supported the ancient V1 link protocol. This, in turn, was causing Stem integration tests to stall in some cases. Fixes bug 30021; bugfix on 0.2.4.8-alpha.
  • Code simplification and refactoring:
    • Introduce a connection_dir_buf_add() helper function that detects whether compression is in use, and adds a string accordingly. Resolves issue 28816.
    • Refactor handle_get_next_bandwidth() to use connection_dir_buf_add(). Implements ticket 29897.
  • Documentation:
    • Clarify that Tor performs stream isolation among *Port listeners by default. Resolves issue 29121.

Comments

Please note that the comment area below has been archived.

Matt (not verified) said:

April 12, 2019

Permalink

I used to have no issues accessing the Settings Page of DuckDuckGo, back when Tor had the Javascript button addon. But sometimes in the past few months, an update has stopped me from being able to access that settings page anymore. How do I fix this? It works on all my other browsers.

Do you have this problem in a clean, new Tor Browser? Which "Javascript button addon" do you mean? Where can I find the DuckDuckGo settings page?

FWIW: This is a blog post about Tor not Tor Browser and chances are better for some browser person noticing this issue if you at least put it into a Tor Browser related blog post. You could try to contact our support channels as well: https://2019.www.torproject.org/about/contact.html.en#support.

Anonymous (not verified) said:

April 13, 2019

Permalink

Are you going to add a way to bypass parental control "pause" features that allow you to connect to the network, but not access the internet? You can go to 192.168.1.1 to request your internet to be unpaused. This system appears to use a firewall. Is it possible to bypass it?

The router that I suffer from blocks unknown devices because I used to spoof my MAC address. I have since started using the MAC addresses of other devices on the network. Maybe Tor could have a way to scan for those and automatically pick one. I have been using arp-scan and nmap for this purpose. I use Ubuntu 18.04, in case you want/need to know.

I think that is outside the scope of what tor tries to do, and the tools you have been using are already much better for the purpose. Posing as an existing MAC address on a LAN will cause interference between those two devices and might cause unforeseen problems. Rather than LAN and MAC configuration, the most that networked client programs try for your purpose is to disguise their traffic as normal web traffic on ports 80 or 443. As you learned, clients are not always in control of LAN administration. Moreover, wifi routers have another option called wireless isolation that prevents client devices from scanning other wifi devices on the SSID except for the router.

cmon (not verified) said:

April 15, 2019

Permalink

Thank you for your project but since today I cannot use the program. I have download the las version of comodo internet security and the cloud antivirus, and the version of tor browser but I cannot use your program. Could you please check it?

Cmon

Please comment to a post about Tor Browser or contact Tor Project's support channels. This blog post is about the tor binary/exe as distributed in the expert bundle, not the browser bundle.

Read the support site FAQ for Tor Browser and Connecting To Tor. "Cannot use" is too vague to solve. Be descriptive. Are there error messages from Tor Browser or from your security programs? What is your platform/OS? Which version of Tor Browser? Alpha version or not? Did you modify bridges, proxy, or port options before connecting? Did you modify Tor Browser after connecting?