Tor security advisory: Debian flaw causes weak identity keys

[Roger Dingledine]

SUMMARY:
  This is a critical security announcement.

  A bug in the Debian GNU/Linux distribution's OpenSSL package was
  announced today. This bug would allow an attacker to figure out private
  keys generated by these buggy versions of the OpenSSL library. Thus,
  all private keys generated by affected versions of OpenSSL must be
  considered to be compromised.

  Tor uses OpenSSL, so Tor users and admins need to take action in order
  to remain secure in response to this problem.

  If you are running Debian, Ubuntu, or any Debian-based GNU/Linux
  distribution, first follow the instructions at
    http://lists.debian.org/debian-security-announce/2008/msg00152.html
  to upgrade your OpenSSL package to a safe version. If you're running a
  Tor server or a Tor hidden service, then also follow the instructions
  below to replace your Tor identity keys.

  Also, if you are running Tor 0.2.0.x, you must upgrade to Tor
  0.2.0.26-rc.


WHO IS AFFECTED:
  This advisory applies to Tor 0.2.0.x and/or any Debian/Ubuntu/related
  system running _any_ Tor version. Tor clients and servers that are
  running 0.1.2.x and that are not using Debian/Ubuntu/etc don't need
  to do anything.

  Specific versions affected: All Tor 0.2.0.x development versions up
  through 0.2.0.25-rc, and most Debian/Ubuntu/related users regardless of
  Tor version.


IMPACT:
  A local attacker or malicious directory cache may be able to trick
  a client running 0.2.0.x into believing a false directory consensus, thus
  (e.g.) causing the client to create a path wholly owned by the attacker.

  Further, relay identity keys or hidden service secret keys that were
  generated on most versions of Debian, Ubuntu, or other Debian-derived OS
  are also weak (regardless of your Tor version):
    http://lists.debian.org/debian-security-announce/2008/msg00152.html


WHAT TO DO:
  First, all affected Debian/Ubuntu/similar users (regardless
  of Tor version) should apt-get upgrade to the latest (i.e. today's)
  OpenSSL package.

  Second, all Tor clients and servers running 0.2.0.x should upgrade to
  0.2.0.26-rc. (Again: Tor clients and servers that are running 0.1.2.x
  and aren't using Debian/Ubuntu/related don't need to do anything.)

  Third, Tor servers and hidden services running on Debian/Ubuntu/related
  (regardless of Tor version) should discard their identity keys and
  generate fresh ones. To discard your Tor server's keys, delete
  the "keys/secret_*" files in your datadirectory (often it is
  /var/lib/tor/). To discard your hidden service secret key, delete
  the "private_key" file from the hidden service directory that you
  configured in your torrc. [This will change the .onion address of your
  hidden service.]


DETAILS:
  Due to a bug in Debian's modified version of OpenSSL 0.9.8, all
  generated keys (and other cryptographic material!) have a stunningly
  small amount of entropy. This flaw means that brute force attacks which
  are very hard against the unmodified OpenSSL library (e.g. breaking RSA
  keys) are very practical against these keys. See the URL above for
  more information about the flaw in Debian's OpenSSL packages.

  While we believe the v2 authority keys (used in Tor 0.1.2.x) were
  generated correctly, at least three of the six v3 authority keys (used
  in Tor 0.2.0.x) are known to be weak. This fraction is uncomfortably
  close to the majority vote needed to create a networkstatus consensus,
  so the Tor 0.2.0.26-rc release changes these three affected keys.

  Relay identity keys and hidden service secret keys generated in this
  flawed way are also breakable. That is, any encryption operations with
  respect to a weak-key relay (including link encryption and onion
  encryption) can be easily broken, and their descriptors can be easily
  forged. Soon we will begin identifying weak-key relays and cutting them
  out of the network. (We will likely put out another release in a few
  days with a new identity key for our bridge authority; we apologize for
  the inconvenience to our bridge users.)

  Finally, while we don't know of any attacks that will reveal the
  location of a weak-key hidden service, an attacker could derive its
  secret key and then pretend to be the hidden service.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20080513/dea0a83c/attachment.pgp>