Tor 0.2.0.2-alpha is out

[vikingserver at gmail.com]

Before anything else, I must say a BIG THANK YOU to the developers of TOR.
I have been running a server now for a year or so, with the purpose of
being an entry server for people behind restrictive firewalls. I choose
port 995 which is a port often used by SSL-email servers. I choose this
port because I didn't find any tor server back then that had a server on
the port 995. Many TOR-servers used ports 9030 or 9031 or other ports
usually blocked by restrictive company/organization/educational
firewalls. And some servers used port 80 or 443, both ports that are
often blocked by restrictive firewalls. Many companies instead have one
proxy that handles all 80/443 traffic, blocking traffic to ports 80 and
443, while they often allow direct connection to email ports 110 and 995.

Anyway, today I read this in the release notes:

>   o Security fixes:
>     - Directory authorities now call routers stable if they have an
>       uptime of at least 30 days, even if that's not the median uptime
>       in the network. Implements proposal 107, suggested by Kevin Bauer
>       and Damon McCoy.
>       is becoming increasingly decoupled from the number of sockets.
>
>   
I have questions about this that might interest others:
Is the requirement of "being stable" to have had the server running for
at least 30 days in a row without any downtime?
If so, this must mean that these servers update TOR very rarely and
might be a security threat. Because TOR is often updated with new bug
fixes and security updates, it's not possible to have an up to date
version of TOR and at the same time being a "stable TOR server". Updates
are released more often than every 30 days, right?
Stable TOR releases are sometimes released more rarely, but still a
server that recently updated to a new stable release will have an uptime
of less than 30 days, while a server running an older version of TOR
(stable TOR version or not), that hasn't been updated for a long time
will be marked as "a stable router" with this system.

My conclusion is that this "security fix" rather than improving
security, really tells TOR clients to try to connect to servers with
high uptime with old, less secure versions of TOR.
Shouldn't TOR clients instead try to favor servers with the latest
version of TOR?

/Viking admin


