from https://blog.torproject.org/blog/openssl-bug-cve-2014-0160 :
> 1. *Clients*: Tor Browser shouldn't be affected, since it uses libnss rather than openssl. But Tor clients could possibly be induced to send sensitive information like "what sites you visited in this session" to your entry guards. If you're using TBB we'll have new bundles out shortly; if you're using your operating system's Tor package you should get a new OpenSSL package and then be sure to manually restart your Tor. 2. *Relays and bridges*: Tor relays and bridges could maybe be made to leak their medium-term onion keys (rotated once a week), or their long-term relay identity keys. An attacker who has your relay identity key can publish a new relay descriptor indicating that you're at a new location (not a particularly useful attack). An attacker who has your relay identity key, has your onion key, and can intercept traffic flows to your IP address can impersonate your relay (but remember that Tor's multi-hop design<https://www.torproject.org/docs/faq#KeyManagement>means that attacking just one relay in the client's path is not very useful). In any case, best practice would be to update your OpenSSL package, discard all the files in keys/ in your DataDirectory, and restart your Tor to generate new keys. 3. *Hidden services*: Tor hidden services might leak their long-term hidden service identity keys to their guard relays. Like the last big OpenSSL bug<https://blog.torproject.org/blog/debian-openssl-flaw%3A-what-does-it-mean-tor-clients%3F>, this shouldn't allow an attacker to identify the location of the hidden service, but an attacker who knows the hidden service identity key can impersonate the hidden service. Best practice would be to move to a new hidden-service address at your convenience. 4. *Directory authorities*: In addition to the keys listed in the "relays and bridges" section above, Tor directory authorities might leak their medium-term authority signing keys. Once you've updated your OpenSSL package, you should generate a new signing key. Long-term directory authority identity keys are offline so should not be affected (whew). More tricky is that clients have your relay identity key hard-coded, so please don't rotate that yet. We'll see how this unfolds and try to think of a good solution there. 5. *Tails* is still tracking Debian oldstable, so it should not be affected by this bug. 6. *Orbot* looks vulnerable; we'll try to publish more details here soon. 7. It looks like most of the webservers in the https://www.torproject.org/ rotation need upgrades too, and maybe we'll need to throw away our torproject SSL web cert and get a new one — hopefully we'll deal with all that soon. On Mon, Apr 7, 2014 at 7:56 PM, Geoff Down <geoffd...@fastmail.net> wrote: > > > On Tue, Apr 8, 2014, at 12:17 AM, Roger Dingledine wrote: > > A new OpenSSL vulnerability on 1.0.1 through 1.0.1f is out today, > > which can be used to reveal up to 64kB of memory to a connected client > > or server. > > > > https://blog.torproject.org/blog/openssl-bug-cve-2014-0160 > > > > The short version is: upgrade your openssl (unless you're running an > > old one), and also more packages coming soon. > > > > --Roger > > So this is the openssl *binary*, the version of which is found by typing > openssl version > not some library used when compiling Tor? > If the latter, how do we find the version? > GD > > -- > http://www.fastmail.fm - Access all of your messages and folders > wherever you are > > -- > tor-talk mailing list - tor-talk@lists.torproject.org > To unsubscribe or change other settings go to > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk > -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk