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.
Changes in version 0.2.3.9-alpha - 2011-12-08
- 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.
- 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.
Minor features (new/different config options):
- New configuration option "DisableDebuggerAttachment" (on by default)
to prevent basic debugging attachment attempts by other processes.
Supports Mac OS X and Gnu/Linux. Resolves ticket 3313.
- Allow MapAddress directives to specify matches against super-domains,
as in "MapAddress *.torproject.org *.torproject.org.torserver.exit".
Implements issue 933.
- Slightly change behavior of "list" options (that is, config
options that can appear more than once) when they appear both in
torrc and on the command line. Previously, the command-line options
would be appended to the ones from torrc. Now, the command-line
options override the torrc options entirely. This new behavior
allows the user to override list options (like exit policies and
ports to listen on) from the command line, rather than simply
appending to the list.
- You can get the old (appending) command-line behavior for "list"
options by prefixing the option name with a "+".
- You can remove all the values for a "list" option from the command
line without adding any new ones by prefixing the option name
with a "/".
- Add experimental support for a "defaults" torrc file to be parsed
before the regular torrc. Torrc options override the defaults file's
options in the same way that the command line overrides the torrc.
The SAVECONF controller command saves only those options which
differ between the current configuration and the defaults file. HUP
reloads both files. (Note: This is an experimental feature; its
behavior will probably be refined in future 0.2.3.x-alpha versions
to better meet packagers' needs.)
- Try to make the introductory warning message that Tor prints on
startup more useful for actually finding help and information.
Resolves ticket 2474.
- Running "make version" now displays the version of Tor that
we're about to build. Idea from katmagic; resolves issue 4400.
- Expire old or over-used hidden service introduction points.
Required by fix for bug 3460.
- Move the replay-detection cache for the RSA-encrypted parts of
INTRODUCE2 cells to the introduction point data structures.
Previously, we would use one replay-detection cache per hidden
service. Required by fix for bug 3460.
- Reduce the lifetime of elements of hidden services' Diffie-Hellman
public key replay-detection cache from 60 minutes to 5 minutes. This
replay-detection cache is now used only to detect multiple
INTRODUCE2 cells specifying the same rendezvous point, so we can
avoid launching multiple simultaneous attempts to connect to it.
Minor bugfixes (on Tor 0.2.2.x and earlier):
- Resolve an integer overflow bug in smartlist_ensure_capacity().
Fixes bug 4230; bugfix on Tor 0.1.0.1-rc. Based on a patch by
- Fix a minor formatting issue in one of tor-gencert's error messages.
Fixes bug 4574.
- Prevent a false positive from the check-spaces script, by disabling
the "whitespace between function name and (" check for functions
- Fix a log message suggesting that people contact a non-existent
email address. Fixes bug 3448.
- Fix null-pointer access that could occur if TLS allocation failed.
Fixes bug 4531; bugfix on 0.2.0.20-rc. Found by "troll_un".
- Report a real bootstrap problem to the controller on router
identity mismatch. Previously we just said "foo", which probably
made a lot of sense at the time. Fixes bug 4169; bugfix on
- If we had ever tried to call tor_addr_to_str() on an address of
unknown type, we would have done a strdup() on an uninitialized
buffer. Now we won't. Fixes bug 4529; bugfix on 0.2.1.3-alpha.
Reported by "troll_un".
- Correctly detect and handle transient lookup failures from
tor_addr_lookup(). Fixes bug 4530; bugfix on 0.2.1.5-alpha.
Reported by "troll_un".
- Use tor_socket_t type for listener argument to accept(). Fixes bug
4535; bugfix on 0.2.2.28-beta. Found by "troll_un".
- Initialize conn->addr to a valid state in spawn_cpuworker(). Fixes
bug 4532; found by "troll_un".
Minor bugfixes (on Tor 0.2.3.x):
- Fix a compile warning in tor_inet_pton(). Bugfix on 0.2.3.8-alpha;
fixes bug 4554.
- Don't send two ESTABLISH_RENDEZVOUS cells when opening a new
circuit for use as a hidden service client's rendezvous point.
Fixes bugs 4641 and 4171; bugfix on 0.2.3.3-alpha. Diagnosed
with help from wanoskarnet.
- Restore behavior of overriding SocksPort, ORPort, and similar
options from the command line. Bugfix on 0.2.3.3-alpha.
- Properly handle the case where the build-tree is not the same
as the source tree when generating src/common/common_sha1.i,
src/or/micro-revision.i, and src/or/or_sha1.i. Fixes bug 3953;
bugfix on 0.2.0.1-alpha.
Code simplifications, cleanups, and refactorings:
- Remove the pure attribute from all functions that used it
previously. In many cases we assigned it incorrectly, because the
functions might assert or call impure functions, and we don't have
evidence that keeping the pure attribute is worthwhile. Implements
changes suggested in ticket 4421.
- Remove some dead code spotted by coverity. Fixes cid 432.
Bugfix on 0.2.3.1-alpha, closes bug 4637.
In February 2011, we enabled IPv6 access to the majority of our websites, such as www.torproject.org, trac.torproject.org, archive.torproject.org, media.torproject.org, gitweb.torproject.org, and check.torproject.org. We've seen a growing amount of ipv6 traffic going to www, gitweb, and archive since then.
However, this isn't what people think about, nor want to hear about, when thinking of Tor and IPv6. Nick posted our efforts on this front in late April. There is an opportunity for someone to make a big impact by helping us enable ipv6 in the tor codebase. We're keeping our thoughts in a draft proposal. We have more thoughts about supporting IPv6 exits written down in 2007.
If IPv6 is the future, protecting your privacy online should be part of that future. We're looking for help to make it happen.
A while ago, I wrote up a description of what needs to be done to get Tor to be IPv6-compliant and sent it to the tor-dev mailinglist. I thought it might be neat to share this on the blog too, so that people know what's left to do before we an call Tor fully IPv6-compliant.
Currently, I'm hoping that for 0.2.3.x we can at least get to the point where bridges can handle IPv6-only clients and exits can handle IPv6 addresses. If we get further, that will be even better.
This document outlines what we'll have to do to make Tor fully support IPv6. It refers to other proposals, current and as-yet unwritten. It suggests a few incremental steps, each of which on its own should make Tor more useful in the brave new IPv6 future of tomorrow.
Turns out, 4 billion addresses wasn't enough.
What needs to change
Tor uses the Internet in many ways. There are three main ways that will need to change for IPv6 support, from most urgent to least urgent.
- Tor must allow connections from IPv6-only clients. (Currently, routers and bridges do not listen on IPv6 addresses, and can't advertise that they support IPv6 addresses, so clients can't learn that they do.)
- Tor must transport IPv6 traffic and IPv6-related DNS traffic. (Currently, Tor only allows BEGIN cells to ask for connections to IPv4 targets or to hostnames, and only allows RESOLVE cells to request A and PTR records.)
- Tor must allow nodes to connect to one another over IPv6.
Allowing IPv6-only clients is the most important, since unless we do, these clients will be unable to connect to Tor at all. Next most important is to support IPv6 DNS related dependencies and exiting to IPv6 services. Finally, allowing Tor nodes to support a dual stack of both IPv4 and IPv6 for interconnection seems like a reasonable step towards a fully hybrid v4/v6 Tor network.
One implementation hurdle that will need to get resolved alongside these changes is to convert uint32_t to tor_addr_t in many more places in the Tor code, so we can handle addresses being either IPv4 or IPv6. There are a few cases, e.g. the local router list, where we'll want to think harder about the resource requirements of keeping tens of thousands of larger addresses in memory.
More issues may of course also be discovered as we develop solutions for these issues, some of which may need to take priority.
Designs that we will need to do
For IPv6-only clients, we'll need to specify that routers can have multiple addresses and ORPorts.
There is an old proposal (118) to try to allow multiple ORPorts per router. It's been accepted; it needs to be checked for correctness, updated to track other changes in more recent Tor versions, and updated to work with the new microdescriptor designs.
Additionally, we'll need to audit the designs for all our codebase for places that might assume that IPs are a scarce resource. For example, clients assume that any two routers occupying an IPv4 /16 network are "too close" topologically to be used in the same circuit, and the bridgedb HTTPS distributor assumes that hopping from one /24 to another takes a little effort for most clients. The directory authorities assume that blacklisting an IP is an okay response to a bad router at that address. These and other places will instead need more appropriate notions of "closeness" and "similarity".
We'll want to consider geographic and political boundaries rather than purely mathematical notions such as the size of network blocks.
We'll need a way to advertise IPv6 bridges, and to use them.
For transporting IPv6-only traffic, we have another accepted design proposal (117). It has some open questions concerning proper behavior with respect to DNS lookups, and also needs to be checked and updated to track current Tor designs.
We do not have a current accepted design proposal for allowing nodes to connect to each other via IPv6. Allowing opportunistic IPv6 traffic between nodes that can communicate with both IPv4 and IPv6 will be relatively simple, as will be bridges that have only an IPv6 address: both of these fall out relatively simply from designing a process for advertising and connecting to IPv6 addresses. The harder problem is in supporting IPv6-only Tor routers. For these, we'll need to consider network topology issues: having nodes that can't connect to all the other nodes will weaken one of our basic assumptions for path generation, so we'll need to make sure to do the analysis enough to tell whether this is safe.
Ready, fire, aim: An alternative methodology
At least one volunteer is currently working on IPv6 issues in Tor. If his efforts go well, it might be that our first design drafts for some of these open topics arrive concurrently with (or even in the form of!) alpha code to implement them. If so, we need to follow a variant of the design process, extracting design from code to evaluate it (rather than designing then coding). Probably, based on design review, some changes to code would be necessary.