Roger Dingledine skrev:
> These are the first two development snapshots for the 0.2.0.x series.
>
> These releases provide new features for people running Tor as both a
> client and a server (check out the new RelayBandwidth config options); let
> Tor run as a DNS proxy; and generally move us forward on a lot of fronts.
>
> https://tor.eff.org/download.html
>
> Changes in version 0.2.0.2-alpha - 2007-06-02
>   o Major bugfixes on 0.2.0.1-alpha:
>     - Fix an assertion failure related to servers without extra-info digests.
>       Resolves bugs 441 and 442.
>
>   o Minor features (directory):
>     - Support "If-Modified-Since" when answering HTTP requests for
>       directories, running-routers documents, and network-status documents.
>       (There's no need to support it for router descriptors, since those
>       are downloaded by descriptor digest.)
>
>   o Minor build issues:
>     - Clear up some MIPSPro compiler warnings.
>     - When building from a tarball on a machine that happens to have SVK
>       installed, report the micro-revision as whatever version existed
>       in the tarball, not as "x".
>
>
> Changes in version 0.2.0.1-alpha - 2007-06-01
>   o Major features, server usability:
>     - New config options RelayBandwidthRate and RelayBandwidthBurst:
>       a separate set of token buckets for relayed traffic. Right now
>       relayed traffic is defined as answers to directory requests, and
>       OR connections that don't have any local circuits on them.
>
>   o Major features, client usability:
>     - A client-side DNS proxy feature to replace the need for
>       dns-proxy-tor: Just set "DNSPort 9999", and Tor will now listen
>       for DNS requests on port 9999, use the Tor network to resolve them
>       anonymously, and send the reply back like a regular DNS server.
>       The code still only implements a subset of DNS.
>     - Make PreferTunneledDirConns and TunnelDirConns work even when
>       we have no cached directory info. This means Tor clients can now
>       do all of their connections protected by TLS.
>
>   o Major features, performance and efficiency:
>     - Directory authorities accept and serve "extra info" documents for
>       routers. These documents contain fields from router descriptors
>       that aren't usually needed, and that use a lot of excess
>       bandwidth. Once these fields are removed from router descriptors,
>       the bandwidth savings should be about 60%. [Partially implements
>       proposal 104.]
>     - Servers upload extra-info documents to any authority that accepts
>       them. Authorities (and caches that have been configured to download
>       extra-info documents) download them as needed. [Partially implements
>       proposal 104.]
>     - Change the way that Tor buffers data that it is waiting to write.
>       Instead of queueing data cells in an enormous ring buffer for each
>       client->OR or OR->OR connection, we now queue cells on a separate
>       queue for each circuit.  This lets us use less slack memory, and
>       will eventually let us be smarter about prioritizing different kinds
>       of traffic.
>     - Use memory pools to allocate cells with better speed and memory
>       efficiency, especially on platforms where malloc() is inefficient.
>     - Stop reading on edge connections when their corresponding circuit
>       buffers are full; start again as the circuits empty out.
>
>   o Major features, other:
>     - Add an HSAuthorityRecordStats option that hidden service authorities
>       can use to track statistics of overall hidden service usage without
>       logging information that would be very useful to an attacker.
>     - Start work implementing multi-level keys for directory authorities:
>       Add a standalone tool to generate key certificates. (Proposal 103.)
>
>   o Security fixes:
>     - Directory authorities now call routers stable if they have an
>       uptime of at least 30 days, even if that's not the median uptime
>       in the network. Implements proposal 107, suggested by Kevin Bauer
>       and Damon McCoy.
>
>   o Minor fixes (resource management):
>     - Count the number of open sockets separately from the number
>       of active connection_t objects. This will let us avoid underusing
>       our allocated connection limit.
>     - We no longer use socket pairs to link an edge connection to an
>       anonymous directory connection or a DirPort test connection.
>       Instead, we track the link internally and transfer the data
>       in-process. This saves two sockets per "linked" connection (at the
>       client and at the server), and avoids the nasty Windows socketpair()
>       workaround.
>     - Keep unused 4k and 16k buffers on free lists, rather than wasting 8k
>       for every single inactive connection_t. Free items from the
>       4k/16k-buffer free lists when they haven't been used for a while.
>
>   o Minor features (build):
>     - Make autoconf search for libevent, openssl, and zlib consistently.
>     - Update deprecated macros in configure.in.
>     - When warning about missing headers, tell the user to let us
>       know if the compile succeeds anyway, so we can downgrade the
>       warning.
>     - Include the current subversion revision as part of the version
>       string: either fetch it directly if we're in an SVN checkout, do
>       some magic to guess it if we're in an SVK checkout, or use
>       the last-detected version if we're building from a .tar.gz.
>       Use this version consistently in log messages.
>
>   o Minor features (logging):
>     - Always prepend "Bug: " to any log message about a bug.
>     - Put a platform string (e.g. "Linux i686") in the startup log
>       message, so when people paste just their logs, we know if it's
>       OpenBSD or Windows or what.
>     - When logging memory usage, break down memory used in buffers by
>       buffer type.
>
>   o Minor features (directory system):
>     - New config option V2AuthoritativeDirectory that all directory
>       authorities should set. This will let future authorities choose
>       not to serve V2 directory information.
>     - Directory authorities allow multiple router descriptors and/or extra
>       info documents to be uploaded in a single go.  This will make
>       implementing proposal 104 simpler.
>
>   o Minor features (controller):
>     - Add a new config option __DisablePredictedCircuits designed for
>       use by the controller, when we don't want Tor to build any circuits
>       preemptively.
>     - Let the controller specify HOP=%d as an argument to ATTACHSTREAM,
>       so we can exit from the middle of the circuit.
>     - Implement "getinfo status/circuit-established".
>     - Implement "getinfo status/version/..." so a controller can tell
>       whether the current version is recommended, and whether any versions
>       are good, and how many authorities agree. (Patch from shibz.)
>
>   o Minor features (hidden services):
>     - Allow multiple HiddenServeicePort directives with the same virtual
>       port; when they occur, the user is sent round-robin to one
>       of the target ports chosen at random.  Partially fixes bug 393 by
>       adding limited ad-hoc round-robining.
>
>   o Minor features (other):
>     - More unit tests.
>     - Add a new AutomapHostsOnResolve option: when it is enabled, any
>       resolve request for hosts matching a given pattern causes Tor to
>       generate an internal virtual address mapping for that host.  This
>       allows DNSPort to work sensibly with hidden service users.  By
>       default, .exit and .onion addresses are remapped; the list of
>       patterns can be reconfigured with AutomapHostsSuffixes.
>     - Add an "-F" option to tor-resolve to force a resolve for a .onion
>       address. Thanks to the AutomapHostsOnResolve option, this is no
>       longer a completely silly thing to do.
>     - If Tor is invoked from something that isn't a shell (e.g. Vidalia),
>       now we expand "-f ~/.tor/torrc" correctly. Suggested by Matt Edman.
>     - Treat "2gb" when given in torrc for a bandwidth as meaning 2gb,
>       minus 1 byte: the actual maximum declared bandwidth.
>
>   o Removed features:
>     - Removed support for the old binary "version 0" controller protocol.
>       This has been deprecated since 0.1.1, and warnings have been issued
>       since 0.1.2.  When we encounter a v0 control message, we now send
>       back an error and close the connection.
>     - Remove the old "dns worker" server DNS code: it hasn't been default
>       since 0.1.2.2-alpha, and all the servers seem to be using the new
>       eventdns code.
>
>   o Minor bugfixes (portability):
>     - Even though Windows is equally happy with / and \ as path separators,
>       try to use \ consistently on Windows and / consistently on Unix: it
>       makes the log messages nicer.
>     - Correctly report platform name on Windows 95 OSR2 and Windows 98 SE.
>
>   o Minor bugfixes (directory):
>     - Correctly enforce that elements of directory objects do not appear
>       more often than they are allowed to appear.
>     - When we are reporting the DirServer line we just parsed, we were
>       logging the second stanza of the key fingerprint, not the first.
>
>   o Minor bugfixes (logging):
>     - When we hit an EOF on a log (probably because we're shutting down),
>       don't try to remove the log from the list: just mark it as
>       unusable.  (Bulletproofs against bug 222.)
>
>   o Minor bugfixes (other):
>     - In the exitlist script, only consider the most recently published
>       server descriptor for each server. Also, when the user requests
>       a list of servers that _reject_ connections to a given address,
>       explicitly exclude the IPs that also have servers that accept
>       connections to that address. (Resolves bug 405.)
>     - Stop allowing hibernating servers to be "stable" or "fast".
>     - On Windows, we were preventing other processes from reading
>       cached-routers while Tor was running.  (Reported by janbar)
>     - Make the NodeFamilies config option work. (Reported by
>       lodger -- it has never actually worked, even though we added it
>       in Oct 2004.)
>     - Check return values from pthread_mutex functions.
>     - Don't save non-general-purpose router descriptors to the disk cache,
>       because we have no way of remembering what their purpose was when
>       we restart.
>     - Add even more asserts to hunt down bug 417.
>     - Build without verbose warnings even on (not-yet-released) gcc 4.2.
>
>   o Minor bugfixes (controller):
>     - Make 'getinfo fingerprint' return a 551 error if we're not a
>       server, so we match what the control spec claims we do. Reported
>       by daejees.
>     - Fix a typo in an error message when extendcircuit fails that
>       caused us to not follow the \r\n-based delimiter protocol. Reported
>       by daejees.
>
>   o Code simplifications and refactoring:
>     - Stop passing around circuit_t and crypt_path_t pointers that are
>       implicit in other procedure arguments.
>     - Drop the old code to choke directory connections when the
>       corresponding OR connections got full: thanks to the cell queue
>       feature, OR conns don't get full any more.
>     - Make dns_resolve() handle attaching connections to circuits
>       properly, so the caller doesn't have to.
>     - Rename wants_to_read and wants_to_write to read/write_blocked_on_bw.
>     - Keep the connection array as a dynamic smartlist_t, rather than as
>       a fixed-sized array. This is important, as the number of connections
>       is becoming increasingly decoupled from the number of sockets.
>
>