Hi folks,
I'm attaching the list of relay identity fingerprints that I'm rejecting on moria1 as of yesterday.
I got the list from Sina's scanner: https://encrypted.redteam.net/bleeding_edges/
I thought for a while about taking away their Valid flag rather than rejecting them outright, but this way they'll get notices in their logs.
I also thought for a while about trying to keep my list of fingerprints up-to-date (i.e. removing the !reject line once they've upgraded their openssl), but on the other hand, if they were still vulnerable as of yesterday, I really don't want this identity key on the Tor network even after they've upgraded their openssl.
If the other directory authority operators follow suit, we'll lose about 12% of the exit capacity and 12% of the guard capacity.
I/we should add to this list as we discover other relays that come online with vulnerable openssl versions.
Also these are just the relays with Guard and/or Exit flags, so we should add the other 1000+ at some point soon.
--Roger
Am 16.04.2014 06:42 schrieb Roger Dingledine:
Hi folks,
I'm attaching the list of relay identity fingerprints that I'm rejecting on moria1 as of yesterday.
I got the list from Sina's scanner: https://encrypted.redteam.net/bleeding_edges/
I thought for a while about taking away their Valid flag rather than rejecting them outright, but this way they'll get notices in their logs.
I also thought for a while about trying to keep my list of fingerprints up-to-date (i.e. removing the !reject line once they've upgraded their openssl), but on the other hand, if they were still vulnerable as of yesterday, I really don't want this identity key on the Tor network even after they've upgraded their openssl.
If the other directory authority operators follow suit, we'll lose about 12% of the exit capacity and 12% of the guard capacity.
How is that going to be decided?
I/we should add to this list as we discover other relays that come online with vulnerable openssl versions.
Also these are just the relays with Guard and/or Exit flags, so we should add the other 1000+ at some point soon.
--Roger
Thanks for your work!
Updating a previous post full of measurement caveats (in particular not keying IP/FP to discard old descriptors)... now at: - 35% reduction in cumulative relay uptime from 14.1Gsec pre-hb. - 4400 out of 5835 descriptors with uptime less than hb-release and totaling 1.2Gsec among them.
tor-relays@lists.torproject.org