[tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade

[grarpamp]

On Tue, Apr 8, 2014 at 4:34 PM, Roger Dingledine <arma at mit.edu> wrote:
> On Tue, Apr 08, 2014 at 04:35:39PM +0100, mick wrote:
>> Moritz Bartl <moritz at torservers.net> allegedly wrote:
>> > Yes. You made it generate new keys, so it is a "new relay" as far as
>> > Tor is concerned. This is why not everybody should generate new keys
>> > immediately, especially larger relays. But don't worry too much,
>> > you'll get your flags back eventually. :)
>>
>> But Roger's blog post makes no mention of the advisability (or
>> otherwise) of a mass re-generation of keys. All it says is that best
>> practice states this would be a good idea.
>
> The first iteration of my blog post said something like "if you run many
> fast and stable relays, consider spreading out your relay identity key
> replacement over the next week so we don't unbalance the network."
>
> But I removed that sentence a little while later, when it became clear
> that nobody knows for sure but quite possibly an attacker could have
> extracted key material from vulnerable relays. If that actually happened,
> I think we probably want new identity keys asap, *especially* from the
> big relays, and we'll be happier tolerating a couple of bumpy days while
> the network recovers.

My reading, even without the PoC's and mmap docs that have since
come out, is that it's always been:
1) simply connect to any vulnerable openssl 1.0.1 [START]TLS service port
2) get a nice 64k chunk of core returned to you (regardless of whether
you posess any type of higher level token, onion key, user cert, etc.)

I'm not so sure it's the 'big relays' that are priority (at least as far as the
net as a whole is concerned). More likely just the largest number of nodes
in the shortest time. And of course key meta points like the authorities and
dirservs.

I've been ad-hoc watching the resultant drop in cumulative node uptime
since yesterday afternoon... we're down maybe 18% from an original
~14.1 gigasecs. And ~3000 descriptors have uptime newer than the
release of openssl 1.0.1g tarball. Lots of caveats in these metrics for sure.

Ps: I liked the idea of the two key transition proposals on tor-dev. Maybe
at this point, if many auths are to swap keys, point releases may be
easier than coding that for now. There's also probably merit in a new
rcfile called
"toretcdir/authority_keys" containing the data in src/or/config.c . Would make
for quicker near-term updates by distributing a small rcfile than recompiling
until the proposals develop.