Tor 0.2.3.9-alpha introduces initial IPv6 support for bridges, adds a "DisableNetwork" security feature that bundles can use to avoid touching the network until bridges are configured, moves forward on the pluggable transport design, fixes a flaw in the hidden service design that unnecessarily prevented clients with wrong clocks from reaching hidden services, and fixes a wide variety of other issues.
- Clients can now connect to private bridges over IPv6. Bridges still need at least one IPv4 address in order to connect to other relays. Note that we don't yet handle the case where the user has two bridge lines for the same bridge (one IPv4, one IPv6). Implements parts of proposal 186.
- New "DisableNetwork" config option to prevent Tor from launching any connections or accepting any connections except on a control port.
- Bundles and controllers can set this option before letting Tor talk to the rest of the network, for example to prevent any connections to a non-bridge address. Packages like Orbot can also use this option to instruct Tor to save power when the network is off.
- Clients and bridges can now be configured to use a separate "transport" proxy. This approach makes the censorship arms race easier by allowing bridges to use protocol obfuscation plugins. It implements the "managed proxy" part of proposal 180 (ticket 3472).
- When using OpenSSL 1.0.0 or later, use OpenSSL's counter mode implementation. It makes AES_CTR about 7% faster than our old one (which was about 10% faster than the one OpenSSL used to provide). Resolves ticket 4526.
- Add a "tor2web mode" for clients that want to connect to hidden services non-anonymously (and possibly more quickly). As a safety measure to try to keep users from turning this on without knowing what they are doing, tor2web mode must be explicitly enabled at compile time, and a copy of Tor compiled to run in tor2web mode cannot be used as a normal Tor client. Implements feature 2553.
- Add experimental support for running on Windows with IOCP and no kernel-space socket buffers. This feature is controlled by a new "UserspaceIOCPBuffers" config option (off by default), which has no effect unless Tor has been built with support for bufferevents, is running on Windows, and has enabled IOCP. This may, in the long run, help solve or mitigate bug 98.
- Use a more secure consensus parameter voting algorithm. Now at least three directory authorities or a majority of them must vote on a given parameter before it will be included in the consensus. Implements proposal 178.
Major Bugfixes:-
- Hidden services now ignore the timestamps on INTRODUCE2 cells.
- They used to check that the timestamp was within 30 minutes of their system clock, so they could cap the size of their replay-detection cache, but that approach unnecessarily refused service to clients with wrong clocks. Bugfix on 0.2.1.6-alpha, when the v3 intro-point protocol (the first one which sent a timestamp field in the INTRODUCE2 cell) was introduced; fixes bug 3460.
- Only use the EVP interface when AES acceleration is enabled, to avoid a 5-7% performance regression. Resolves issue 4525; bugfix on 0.2.3.8-alpha.
Privacy/Anonymity Features (bridge detection):-
- Make bridge SSL certificates a bit more stealthy by using random serial numbers, in the same fashion as OpenSSL when generating self-signed certificates. Implements ticket 4584.
- Introduce a new config option "DynamicDHGroups", enabled by default, which provides each bridge with a unique prime DH modulus to be used during SSL handshakes. This option attempts to help against censors who might use the Apache DH modulus as a static identifier for bridges. Addresses ticket 4548.
To Download Tor 0.2.3.9-alpha Click Here
Posts
