New Alpha Release: Tor 0.4.7.1-alpha
There's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.4.7.1-alpha from the download page on the website. Packages should be available over the coming weeks, with a new alpha Tor Browser release likely some time 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.
This version is the first alpha release of the 0.4.7.x series. One major feature is Vanguards Lite, from proposal 333, to help mitigate guard discovery attacks against onion services. It also includes numerous bugfixes.
Changes in version 0.4.7.1-alpha - 2021-09-17
- Major features (Proposal 332, onion services, guard selection algorithm):
- Clients and onion services now choose four long-lived "layer 2" guard relays for use as the middle hop in all onion circuits. These relays are kept in place for a randomized duration averaging 1 week. This mitigates guard discovery attacks against clients and short-lived onion services such as OnionShare. Long-lived onion services that need high security should still use the Vanguards addon (https://github.com/mikeperry-tor/vanguards). Closes ticket 40363; implements proposal 333.
- Minor features (bridge testing support):
- Let external bridge reachability testing tools discard cached bridge descriptors when setting new bridges, so they can be sure to get a clean reachability test. Implements ticket 40209.
- Minor features (fuzzing):
- When building with --enable-libfuzzer, use a set of compiler flags that works with more recent versions of the library. Previously we were using a set of flags from 2017. Closes ticket 40407.
- Minor features (testing configuration):
- When TestingTorNetwork is enabled, skip the permissions check on hidden service directories. Closes ticket 40338.
- On a testing network, relays can now use the TestingMinTimeToReportBandwidth option to change the smallest amount of time over which they're willing to report their observed maximum bandwidth. Previously, this was fixed at 1 day. For safety, values under 2 hours are only supported on testing networks. Part of a fix for ticket 40337.
- Relays on testing networks no longer rate-limit how frequently they are willing to report new bandwidth measurements. Part of a fix for ticket 40337.
- Relays on testing networks now report their observed bandwidths immediately from startup. Previously, they waited until they had been running for a full day. Closes ticket 40337.
- Minor bugfixes (circuit padding):
- Don't send STOP circuit padding cells when the other side has already shut down the corresponding padding machine. Fixes bug 40435; bugfix on 0.4.0.1-alpha.
- Minor bugfixes (compatibility):
- Fix compatibility with the most recent Libevent versions, which no longer have an evdns_set_random_bytes() function. Because this function has been a no-op since Libevent 2.0.4-alpha, it is safe for us to just stop calling it. Fixes bug 40371; bugfix on 0.2.1.7-alpha.
- Minor bugfixes (control, sandbox):
- Allows the control command SAVECONF to succeed when the seccomp sandbox is enabled. Makes SAVECONF keep only one backup file, to simplify implementation. Fixes bug 40317; bugfix on 0.2.5.4-alpha. Patch by Daniel Pinto.
- Minor bugfixes (heartbeat):
- Adjust the heartbeat log message about distinct clients to consider the HeartbeatPeriod rather than a flat 6-hour delay. Fixes bug 40330; bugfix on 0.2.6.3-alpha.
- Minor bugfixes (logging, relay):
- Add spaces between the "and" when logging the "Your server has not managed to confirm reachability for its" on dual-stack relays. Fixes bug 40453; bugfix on 0.4.5.1-alpha. Patch by Neel Chauhan.
- Minor bugfixes (onion service):
- Do not flag an HSDir as non-running in case the descriptor upload or fetch fails. An onion service closes pending directory connections before uploading a new descriptor which leads to wrongly flagging many relays and thus affecting circuit path selection. Fixes bug 40434; bugfix on 0.2.0.13-alpha.
- Minor bugfixes (statistics):
- Fix a fencepost issue when we check stability_last_downrated where we called rep_hist_downrate_old_runs() twice. Fixes bug 40394; bugfix on 0.2.0.5-alpha. Patch by Neel Chauhan.
- Minor bugfixes (tests):
- Fix a bug that prevented some tests from running with the correct names. Fixes bug 40365; bugfix on 0.4.3.1-alpha.
- Documentation:
Comments
Please note that the comment area below has been archived.
For readers, more…
For readers, more information about the Vanguards add-on is on the Operational Security (OpSec) page of the onion service advanced settings guide:
https://sgapqzbrdr.oedi.net/onion-services/advanced/opsec/
Please look into this tested…
Please look into this tested and proven method of quantum proofing Tor. Quantum computers are less than 10 years away. All data passing now can be decrypted at some point in the near future.
https://essay.utwente.nl/79710/
Clients and onion services…
Why not extend this to all circuits (not just onion circuits)?
So how does that prevent…
So how does that prevent decryption?
I got an IPv6-only relay…
I got an IPv6-only relay configured and sitting here waiting to start accepting traffic one of these days...
> IPv6-only Tor relays…
> IPv6-only
Tor relays require IPv4 at minimum for the time being.
https://sgapqzbrdr.oedi.net/relay/relays-requirements/
https://sgapqzbrdr.oedi.net/relay/setup/post-install/
https://sgapqzbrdr.oedi.net/relay/getting-help/
https://jqlsbiwihs.oedi.net/relay-operators/ipv6-relay/
https://jqlsbiwihs.oedi.net/relay-operators/why-isnt-my-relay-being-…
Can you link to proposal 333…
Can you link to proposal 333 please?
Here are all the proposals:…
Here are all the proposals: https://gitweb.torproject.org/torspec.git/tree/proposals/
In ticket 40363 for…
In ticket 40363 for vanguards lite, Mike Perry wrote, "It's not impossible that a user might have a malicious tab open that entire time. If we look at https://gitweb.torproject.org/torspec.git/tree/proposals/247-hs-guard-d…, then 30 rotations is still 60% success even for a 1% adversary, with a 24 hour rotation period, and 99% success for a 5% adversary... We should raise this to a longer average. 1 week would make it 10% success probability for 1% adversary, and 50% for 5%. And/or we could use 3 L2 guards."
If the probability exceeds a threshold, should Tor Browser warn the user and tell them to close the tab or start a new identity? Although, this is for little-t tor, so it isn't exclusive to browser tabs. It couldn't communicate a warning to applications about anything.
>Major features (Proposal…
>Major features (Proposal 332, onion services, guard selection algorithm):
>[....]
>Closes ticket 40363; implements proposal 333.
Looks like a typo.