New Tor alpha release: 0.3.3.3-alpha
Hi! In addition to today's stable releases, there's a new alpha release available for download. If you build Tor from source, you can download the source code for 0.3.3.3-alpha from the usual place on the website. Packages for relays should be available over the coming days.
Remember, this is an alpha release: you should only run this if you'd like to find and report more bugs than usual.
See the other announcement for more information about today's security issues.
Tor 0.3.3.3-alpha is the third alpha release for the 0.3.3.x series. It includes an important security fix for a remote crash attack against directory authorities tracked as TROVE-2018-001.
Additionally, with this release, we are upgrading the severity of a bug fixed in 0.3.3.2-alpha. Bug 24700, which was fixed in 0.3.3.2-alpha, can be remotely triggered in order to crash relays with a use-after-free pattern. As such, we are now tracking that bug as TROVE-2018-002 and CVE-2018-0491. This bug affected versions 0.3.2.1-alpha through 0.3.2.9, as well as 0.3.3.1-alpha.
This release also fixes several minor bugs and annoyances from earlier releases.
Relays running 0.3.2.x should upgrade to one of the versions released today, for the fix to TROVE-2018-002. Directory authorities should also upgrade. (Relays on earlier versions might want to update too for the DoS mitigations.)
Changes in version 0.3.3.3-alpha - 2018-03-03
- Major bugfixes (denial-of-service, directory authority):
- Fix a protocol-list handling bug that could be used to remotely crash directory authorities with a null-pointer exception. Fixes bug 25074; bugfix on 0.2.9.4-alpha. Also tracked as TROVE-2018-001 and CVE-2018-0490.
- Minor features (compatibility, OpenSSL):
- Tor will now support TLS1.3 once OpenSSL 1.1.1 is released. Previous versions of Tor would not have worked with OpenSSL 1.1.1, since they neither disabled TLS 1.3 nor enabled any of the ciphersuites it requires. Now we enable the TLS 1.3 ciphersuites. Closes ticket 24978.
- Minor features (logging):
- Clarify the log messages produced when getrandom() or a related entropy-generation mechanism gives an error. Closes ticket 25120.
- Minor features (testing):
- Add a "make test-rust" target to run the rust tests only. Closes ticket 25071.
- Minor bugfixes (denial-of-service):
- Fix a possible crash on malformed consensus. If a consensus had contained an unparseable protocol line, it could have made clients and relays crash with a null-pointer exception. To exploit this issue, however, an attacker would need to be able to subvert the directory authority system. Fixes bug 25251; bugfix on 0.2.9.4-alpha. Also tracked as TROVE-2018-004.
- Minor bugfixes (DoS mitigation):
- Add extra safety checks when refilling the circuit creation bucket to ensure we never set a value above the allowed maximum burst. Fixes bug 25202; bugfix on 0.3.3.2-alpha.
- When a new consensus arrives, don't update our DoS-mitigation parameters if we aren't a public relay. Fixes bug 25223; bugfix on 0.3.3.2-alpha.
- Minor bugfixes (man page, SocksPort):
- Remove dead code from the old "SocksSocket" option, and rename SocksSocketsGroupWritable to UnixSocksGroupWritable. The old option still works, but is deprecated. Fixes bug 24343; bugfix on 0.2.6.3.
- Minor bugfixes (performance):
- Reduce the number of circuits that will be opened at once during the circuit build timeout phase. This is done by increasing the idle timeout to 3 minutes, and lowering the maximum number of concurrent learning circuits to 10. Fixes bug 24769; bugfix on 0.3.1.1-alpha.
- Minor bugfixes (spec conformance):
- Minor bugfixes (spec conformance, rust):
- Resolve a denial-of-service issue caused by an infinite loop in the rust protover code. Fixes bug 25250, bugfix on 0.3.3.1-alpha. Also tracked as TROVE-2018-003.
- Code simplification and refactoring:
- Update the "rust dependencies" submodule to be a project-level repository, rather than a user repository. Closes ticket 25323.
Please note that the comment area below has been archived.
Quick Question, i read…
Quick Question, i read somewhere in past Blogposts, that users from countries that have already a high number of volunteers like france or germany should rather operate a bridge than a regular relay. Is that still the case? I cant find the article anymore.
Also, can i run a obfs bridge on a dynamic ip setup or is a static ip required to be a bridge operator?
Thanks for the good work.
Thanks for the good work.
Why is https://www…
Why is https://www.torproject.org/ working on TLS 1?