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
designhttps://www.torproject.org/docs/faq#KeyManagementmeans 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
bughttps://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
