[tahoe-dev] Foolscap-0.2.7 released, Foolscap vs. debian openssl bug

[Brian Warner]

I released Foolscap-0.2.7 the other week, just a few days after the release
of 0.2.6 . This fixes a brown-paper-bag bug in 0.2.6 that prevented the
'flogtool' utility from running at all.

Tarballs can be obtained from foolscap.lothar.com and from PyPI. All releases
are signed by my GPG public key: 0x1514A7BD.

 http://pypi.python.org/packages/source/f/foolscap/foolscap-0.2.7.tar.gz#md5=8b766c322f30bd267405c399bce2d362
 http://pypi.python.org/packages/source/f/foolscap/foolscap-0.2.7.zip#md5=9554d22d58113c0d87f58ec3dcf43e2a

For documentation, bugs, and patches, please visit
http://foolscap.lothar.com/trac .

== Debian OpenSSL Bugs and Foolscap ==

As you've probably heard[1], last week the debian project published a
security advisory that described how the openssl package has been using a
18-ish-bit random number generator for the last two years. As a result, keys
and certificates generated by the affected versions (or used for DSA
signatures by affected versions) should be considered compromised and
immediately replaced. This affects the last 3 or 4 Ubuntu releases too
(Dapper was correct, Edgy was broken). All affected releases now have fixed
versions available for download, and obviously everyone using an affected
release needs to upgrade immediately.

 [1]: http://lists.debian.org/debian-security-announce/2008/msg00152.html

Since the bug affected key generation, keys which were created by the broken
versions will remain broken even after openssl itself is upgraded. The Debian
and Ubuntu projects have released tools to detect weak ssh keys that were
generated by these versions and disable them. Other projects (including
Foolscap) use generated keys for various purposes, so the effects of this bug
will linger even after openssl has been fixed.

How does this affect Foolscap? The short answer: Weak keys generated by the
broken versions of openssl will enable a man-in-the-middle attack, which (if
successful) would reveal the private swissnums that protect access to
Referenceables. Foolscap users who have created Tubs while they had the
broken versions installed should stop using the associated FURLs and generate
new certificates/FURLs.

The longer answer: There are three things in Foolscap that use random
numbers:

 1: TubIDs [COMPROMISED]. These are a hash of the public key that corresponds
 to a Tub's private key, and are included in FURLs (as the base32 part
 immediately following the pb:// prefix). This provides protection against a
 man-in-the-middle attack: when connecting to a FURL, the certificate of the
 remote end is compared against the TubID in the FURL, and the connection is
 dropped with extreme prejudice if they do not match. This validation is
 performed before any secrets are passed over the wire.

 2: SwissNums [SAFE]. These are a randomly-generated name for a reference,
 created when tub.registerReference(obj) is called without a name= argument,
 and when a Referenceable is sent over the wire without being explicitly
 registered. They appear at the right-hand end of the FURL, after the last
 slash. Most Referenceables are given these unguessable names, because that
 limits access to parties that have been explicitly granted access. (when
 registerReference() is called with a guessable name, anyone who can guess
 that name will get reference to the given object). The capability-based
 security of foolscap Referenceables depends upon these swissnums remaining
 secret.

 3: SSL transport sessions [VULNERABLE]. Foolscap runs over SSL, which uses
 random numbers to generate the Diffie-Hellman key agreement parameters. An
 eavesdropper who can guess one of these parameters will be able to determine
 the session key, and can decrypt the remainder of the conversation.

TubIDs are derived from an SSL certificate that OpenSSL generates on demand,
and if the broken version of OpenSSL was used for this purpose, than that
certificate will be guessable. (at some point it would be great to write a
tool that would generate the 128000-ish TubIDs that can be generated by the
broken SSL, to create a blacklist like the ones created by debian/ubuntu for
ssh keys).

So if you've generated a TubID with the broken version of openssl, it is
pretty easy to guess the corresponding private key. This allows an attacker
to mount an undetectable man-in-the-middle attack: if they can convince you
to make your TCP connection to their server instead of the right one, then
they can impersonate the real server, and they'll get to see the unencrypted
conversation (revealing the private swissnums).

Swissnums are generated by calling os.urandom(), which was not affected by
the openssl bug. As long as one of the other problems (man-in-the-middle
attack) doesn't reveal your swissnums to an attacker, access to
Referenceables will remain limited to the parties to whom you've explicitly
granted it (by telling them the swissnum, in a FURL).

Foolscap uses SSL for its encrypted transport, and SSL frequently uses
Diffie-Hellman key negotiation to establish a session key. This key
negotiation process depends upon random numbers, generated by the same buggy
RNG that is used to create keys. So if one of the two ends of an encrypted
session was using the buggy version of openssl, then an attacker may be able
to guess the session key, and thus decrypt the conversation. (note, I'm not a
cryptographer, and I'm not as confident about this attack as I am about the
others). So like the MitM attack, it seems likely that swissnums used by
sessions established during the buggy openssl era may be compromised: an
eavesdropper who recorded that encrypted conversation may be able to decrypt
it after the fact.


Of course, the whole idea of capabilities is to implement the Principle Of
Least Authority: each FURL gives access to a specific Referenceable that will
only do some specific limited task. If an MitM/eavesdropper manages to guess
your supposedly-unguessable swissnums, they'll still only be able to do
whatever the Referenceable will let them do.


So to summarize: if you've been using the buggy openssl libraries, here's
what you need to do:

 1: upgrade openssl
 2: throw out your old FURLs (tell everyone that you've given them to to stop
    using them): this protects clients from the MitM attack.
 3: throw out your old Tub certificates: the certFile= argument to Tub()
    provides a persistent location for this.. just delete that file. This
    prevents clients from ever successfully using the old FURLs to connect
    to your server.
 4: restart the Tub, allowing it to create a new certificate
 5: regenerate and distribute new FURLs

You can also just upgrade openssl (and keep using your old certs and FURLs)
if you're willing to remain vulnerable to man-in-the-middle attacks or
eavesdroppers who have recorded your earlier conversations.


cheers,
 -Brian