[tor-relays] Recommended reject lines for relays affected by Heartbleed

Thu Apr 17 21:27:19 UTC 2014

Thanks Andrea, Thanks Scott,

Keys have been replaced and I tested the relay with the script on github
as well. I guess it was something stupid like forgetting to restart.

For the rest: test your server via the script on
https://github.com/wwwiretap/bleeding_onions

Am 17.04.2014 22:58, schrieb Scott Bennett:
> Andrea Shepard <andrea at torproject.org> wrote:
>
>> On Thu, Apr 17, 2014 at 08:58:46PM +0200, Lars Kumbier wrote:
>>> I'm supposedly running one of the still affected tor-relays and since my
>>> relay is also a guard, I'm in the latest blocklist[1] (pre-upgrade
>>> fingerprint). I did upgrade the system on April 9th to openssl
>>> 1.0.1-4ubuntu5.12 - base system is an ubuntu 12.04.
>>>
>>> According to the changelog[2], this should have fixed the heartbleed
>>> issue and according to this scanner[3], it should be as well. I did
>>> create new keys anyway, but just to be sure: Is the host[4] still
>>> affected as given in the blocklist?
>>>
>>> Best,
>>> Lars
>>> __________________________________
>>> [1]
>>> https://atlas.torproject.org/#details/9AB511B6894566C1CF56043CE60077D213CF1A1A
>>> [2] https://launchpad.net/ubuntu/+source/openssl/1.0.1-4ubuntu5.12
>>> [3] https://filippo.io/Heartbleed/#tor.kumbier.it
>>> [4] tor running on 5.9.165.90:443
>> A router at that IP with identity 9AB511B6894566C1CF56043CE60077D213CF1A1A
>> tested positive for Heartbleed several times, most recently at
>> 2014-04-17 10:19:18, before testing negative at 2014-04-17 18:51:46 (all
>> times UTC).  If you rotate the key you should be fine, but that key is
>> potentially exposed.
>>
>      No, I don't think that is sufficient.  Not only must the onion keypair
> be replaced, but also the relay's identity keypair.  Once the authorities
> have been told to reject the identity key with the fingerprint shown above,
> that relay will no longer be included in the consensus, nor will its published
> descriptor be distributed by them.
>      The reason for rejecting the identity keys as well is that the identity
> secret key may just as easily have been leaked as the onion secret key.
>      So, Lars, either destroy or rename all of your existing keys for tor,
> both secret and public, and then restart tor.  It will not find existing keys
> during its startup phase and will therefore generate brand-new keys.  After
> checking for reachability, it will publish a new descriptor.  Within a couple
> of hours, the authorities will begin including the new relay in the consensus
> and distributing the descriptor.  IOW, get rid of *all* the old keys, restart
> tor, and tor will handle the rest for you.
>
>
>                                   Scott Bennett, Comm. ASMELG, CFIAG
> **********************************************************************
> * Internet:   bennett at sdf.org   *or*   bennett at freeshell.org   *
> *--------------------------------------------------------------------*
> * "A well regulated and disciplined militia, is at all times a good  *
> * objection to the introduction of that bane of all free governments *
> * -- a standing army."                                               *
> *    -- Gov. John Hancock, New York Journal, 28 January 1790         *
> **********************************************************************
> _______________________________________________
> tor-relays mailing list
> tor-relays at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

-- 

Kumbier IT Consulting and Solutions <http://kumbier.it>

*Lars Kumbier* / IT Consultant
lars at kumbier.it <mailto:lars at kumbier.it> (gpg
<http://kumbier.it/Lars_Kumbier.asc>)

*Kumbier IT Consulting and Solutions* Office: +49 (0)6221 1871632
<tel:004962211871632>
SRH Gründerzentrum | Waldhoferstr. 100 | 69123 Heidelberg | Germany
http://kumbier.it

Facebook <https://www.facebook.com/lars.kumbier> Twitter
<http://twitter.com/LarsKumbier> Google Plus
<https://plus.google.com/+LarsKumbier> LinkedIn
<http://linkedin.com/in/larskumbier>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140417/548c92eb/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: edgeejfa.png
Type: image/png
Size: 7749 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140417/548c92eb/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gejghegf.png
Type: image/png
Size: 554 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140417/548c92eb/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffbffcji.png
Type: image/png
Size: 676 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140417/548c92eb/attachment-0007.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: chdeadja.png
Type: image/png
Size: 686 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140417/548c92eb/attachment-0008.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ihhieegj.png
Type: image/png
Size: 631 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140417/548c92eb/attachment-0009.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140417/548c92eb/attachment-0001.sig>