[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Tor 0.2.4.8-alpha is out



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@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
> 


-- 
Micah Lee
https://twitter.com/micahflee

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk