Merge tag 'tor-0.2.4.8-alpha' into debian-merge

.dirstamp

# Stuff made by our makefiles

*.bak

# Python droppings

*.pyc

# /

/Makefile

/src/common/libor-crypto.lib

/src/common/libor-event.a

/src/common/libor-event.lib

/src/common/libcurve25519_donna.a

/src/common/libcurve25519_donna.lib

# /src/config/

/src/config/Makefile

/src/test/bench.exe

/src/test/test

/src/test/test-child

/src/test/test-ntor-cl

/src/test/test.exe

/src/test/test-child.exe

/src/test/test-ntor-cl.exe

# /src/tools/

/src/tools/tor-checkkey

Changes in version 0.2.4.8-alpha - 2013-01-14

  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.

  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.

Changes in version 0.2.4.7-alpha - 2012-12-24

  Tor 0.2.4.7-alpha introduces a new approach to providing fallback

  directory mirrors for more robust bootstrapping; fixes more issues where

dnl Copyright (c) 2007-2012, The Tor Project, Inc.

dnl See LICENSE for licensing information

AC_INIT([tor],[0.2.4.7-alpha])

AC_INIT([tor],[0.2.4.8-alpha])

AC_CONFIG_SRCDIR([src/or/main.c])

AM_INIT_AUTOMAKE

m4_ifdef([AM_SILENT_RULES], [AM_SILENT_RULES([yes])])

   AS_HELP_STRING(--enable-static-zlib, Link against a static zlib library. Requires --with-zlib-dir))

AC_ARG_ENABLE(static-tor,

   AS_HELP_STRING(--enable-static-tor, Create an entirely static Tor binary. Requires --with-openssl-dir and --with-libevent-dir and --with-zlib-dir))

AC_ARG_ENABLE(curve25519,

   AS_HELP_STRING(--disable-curve25519, Build Tor with no curve25519 elliptic-curve crypto support))

if test "$enable_static_tor" = "yes"; then

  enable_static_libevent="yes";

    fi

fi

dnl ============================================================

dnl We need an implementation of curve25519.

dnl set these defaults.

have_a_curve25519=no

build_curve25519_donna=no

build_curve25519_donna_c64=no

use_curve25519_donna=no

use_curve25519_nacl=no

CURVE25519_LIBS=

if test x$enable_curve25519 != xno; then

  dnl The best choice is using curve25519-donna-c64, but that requires

  dnl that we

  AC_CACHE_CHECK([whether we can use curve25519-donna-c64],

    tor_cv_can_use_curve25519_donna_c64,

    [AC_RUN_IFELSE(

      [AC_LANG_PROGRAM([dnl

        #include <stdint.h>

        typedef unsigned uint128_t __attribute__((mode(TI)));

	], [dnl

          uint64_t a = ((uint64_t)2000000000) * 1000000000;

	  uint64_t b = ((uint64_t)1234567890) << 24;

	  uint128_t c = ((uint128_t)a) * b;

	  return ((uint64_t)(c>>96)) == 522859 &&

	         ((uint64_t)(c>>64))&0xffffffffL == 3604448702L &&

                 ((uint64_t)(c>>32))&0xffffffffL == 2351960064L &&

                 ((uint64_t)(c))&0xffffffffL == 0;

        ])],

	[tor_cv_can_use_curve25519_donna_c64=yes],

        [tor_cv_can_use_curve25519_donna_c64=no],

	[AC_COMPILE_IFELSE(

          [AC_LANG_PROGRAM([dnl

            #include <stdint.h>

            typedef unsigned uint128_t __attribute__((mode(TI)));

            ], [dnl

              uint64_t a = ((uint64_t)2000000000) * 1000000000;

	      uint64_t b = ((uint64_t)1234567890) << 24;

	      uint128_t c = ((uint128_t)a) * b;

	      return ((uint64_t)(c>>96)) == 522859 &&

	             ((uint64_t)(c>>64))&0xffffffffL == 3604448702L &&

                     ((uint64_t)(c>>32))&0xffffffffL == 2351960064L &&

                     ((uint64_t)(c))&0xffffffffL == 0;

            ])],

            [tor_cv_can_use_curve25519_donna_c64=cross],

	    [tor_cv_can_use_curve25519_donna_c64=no])])])

  AC_CACHE_CHECK([whether we can use curve25519 from nacl],

    tor_cv_can_use_curve25519_nacl,

    [tor_saved_LIBS="$LIBS"

     LIBS="$LIBS -lnacl"

     AC_LINK_IFELSE(

       [AC_LANG_PROGRAM([dnl

         #include <crypto_scalarmult_curve25519.h>

         #ifdef crypto_scalarmult_curve25519_ref_BYTES

	 #error Hey, this is the reference implementation!

	 #endif

       ], [

	 unsigned char *a, *b, *c; crypto_scalarmult_curve25519(a,b,c);

       ])], [tor_cv_can_use_curve25519_nacl=yes],

       [tor_cv_can_use_curve25519_nacl=no])

     LIBS="$tor_saved_LIBS" ])

   dnl Okay, now we need to figure out which one to actually use. Fall back

   dnl to curve25519-donna.c

   if test x$tor_cv_can_use_curve25519_donna_c64 != xno; then

     build_curve25519_donna_c64=yes

     use_curve25519_donna=yes

   elif test x$tor_cv_can_use_curve25519_nacl = xyes; then

     use_curve25519_nacl=yes

     CURVE25519_LIBS=-lnacl

   else

     build_curve25519_donna=yes

     use_curve25519_donna=yes

   fi

   have_a_curve25519=yes

fi

if test x$have_a_curve25519 = xyes; then

  AC_DEFINE(CURVE25519_ENABLED, 1,

            [Defined if we have a curve25519 implementation])

fi

if test x$use_curve25519_donna = xyes; then

  AC_DEFINE(USE_CURVE25519_DONNA, 1,

            [Defined if we should use an internal curve25519_donna{,_c64} implementation])

fi

if test x$use_curve25519_nacl = xyes; then

  AC_DEFINE(USE_CURVE25519_NACL, 1,

            [Defined if we should use a curve25519 from nacl])

fi

AM_CONDITIONAL(BUILD_CURVE25519_DONNA, test x$build_curve25519_donna = xyes)

AM_CONDITIONAL(BUILD_CURVE25519_DONNA_C64, test x$build_curve25519_donna_c64 = xyes)

AM_CONDITIONAL(CURVE25519_ENABLED, test x$have_a_curve25519 = xyes)

AC_SUBST(CURVE25519_LIBS)

dnl Make sure to enable support for large off_t if available.

AC_SYS_LARGEFILE

!include "LogicLib.nsh"

!include "FileFunc.nsh"

!insertmacro GetParameters

!define VERSION "0.2.4.7-alpha"

!define VERSION "0.2.4.8-alpha"

!define INSTALLER "tor-${VERSION}-win32.exe"

!define WEBSITE "https://www.torproject.org/"

!define LICENSE "LICENSE"

    increases the odds that an adversary who owns some servers will observe a

    fraction of your paths. (Default: 1)

**UseEntryGuardsAsDirectoryGuards** **0**|**1**::

    If this option is set to 1, we try to use our entry guards as directory

    guards, and failing that, pick more nodes to act as our directory guards.

    This helps prevent an adversary from enumerating clients. It's only

    available for clients (non-relay, non-bridge) that aren't configured to

    download any non-default directory material.  It doesn't currently

    do anything when we lack a live consensus. (Default: 1)

**NumEntryGuards** __NUM__::

    If UseEntryGuards is set to 1, we will try to pick a total of NUM routers

    as long-term entries for our circuits. (Default: 3)

**NumDirectoryGuards** __NUM__::

    If UseEntryGuardsAsDirectoryGuards is enabled, we try to make sure we

    have at least NUM routers to use as directory guards. (Default: 3)

**SafeSocks** **0**|**1**::

    When this option is enabled, Tor will reject application connections that

    use unsafe variants of the socks protocol -- ones that only provide an IP

    "auto" (recommended) then it is on for all clients that do not set

    FetchUselessDescriptors. (Default: auto)

**UseNTorHandshake** **0**|**1**|**auto**::

    The "ntor" circuit-creation handshake is faster and (we think) more

    secure than the original ("TAP") circuit handshake, but starting to use

    it too early might make your client stand out. If this option is 0, your

    Tor client won't use the ntor handshake. If it's 1, your Tor client

    will use the ntor handshake to extend circuits through servers that

    support it. If this option is "auto" (recommended), then your client

    will use the ntor handshake once enough directory authorities recommend

    it. (Default: auto)

**PathBiasCircThreshold** __NUM__ +

**PathBiasNoticeRate** __NUM__ +

**PathBiasDisableRate** __NUM__ +

**PathBiasWarnRate** __NUM__ +

**PathBiasExtremeRate** __NUM__ +

**PathBiasDropGuards** __NUM__ +

**PathBiasScaleThreshold** __NUM__ +

**PathBiasScaleFactor** __NUM__::

**PathBiasMultFactor** __NUM__ +

**PathBiasScaleFactor** __NUM__ +

**PathBiasUseCloseCounts** __NUM__::

    These options override the default behavior of Tor's (**currently

    experimental**) path bias detection algorithm. To try to find broken or

    misbehaving guard nodes, Tor looks for nodes where more than a certain

    fraction of circuits through that node fail after the first hop.  The

    PathBiasCircThreshold option controls how many circuits we need to build

    through a guard before we make these checks.  The PathBiasNoticeRate and

    PathBiasDisableRate options control what fraction of circuits must

    succeed through a guard so we won't warn about it or disable it,

    respectively.  When we have seen more than PathBiasScaleThreshold

    circuits through a guard, we divide our observations by

    PathBiasScaleFactor, so that new observations don't get swamped by old

    ones. +

    fraction of circuits through that guard fail to get built. If

    PathBiasUseCloseCounts is set to 1 (the default), usage-based accounting is

    performed, and circuits that fail to carry streams are also counted as

    failures. +

 +

    The PathBiasCircThreshold option controls how many circuits we need to build

    through a guard before we make these checks.  The PathBiasNoticeRate,

    PathBiasWarnRate and PathBiasExtremeRate options control what fraction of

    circuits must succeed through a guard so we won't write log messages.

    If less than PathBiasExtremeRate circuits succeed *and* PathBiasDropGuards

    is set to 1, we disable use of that guard. +

 +

    When we have seen more than PathBiasScaleThreshold

    circuits through a guard, we scale our observations by

    PathBiasMultFactor/PathBiasScaleFactor, so that new observations don't get

    swamped by old ones. +

 +

    By default, or if a negative value is provided for one of these options,

    Tor uses reasonable defaults from the networkstatus consensus document.

    If no defaults are available there, these options default to 20, .70,

    0.0, 200, and 4 respectively.

    If no defaults are available there, these options default to 150, .70,

    .50, .30, 0, 300, 1, and 2 respectively.

**ClientUseIPv6** **0**|**1**::

    If this option is set to 1, Tor might connect to entry nodes over

**GeoIPv6File** __filename__::

    A filename containing IPv6 GeoIP data, for use with by-country statistics.

**TLSECGroup** **P224**|**P256**::

    What EC group should we try to use for incoming TLS connections?

    P224 is faster, but makes us stand out more. Has no effect if

    we're a client, or if our OpenSSL version lacks support for ECDHE.

    (Default: P224 for public servers; P256 for bridges.)

**CellStatistics** **0**|**1**::

    When this option is enabled, Tor writes statistics on the mean time that

    cells spend in circuit queues to disk every 24 hours. (Default: 0)