New Release: Tor 0.3.5.5-alpha
There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.3.5.5-alpha from the download page on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release by late next week.
Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.
Tor 0.3.5.5-alpha includes numerous bugfixes on earlier releases, including several that we hope to backport to older release series in the future.
Changes in version 0.3.5.5-alpha - 2018-11-16
- Major bugfixes (OpenSSL, portability):
- Fix our usage of named groups when running as a TLS 1.3 client in OpenSSL 1.1.1. Previously, we only initialized EC groups when running as a relay, which caused clients to fail to negotiate TLS 1.3 with relays. Fixes bug 28245; bugfix on 0.2.9.15 (when TLS 1.3 support was added).
- Minor features (geoip):
- Update geoip and geoip6 to the November 6 2018 Maxmind GeoLite2 Country database. Closes ticket 28395.
- Minor bugfixes (compilation):
- Initialize a variable unconditionally in aes_new_cipher(), since some compilers cannot tell that we always initialize it before use. Fixes bug 28413; bugfix on 0.2.9.3-alpha.
- Minor bugfixes (connection, relay):
- Avoid a logging a BUG() stacktrace when closing connection held open because the write side is rate limited but not the read side. Now, the connection read side is simply shut down until Tor is able to flush the connection and close it. Fixes bug 27750; bugfix on 0.3.4.1-alpha.
- Minor bugfixes (continuous integration, Windows):
- Manually configure the zstd compiler options, when building using mingw on Appveyor Windows CI. The MSYS2 mingw zstd package does not come with a pkg-config file. Fixes bug 28454; bugfix on 0.3.4.1-alpha.
- Stop using an external OpenSSL install, and stop installing MSYS2 packages, when building using mingw on Appveyor Windows CI. Fixes bug 28399; bugfix on 0.3.4.1-alpha.
- Minor bugfixes (documentation):
- Make Doxygen work again after the code movement in the 0.3.5 source tree. Fixes bug 28435; bugfix on 0.3.5.1-alpha.
- Minor bugfixes (Linux seccomp2 sandbox):
- Permit the "shutdown()" system call, which is apparently used by OpenSSL under some circumstances. Fixes bug 28183; bugfix on 0.2.5.1-alpha.
- Minor bugfixes (logging):
- Stop talking about the Named flag in log messages. Clients have ignored the Named flag since 0.3.2. Fixes bug 28441; bugfix on 0.3.2.1-alpha.
- Minor bugfixes (memory leaks):
- Fix a harmless memory leak in libtorrunner.a. Fixes bug 28419; bugfix on 0.3.3.1-alpha. Patch from Martin Kepplinger.
- Minor bugfixes (onion services):
- On an intro point for a version 3 onion service, stop closing introduction circuits on an NACK. This lets the client decide whether to reuse the circuit or discard it. Previously, we closed intro circuits when sending NACKs. Fixes bug 27841; bugfix on 0.3.2.1-alpha. Patch by Neel Chaunan.
- When replacing a descriptor in the client cache, make sure to close all client introduction circuits for the old descriptor, so we don't end up with unusable leftover circuits. Fixes bug 27471; bugfix on 0.3.2.1-alpha.
Please note that the comment area below has been archived.
Should we ask Tor Browser…
Should we ask Tor Browser Team to switch to TLS 1.3 client with OpenSSL 1.1.1?
They'll get there eventually…
They'll get there eventually. For now, I think it's a better idea to go slowly and give more people time to find bugs.
Then why do you allow Tor…
Then why do you allow Tor clients to connect with TLS 1.3 by default? Isn't it weird to have two types of clients/traffic in the Tor network?
Also, as it is a security upgrade, shouldn't you prioritize this work and recommend to switch to TLS 1.3 as OpenSSL team does?
Two types of travel relayed…
Two types of travel relayed across the network would be a fingerprinting risk. But TLS1.3 only affects the traffic between the client and the guard.
When it comes to upgrading, we need to balance prioritizing upgrades and prioritizing stability. New software tends to have more bugs than older versions. For instance, here's a bug in OpenSSL 1.1.1a that breaks our handshakes: https://trac.torproject.org/projects/tor/ticket/28616
(#1) Error Killing GPU…
(#1) Error Killing GPU process due to IPC reply timeout
(#2) Error Failed to connect GPU process
(#3) Error Receive IPC close with reason=AbnormalShutdown
This sounds more like a…
This sounds more like a Torbrowser issue than a Tor issue -- Tor doesn't mess with the GPU.
could tor consider add a f2f…
could tor consider add a f2f layer with obfs bridges? not like now, but add a opition for the user in the region can connect to tor network directly being a bridge, and broadcast it via DHT not a server. you know that china can block all bridge ip, they are in the central server, but if the ip is anyone's home ip, they can't block the dymanic ips. and just be a entry for the network, they will not be in a legal risk.
This is not related to this…
This is not related to this release, but I fear that nobody would notice me in the older topics before the next TB release.
DuckDuckGo.com often blocks random exit nodes. It's really annoying sometimes. I suggest that Tor Browser moves to the official DuckDuckGo hidden service: http://3g2upl4pq6kufc4m.onion (address can be verified by searching "duckduckgo onion" on ddg.gg)
If that's a DuckDuckGo issue…
If that's a DuckDuckGo issue, please contact them so they can fix that. We don't have plans to use the onion services by default right now but it's an options for you to switch to.