[tor-talk] Tor 0.2.4.8-alpha is out
Micah Lee
micahflee at riseup.net
Wed Jan 16 00:28:34 UTC 2013
Are there plans to release the Tor Browser Bundle as a package in Tor's
official repos, e.g. http://deb.torproject.org/torproject.org/?
This would make keeping an up-to-date TBB much more convenient.
On 01/14/2013 08:37 PM, Roger Dingledine wrote:
> Tor 0.2.4.8-alpha introduces directory guards to reduce user enumeration
> risks, adds a new stronger and faster circuit handshake, and offers
> stronger and faster link encryption when both sides support it.
>
> https://www.torproject.org/download
>
> Changes in version 0.2.4.8-alpha - 2013-01-14
> o Major features:
> - Preliminary support for directory guards (proposal 207): when
> possible, clients now use their entry guards for non-anonymous
> directory requests. This can help prevent client enumeration. Note
> that this behavior only works when we have a usable consensus
> directory, and when options about what to download are more or less
> standard. In the future we should re-bootstrap from our guards,
> rather than re-bootstrapping from the preconfigured list of
> directory sources that ships with Tor. Resolves ticket 6526.
> - Tor relays and clients now support a better CREATE/EXTEND cell
> format, allowing the sender to specify multiple address, identity,
> and handshake types. Implements Robert Ransom's proposal 200;
> closes ticket 7199.
>
> o Major features (new circuit handshake):
> - Tor now supports a new circuit extension handshake designed by Ian
> Goldberg, Douglas Stebila, and Berkant Ustaoglu. Our original
> circuit extension handshake, later called "TAP", was a bit slow
> (especially on the relay side), had a fragile security proof, and
> used weaker keys than we'd now prefer. The new circuit handshake
> uses Dan Bernstein's "curve25519" elliptic-curve Diffie-Hellman
> function, making it significantly more secure than the older
> handshake, and significantly faster. Tor can use one of two built-in
> pure-C curve25519-donna implementations by Adam Langley, or it
> can link against the "nacl" library for a tuned version if present.
>
> The built-in version is very fast for 64-bit systems when building
> with GCC. The built-in 32-bit version is still faster than the
> old TAP protocol, but using libnacl is better on most such hosts.
>
> Clients don't currently use this protocol by default, since
> comparatively few clients support it so far. To try it, set
> UseNTorHandshake to 1.
>
> Implements proposal 216; closes ticket 7202.
>
> o Major features (better link encryption):
> - Relays can now enable the ECDHE TLS ciphersuites when available
> and appropriate. These ciphersuites let us negotiate forward-secure
> TLS secret keys more safely and more efficiently than with our
> previous use of Diffie-Hellman modulo a 1024-bit prime. By default,
> public relays prefer the (faster) P224 group, and bridges prefer
> the (more common) P256 group; you can override this with the
> TLSECGroup option.
>
> Enabling these ciphers was a little tricky, since for a long time,
> clients had been claiming to support them without actually doing
> so, in order to foil fingerprinting. But with the client-side
> implementation of proposal 198 in 0.2.3.17-beta, clients can now
> match the ciphers from recent Firefox versions *and* list the
> ciphers they actually mean, so relays can believe such clients
> when they advertise ECDHE support in their TLS ClientHello messages.
>
> This feature requires clients running 0.2.3.17-beta or later,
> and requires both sides to be running OpenSSL 1.0.0 or later
> with ECC support. OpenSSL 1.0.1, with the compile-time option
> "enable-ec_nistp_64_gcc_128", is highly recommended.
>
> Implements the relay side of proposal 198; closes ticket 7200.
>
> o Major bugfixes:
> - Avoid crashing when, as a relay without IPv6-exit support, a
> client insists on getting an IPv6 address or nothing. Fixes bug
> 7814; bugfix on 0.2.4.7-alpha.
>
> o Minor features:
> - Improve circuit build timeout handling for hidden services.
> In particular: adjust build timeouts more accurately depending
> upon the number of hop-RTTs that a particular circuit type
> undergoes. Additionally, launch intro circuits in parallel
> if they timeout, and take the first one to reply as valid.
> - Work correctly on Unix systems where EAGAIN and EWOULDBLOCK are
> separate error codes; or at least, don't break for that reason.
> Fixes bug 7935. Reported by "oftc_must_be_destroyed".
> - Update to the January 2 2013 Maxmind GeoLite Country database.
>
> o Minor features (testing):
> - Add benchmarks for DH (1024-bit multiplicative group) and ECDH
> (P-256) Diffie-Hellman handshakes to src/or/bench.
> - Add benchmark functions to test onion handshake performance.
>
> o Minor features (path bias detection):
> - Alter the Path Bias log messages to be more descriptive in terms
> of reporting timeouts and other statistics.
> - Create three levels of Path Bias log messages, as opposed to just
> two. These are configurable via consensus as well as via the torrc
> options PathBiasNoticeRate, PathBiasWarnRate, PathBiasExtremeRate.
> The default values are 0.70, 0.50, and 0.30 respectively.
> - Separate the log message levels from the decision to drop guards,
> which also is available via torrc option PathBiasDropGuards.
> PathBiasDropGuards still defaults to 0 (off).
> - Deprecate PathBiasDisableRate in favor of PathBiasDropGuards
> in combination with PathBiasExtremeRate.
> - Increase the default values for PathBiasScaleThreshold and
> PathBiasCircThreshold from (200, 20) to (300, 150).
> - Add in circuit usage accounting to path bias. If we try to use a
> built circuit but fail for any reason, it counts as path bias.
> Certain classes of circuits where the adversary gets to pick your
> destination node are exempt from this accounting. Usage accounting
> can be specifically disabled via consensus parameter or torrc.
> - Convert all internal path bias state to double-precision floating
> point, to avoid roundoff error and other issues.
> - Only record path bias information for circuits that have completed
> *two* hops. Assuming end-to-end tagging is the attack vector, this
> makes us more resilient to ambient circuit failure without any
> detection capability loss.
>
> o Minor bugfixes (log messages):
> - Rate-limit the "No circuits are opened. Relaxed timeout for a
> circuit with channel state open..." message to once per hour to
> keep it from filling the notice logs. Mitigates bug 7799 but does
> not fix the underlying cause. Bugfix on 0.2.4.7-alpha.
> - Avoid spurious warnings when configuring multiple client ports of
> which only some are nonlocal. Previously, we had claimed that some
> were nonlocal when in fact they weren't. Fixes bug 7836; bugfix on
> 0.2.3.3-alpha.
>
> o Code simplifications and refactoring:
> - Get rid of a couple of harmless clang warnings, where we compared
> enums to ints. These warnings are newly introduced in clang 3.2.
> - Split the onion.c file into separate modules for the onion queue
> and the different handshakes it supports.
> - Remove the marshalling/unmarshalling code for sending requests to
> cpuworkers over a socket, and instead just send structs. The
> recipient will always be the same Tor binary as the sender, so
> any encoding is overkill.
>
>
>
> _______________________________________________
> tor-talk mailing list
> tor-talk at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
--
Micah Lee
https://twitter.com/micahflee
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 901 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20130115/001ca4a5/attachment-0001.pgp>
More information about the tor-talk
mailing list