Re: [tor-relays] Metrics for assessing EFF's Tor relay challenge?
On 05/04/14 17:46, Lukas Erlacher wrote: Hello Nikita, Karsten, On 04/05/2014 05:03 PM, Nikita Borisov wrote: On Sat, Apr 5, 2014 at 3:58 PM, Karsten Loesing kars...@torproject.org wrote: Installing packages using Python-specific package managers is going to make our sysadmins sad, so we should have a very good reason for wanting such a package. In general, we don't need the latest and greatest package. Unless we do. What about virtualenv? Part of the premise behind it is that you can configure appropriate packages as a developer / operator without having to bother sysadmins and making them worried about system-wide effects. - Nikita I was going to mention virtualenv as well, but I have to admit that I find it weird and scary, especially since I haven't found good documentation for it. If there is somebody who is familiar with virtualenv that would probably be the best solution. I'm afraid I don't know enough about Python or virtualenv. So far, it was almost zero effort for our sysadmins to install a package from the repositories and keep that up-to-date. I'd like to stick with the apt-get approach and save the virtualenv approach for situations when we really need a package that is not contained in the repositories. Thanks for the suggestion, though! On 04/05/2014 04:58 PM, Karsten Loesing wrote: My hope with challenger is that it's written quickly, working quietly for a year, and then disappearing without anybody noticing. I'd rather not want to maintain yet another thing. So, maybe Weather is a better candidate for using onion-py than challenger. Yes, I understand. Yeah, I think we'll want to define a maximum lifetime of cache entries, or the poor cache will explode pretty soon. What usage patterns do we have to expect? Do we want to hit onionoo to check if the cache is still valid for every request, or should we do hard caching for several minutes? The best UX solution would be to have a background task that keeps the cache current so user requests can be delivered without hitting onionoo at all. That's a fine question. I can see various caching approaches here. But I just realize that this is premature optimization. Let's first build the thing and download whatever we need and whenever we need it. And once we know what caching needs we have, let's build the cache. In other words, unless we do something intelligent with the cache, the cache is not actually going to be very useful. Valid point. :) Great, your help would be much appreciated! Want to send me a pull request whenever you have something to merge? Will do. Great. Thanks! All the best, Karsten ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
On 04/08/2014 04:58 PM, ecart...@riseup.net wrote: Greetings all. I follwed the above instructions on my relay. Upon restarting Tor I have lost all of my flags and I have a new fingerprint. Previously I had the Fast, Guard, Named, Running, Stable, and Valid flags. Is this expected? Did I miss a step somewhere? Thanks for any help. 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. :) -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
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. Greetings all. I follwed the above instructions on my relay. Upon restarting Tor I have lost all of my flags and I have a new fingerprint. Previously I had the Fast, Guard, Named, Running, Stable, and Valid flags. Is this expected? Did I miss a step somewhere? Thanks for any help. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] 1.0.1e-2+deb7u5 should be good for Wheezy
Thanks for posting the blog in here 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 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. I am on Wheezy and did 'apt-get update' and 'apt-get upgrade'. 1.0.1e-2+deb7u5 should be good for Wheezy. ( Deleted keys, restarted tor, receive a new fingerprint and stand back in line for new flags - but we are safe ) Felix ==-- - - - - - - - - - - --== -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v2.0.22 (MingW32) mQENBFL/49QBCADF+dfqQzatgiEH/SgymqjyIt2VdSe2mtKF1zHPjOnYiq88/qio 88Q4CjcImhFGPZCdDqLlno6ufl55omhTLfr4frNRgvfOsazzWNzIcghc+/bOyidD E6TmbCjfL9Zvp1jr9vW0eC6NmmUbTbkrs6M/eF1CS/PqZS1cCJuQoz0BBHgzMIMI Ro78dgcmcml4kNzP6z7FrecWaqikJk1h8jxpP0+bSrNY21b1OQA05Nm3glhlQuI8 CRzWRJXVyfk0qSqC1KUYB/qKVwXcIh0EB1CZgJnfMatZkwwj9re8LQYIkaYp6XnU u2g5/WuD6QhRA2cZ0eWG03lYzFCBc5vCj4Z3ABEBAAG0F0ZlbGl4IDxmZWxpeGhv ZUBnbXguZGU+iQE5BBMBAgAjBQJS/+PUAhsPBwsJCAcDAgEGFQgCCQoLBBYCAwEC HgECF4AACgkQn7tfwacd4SUoRwf/e3wEG7PWoLOEKMsGIf/hc6b4Q7E5xtTe5auh vowcFXkL+4sGn8SJzMEgYO3rgsmE6HvxSf20A3vT/J1IpSo/QsgtnxToaXnilMpK Oy58KQjxCJB7Reg9BtF2DZsPul0QSftSAdrXtCD6jIXRbyGwl5Wh0RLlAF0vB/KZ yYpoe1OmDnjDfGW64oJHs6dDHW1toit30fYOvULwphvCS02h61PmoMFmlabtfDo/ L4PyjvHZIzjVmf2UACEIV+oNc/yzAj5pFRPE8psfxq+0Sz0DRrAWnfqIilzlEzQX 8FqwHp+Kln7XSrA74Wr3LupVe1vnzRayWdhPi7S+AGUwiyFCXw== =7lFN -END PGP PUBLIC KEY BLOCK- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
On Tue, 08 Apr 2014 17:01:18 +0200 Moritz Bartl mor...@torservers.net allegedly wrote: On 04/08/2014 04:58 PM, ecart...@riseup.net wrote: Greetings all. I follwed the above instructions on my relay. Upon restarting Tor I have lost all of my flags and I have a new fingerprint. Previously I had the Fast, Guard, Named, Running, Stable, and Valid flags. Is this expected? Did I miss a step somewhere? Thanks for any help. 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. (I have regenerated mine and restarted so I too now have a shiny a new relay). Mick - Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net - signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
On Tue, Apr 8, 2014 at 11:01 AM, Moritz Bartl mor...@torservers.net wrote: On 04/08/2014 04:58 PM, ecart...@riseup.net wrote: Greetings all. I follwed the above instructions on my relay. Upon restarting Tor I have lost all of my flags and I have a new fingerprint. Previously I had the Fast, Guard, Named, Running, Stable, and Valid flags. Is this expected? Did I miss a step somewhere? Thanks for any help. 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. :) Note that this also means you need to update your MyFamily directives. I don't think anything else has long-term key fingerprints wired into it, but I could be wrong. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
Thanks Moritz. But shouldn't I at least be Fast Running Valid? I thought that when I first set up the relay I received those flags almost immediately, but I've been running for over an hour and I still have no flags at all. Also, if all relays lose their flags won't we be left with an inoperable Tor network for a few days? On 04/08/2014 04:58 PM, ecart...@riseup.net wrote: Greetings all. I follwed the above instructions on my relay. Upon restarting Tor I have lost all of my flags and I have a new fingerprint. Previously I had the Fast, Guard, Named, Running, Stable, and Valid flags. Is this expected? Did I miss a step somewhere? Thanks for any help. 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. :) -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
Where is the instructions for this? Thanks! Dennis -Original Message- From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of mick Sent: Tuesday, April 8, 2014 11:36 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade On Tue, 08 Apr 2014 17:01:18 +0200 Moritz Bartl mor...@torservers.net allegedly wrote: On 04/08/2014 04:58 PM, ecart...@riseup.net wrote: Greetings all. I follwed the above instructions on my relay. Upon restarting Tor I have lost all of my flags and I have a new fingerprint. Previously I had the Fast, Guard, Named, Running, Stable, and Valid flags. Is this expected? Did I miss a step somewhere? Thanks for any help. 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. (I have regenerated mine and restarted so I too now have a shiny a new relay). Mick - Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net - ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
On Debian or Ubuntu: service tor stop rm /var/lib/tor/keys/* apt-get update apt-get -y upgrade Cheers Luke On 04/08/2014 05:55 PM, Dennis Crawford wrote: Where is the instructions for this? Thanks! Dennis -Original Message- From: tor-relays [mailto:tor-relays-boun...@lists.torproject.org] On Behalf Of mick Sent: Tuesday, April 8, 2014 11:36 AM To: tor-relays@lists.torproject.org Subject: Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade On Tue, 08 Apr 2014 17:01:18 +0200 Moritz Bartl mor...@torservers.net allegedly wrote: On 04/08/2014 04:58 PM, ecart...@riseup.net wrote: Greetings all. I follwed the above instructions on my relay. Upon restarting Tor I have lost all of my flags and I have a new fingerprint. Previously I had the Fast, Guard, Named, Running, Stable, and Valid flags. Is this expected? Did I miss a step somewhere? Thanks for any help. 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. (I have regenerated mine and restarted so I too now have a shiny a new relay). Mick - Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net - ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
On Tue, 08 Apr 2014 17:01:18 +, Moritz Bartl wrote: ... immediately, especially larger relays. But don't worry too much, you'll get your flags back eventually. :) But my name only very eventually? Andreas -- Totally trivial. Famous last words. From: Linus Torvalds torvalds@*.org Date: Fri, 22 Jan 2010 07:29:21 -0800 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
On Tue, 08 Apr 2014 19:04:08 +0200 Lukas Erlacher t...@lerlacher.de allegedly wrote: On Debian or Ubuntu: service tor stop rm /var/lib/tor/keys/* apt-get update apt-get -y upgrade You might want to restart tor after that. - Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net - signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 1.0.1e-2+deb7u5 should be good for Wheezy
Hy there. My Debian Wheezy box is using 1.0.1e-2+deb7u6 after the upgrade I think this should be good :) Am Dienstag, 8. April 2014, 17:09:07 schrieb Felix: Thanks for posting the blog in here 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 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. I am on Wheezy and did 'apt-get update' and 'apt-get upgrade'. 1.0.1e-2+deb7u5 should be good for Wheezy. ( Deleted keys, restarted tor, receive a new fingerprint and stand back in line for new flags - but we are safe ) Felix ==-- - - - - - - - - - - --== -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v2.0.22 (MingW32) mQENBFL/49QBCADF+dfqQzatgiEH/SgymqjyIt2VdSe2mtKF1zHPjOnYiq88/qio 88Q4CjcImhFGPZCdDqLlno6ufl55omhTLfr4frNRgvfOsazzWNzIcghc+/bOyidD E6TmbCjfL9Zvp1jr9vW0eC6NmmUbTbkrs6M/eF1CS/PqZS1cCJuQoz0BBHgzMIMI Ro78dgcmcml4kNzP6z7FrecWaqikJk1h8jxpP0+bSrNY21b1OQA05Nm3glhlQuI8 CRzWRJXVyfk0qSqC1KUYB/qKVwXcIh0EB1CZgJnfMatZkwwj9re8LQYIkaYp6XnU u2g5/WuD6QhRA2cZ0eWG03lYzFCBc5vCj4Z3ABEBAAG0F0ZlbGl4IDxmZWxpeGhv ZUBnbXguZGU+iQE5BBMBAgAjBQJS/+PUAhsPBwsJCAcDAgEGFQgCCQoLBBYCAwEC HgECF4AACgkQn7tfwacd4SUoRwf/e3wEG7PWoLOEKMsGIf/hc6b4Q7E5xtTe5auh vowcFXkL+4sGn8SJzMEgYO3rgsmE6HvxSf20A3vT/J1IpSo/QsgtnxToaXnilMpK Oy58KQjxCJB7Reg9BtF2DZsPul0QSftSAdrXtCD6jIXRbyGwl5Wh0RLlAF0vB/KZ yYpoe1OmDnjDfGW64oJHs6dDHW1toit30fYOvULwphvCS02h61PmoMFmlabtfDo/ L4PyjvHZIzjVmf2UACEIV+oNc/yzAj5pFRPE8psfxq+0Sz0DRrAWnfqIilzlEzQX 8FqwHp+Kln7XSrA74Wr3LupVe1vnzRayWdhPi7S+AGUwiyFCXw== =7lFN -END PGP PUBLIC KEY BLOCK- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elri...@elrippoisland.net Encrypted messages are welcome. 0x84DF1F7E6AE03644 -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
Indeed, you should check you /var/lib/tor/keys directory to be empty before restarting your service again. ATTENTION!!! On a Debian box, i got the warning to restart the openssh and openvpn server, to be sure that these services use the new libssl binaries. It is recommended to not only restart the service like openssh, openvpn, apache2, tor and so on... Just restart the whole box with [sudo reboot] to be kind of sure it is using the patched openssl libaries. greetings, elrippo Am Dienstag, 8. April 2014, 18:15:30 schrieb mick: On Tue, 08 Apr 2014 19:04:08 +0200 Lukas Erlacher t...@lerlacher.de allegedly wrote: On Debian or Ubuntu: service tor stop rm /var/lib/tor/keys/* apt-get update apt-get -y upgrade You might want to restart tor after that. - Mick Morgan gpg fingerprint: FC23 3338 F664 5E66 876B 72C0 0A1F E60B 5BAD D312 http://baldric.net - -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elri...@elrippoisland.net Encrypted messages are welcome. 0x84DF1F7E6AE03644 -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP
Re: [tor-relays] 1.0.1e-2+deb7u5 should be good for Wheezy
On Tue, 08 Apr 2014 19:54:21 +0200 elrippo elri...@elrippoisland.net wrote: Hy there. My Debian Wheezy box is using 1.0.1e-2+deb7u6 after the upgrade I think this should be good :) Thanks for the heads-up, turns out it was updated twice in a day. I guess the 6th version is not as important if you remembered to manually restart everything that's using OpenSSL. openssl (1.0.1e-2+deb7u6) wheezy-security; urgency=high * Non-maintainer upload by the Security Team. * Enable checking for services that may need to be restarted * Update list of services to possibly restart -- Salvatore Bonaccorso car...@debian.org Tue, 08 Apr 2014 10:44:53 +0200 openssl (1.0.1e-2+deb7u5) wheezy-security; urgency=high * Non-maintainer upload by the Security Team. * Add CVE-2014-0160.patch patch. CVE-2014-0160: Fix TLS/DTLS hearbeat information disclosure. A missing bounds check in the handling of the TLS heartbeat extension can be used to reveal up to 64k of memory to a connected client or server. -- Salvatore Bonaccorso car...@debian.org Mon, 07 Apr 2014 22:26:55 +0200 -- With respect, Roman signature.asc Description: PGP signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 1.0.1e-2+deb7u5 should be good for Wheezy
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hy Guido. I tend to use openssl-dev, so I suppose that is on behalf of the dev extension :D greetings, elrippo On 08. April 2014 20:07:58 MESZ, Guido Witmond gu...@witmond.nl wrote: On 04/08/14 19:54, elrippo wrote: Hy there. My Debian Wheezy box is using 1.0.1e-2+deb7u6 after the upgrade I think this should be good :) According to the debian security announcement it has been fixed at *u5*. Where did you get *u6*? A QUANTUM INSERT? Or a typo? http://www.debian.org/security/2014/dsa-2896 Guido. - -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elri...@elrippoisland.net Encrypted messages are welcome. 0x84DF1F7E6AE03644 - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI KmTEJxdADB5v/Jx4HiLHNDSfBUb8gfONCkNSTYvTcSwTjWzHOkXeE/9ZbQARAQAB tD5lbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0ZWQpIDxlbHJpcHBvQGVs cmlwcG9pc2xhbmQubmV0PokCOAQTAQIAIgUCUfv3swIbLwYLCQgHAwIGFQgCCQoL BBYCAwECHgECF4AACgkQhN8ffmrgNkT8+BAAoAXBqu4/O2Cs5FSWWZpzgScNEgq7 uHhOKeYmRfgKlOUPoYlPB1DBqdOAXSKb9OvsmyOvpoGnqijB7aAJBoyQYW/OCQgd U8L4eTCf4yRZnfFLdgskcPfN1p0Rs/yinGEooBJFtYa7mT6J0UTW2JjCLZK2AFCW oF+KBu5JICXGBXigb2ZbX1jWjxP5H1RidQw6HF5z4z34SjLWAOOeZ8B/Xfz6Fs0s IAuLu2O4HE4DI8Qu196LhSVHHgr3uMTkvN1t5nKwyjrRQztwXXk9qIomII3ydNYb BYAGdWNNMfLb1kmDwC5wQHAFvSP1aiMF3aKAY+gl2wXSGO6JqM0SteJS3dytIljI kzu0atc9HuGs/HDQgdmpAS4WU2YefEr/WieltSiAKlwuC+3wg+CONJ6TE1vgNDU/ axerttb0jq7UQb/nAp05bsrB7XH1Vs+1ON9lUPEfWRmwQcrVK5JUrUWa/4tA/UeM XvFcPFtFluGTlLewgJIqcvjPXFwpbDZprXJsMkwew/A6B6n3+0sbgf7p3QSGkVbi dwQAymTbHdYqLnbcnKZhjto3Wjw1J5QB2wuiRYlpjV3i7AWTGlqoSTOWCCV+HamQ qeFYNYAWNFx3+J/oi7xDi8t9bHVNA205equ+y2sj3G5uGJ6LSHQ8AXp9uOipUUvU 1MJN0yLXr9PIwvi5Ag0EUfv3swEQAL0+MnxHGrTjSYdfdua4SBpmytDONM1EngeY s+WyaC/760MughKbaysI/nK2LB1vnwEY7f3NM4fxBx8u2T7VBm6Ez6Fs23Bb8Rkz f97bPSdxCmg64GPHfLA9uwTIXcYS+MpI86WOf6eWY0rRpf7Y9Nl7YoUNvzOyUPqc ggdcnHce8zYv7A/WS8flZDm8tVFPsHrQDEwNMws7ZhiNnHkeZeRJrvCuB7oEVich O/ROYoA5o6NozWYQbjxe1f6Yur4Q10qgVcxVnyLFJSbg6vZSzL7KYh3Z5iBOzPHt 7cwEDrW8W4Kl2Qj8rhJ4Wxs94CAtua7IXK44sVZWQbyHcOXRikgGMZKkEZzVCQa5 KD1u1ZrcBCyuMAir0hsmS3jhCUwpiE2c3SRk8O8CgixhTcBk0X/k9ZFu3Hbi1JMB FLzs/Nq3tYAYvVivhPloSxmYBPsafYHCZM83yBNNsralXh5zjB+di90G+AMXt2PN LTcdovZuWtC0s8/jrx+zv/AA4FAGYU9OVl+YL9ybFX8gSdMEcixyzQcKfiFBjpWv 5iFrwIuDlaXMcheyrhc9aGOxfx44OXc505+VjO/1Q/8EOWlJ6UwOi6GMkj5T+RFJ MDyP0UixS7dt6wTuD5t6PRuyWWxZswgrbL9hjwGFr154Z19TWeNWc23pWtUvQJos UCxl2nFHABEBAAGJBD4EGAECAAkFAlH797MCGy4CKQkQhN8ffmrgNkTBXSAEGQEC AAYFAlH797MACgkQJEPd69lQ0evA+Q/+M7lSFlrQWiRsFqDjh+kTJc+0OEBCvnfo N2KPyXXbfc//qup55PfEygE6C60zvrlv3WE33GZ5GS5MLuDMP82b+a5Yt16NQU7L WtAg1g0S0BvazW+28TgnfO8bhbGaFeE9ccw3xLmlbwZQ3f3LtMKdwFIROiG6hvAs 9U54QYti3tv9DowRYYWpdr0Ga8RqeGNtCKc0v2opy51MpzKWjwUW0i3XlSlyY8Lj 1KT8PyznNPw32nYpmDizz+0OUJNnn/kT+GnFoR3DJnFosTOrnxFJp+N+nejMp/gW r9NM0/E7H+P53IiytBOt5/0vsOaCFGdYGhKEjmJi3dHS4Xk1ObD1mjdD1YDOlWWU 3Md6BDHd4W7Q8gT7oQfTIMLd3HzV+WNPIdocPLBaeA/tRD8Pg5CCmncAmSub4F5T An7FlnACtSOv3cIWQ0TymS42DihDaJ5d1RvNzKw+zHYdPvf471JFZR3TDhkPbLIr 9czR7kbpnXRwchgwXQn306NVWf37TgA8wpbnFTazZ38iOeqcb9oKprqnbgEdr3PN OhKSlMTkzAqf3MEi2Fyua4BADMhS3oBwCRgDTlt6wquEytpNSlZaHnyiyIgOpekF Uy5K3w8NhHqeifRPrNb/UcCbXtXz+puqIEZHMenpv6FRlTTKpdoHoVXSkp1TPMGN /VaCiLbP4Z3xEw/9EbAJJkhmmx1Qw3ueoqc4h1MmhUtIdxSZ/oA9SjwlnY++zvaZ 6w1wTS4P+OUkETNDtItdpxXMJ9qfSy9voAQc2K43WMZCCmpPJYSdqaZZNPFj+Ne8 6FNtNKuUkXREybpHwlVAXnHzInmFOOM9RAmF70r3zEmKt77W1ztBLo2o9X79gPgL u9ThgrH6Oc2k46n+9nc3joccr7miiX/bp976DNWcWdOYThiSSOCb8Zw9/Zs935i1 wUVkYTj24tmBH4H5ov9ib7RPmU21ru458RbUKG0ONAqBtAHNyXHzUnXsrke+D4VW MI06YcXSk8YeYgQ8GxgHQc+W2bb8LIbKN1hEYJ0wzM62vKR2/Oiwuf8lXutIKTuz +v7Vj1PQd66DGHsxtWRaWnr1c54JTL2wICHJYKFH4grp7864+GL/uQ1O/Z/XxVku E1JQ/AnwBGU1M1S6otwWGWVRjzEzQtxsfcCEPvV/9td3FIFQAbGTPb+48XFU+TY9 8AlcXBlDzXq7c5f8Evn/oSIsZDt63K4HNTmMGqOTl/p1aA0e4eyX76LczY06rDP5 GMSNs+AHmYgZiS4RYhRUIvS9uLXMnnDAMYst0SDl2orDUUeHBTzu0rchyknBZMGP p5wQuWQ9CFlV+dj3UYbrBwC1lTkAMXRG2vlhA0V0TZqos7A5D4VHgSUQQjE= =otlL - -END PGP PUBLIC KEY BLOCK- -BEGIN PGP SIGNATURE- Version: APG v1.1.1 iQJcBAEBCgBGBQJTRETVPxxlbHJpcHBvIChrZWVwIHlvdXIgZGF0YSBlbmNyeXB0 ZWQpIDxlbHJpcHBvQGVscmlwcG9pc2xhbmQubmV0PgAKCRAkQ93r2VDR6+hfD/9G Cv5a7LceQ+NSJmD2/GmGEbFYaF9NBgIxeHP2XBNbhM+HoAaA3qNFFnw37A83RSeR BvBAMtbOBG57prDOZsGvCFIa1mmr5+Z7JdOUnCxiadW6SU3/qbNZmO8d87xHtvys
Re: [tor-relays] 1.0.1e-2+deb7u5 should be good for Wheezy
Hey Guido. Am 08.04.2014 20:07, schrieb Guido Witmond: According to the debian security announcement it has been fixed at *u5*. Where did you get *u6*? A QUANTUM INSERT? Or a typo? Debian released another update that - unlike the previous version - also prompts you to restart affected services. See https://lwn.net/Articles/593824/ Regards felix ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hy community :( It seems, that we are seriously f# since 14 MAR 2012 with the release of the openssl 1.0.1 branch until yesterday!!! Affected services which used these libraries are enormous. ftps, https, imaps, smtp over ssl, xmpp, and so on, and so on. It makes me really feel sad and angry that all efforts to stay secured, especially over TOR, on encryptions were compromised by such a programing mistake that caused this zerodayexploit. My users and me are virtually crying our hearts out... Good night, over and out, elrippo. On 08. April 2014 06:11:01 MESZ, Moritz Bartl mor...@torservers.net wrote: https://blog.torproject.org/blog/openssl-bug-cve-2014-0160 A new OpenSSL vulnerability on 1.0.1 through 1.0.1f is out today, which can be used to reveal memory to a connected client or server. If you're using an older OpenSSL version, you're safe. Note that this bug affects way more programs than just Tor — expect everybody who runs an https webserver to be scrambling today. If you need strong anonymity or privacy on the Internet, you might want to stay away from the Internet entirely for the next few days while things settle. Here are our first thoughts on what Tor components are affected: 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. 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 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. Hidden services: Tor hidden services might leak their long-term hidden service identity keys to their guard relays. Like the last big OpenSSL bug, 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. 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. Tails is still tracking Debian oldstable, so it should not be affected by this bug. Orbot looks vulnerable; we'll try to publish more details here soon. 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. -- Moritz Bartl https://www.torservers.net/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays - -- We don't bubble you, we don't spoof you ;) Keep your data encrypted! Log you soon, your Admin elri...@elrippoisland.net Encrypted messages are welcome. 0x84DF1F7E6AE03644 - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.4.11 (GNU/Linux) mQINBFH797MBEAC0Y0NeI7lmDR9szTEcWuHuRe0r/WjSRC0Nr5nXsghuMcxpJ3Dd BOBimi4hdMMK4iqPVMwNw6GpKYR3A9LHHjbYRXHUKrJmB+BaJVyzJXN5H6XvxTTb UfX+DaXAGJW/G+3cBB3qm/QaU8QGkBKfXq0DLTaTGPkGKxEAldj/8onGZhawdJs+ B92JrW+S2HDh15pIuXzSqe7eCcIOdvvwfWe0fJi2AraA7LYGpxP6GcC/b9JJpbq5 Y6DfE2Aun9ZK3iHqURyrms0Whbv1CgmUahL2MVYCsTsXwe0GwlAxxKvjXAiXuo+R 9wO5wsXvVVSVNqsk9Yqi+wYzdPKndTU0GyxSApQHroF+cxaZ8Lk0xloj18+LdCSs e5IiTSXH0MMsDdWWdHlrgk+bgDG+0Gu3ne4vMwGdKO7AhYgQW/ueMy4RnkG/nsV9 jry5BO4gGAI1Ij8KvqUzEnvJFGE3ptJogU+zazWWDUWmL3ecKb3aDRlJFnZ3kJ5h q8GolZVjpk99V+4B5WVRPXdej/p5J19tXycK/jdNmr4oC8NyUhIpe8xHELnfoB4z +rxiTx+KMnW0rY8EQg8O2ixEYt5my90IwQkxcxIxextVrqjJjYn8extc2/v8yGzI
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
On Tue, Apr 8, 2014 at 4:34 PM, Roger Dingledine a...@mit.edu wrote: On Tue, Apr 08, 2014 at 04:35:39PM +0100, mick wrote: Moritz Bartl mor...@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. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
On Tue, Apr 8, 2014 at 4:04 PM, Roger Dingledine a...@mit.edu wrote: Actually, I'd like us to take this opportunity to throw out the Named and Unnamed flags entirely. I think we've done pretty well at teaching users to use $fingerprints rather than nicknames in the few cases where they actually want to specify a particular relay. And only two-ish directory authorities still track and vote about Named Second the idea of completely tossing names internally in favor of fingerprints. It would be great to have somebody think through the implications of what exactly we'll lose by dropping them, so we can make a more informed decision. Maybe that could be one of you? :) I've felt the real benefit of nicknames has always and only been in operator participation (woot, other than dns and http on my OR IP, I can feel good by having this short name string), and moniker recognition (hey, look at this metrics widget, I can search/spot all kinds of human readable cool nodes... maybe I'll run one or keep running mine, etc). Nicknames, 'contact' and the like could be merged into new a formally structured user metadata descriptor field. Some fields of which might be used by applications such as onionoo to populate other empty fields. ie: 'udata nickname[16char]: email[32char]: uri[32char]: blurb[up to remaining n char limit]' ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] What fraction of the tor network by consensus weight are the openssl-vulnerable relays?
Making a separate thread so as not to pollute the challenger[1] one. Roger: you wanted to know (times are UTC if anyone cares), [22:08:35] [...] we now have a list of 1000 fingerprints, and we could pretend those are in the challenge and use our graphing/etc plans on them [22:08:45] they happen to be the relays vulnerable to our openssl bug [22:11:43] what fraction of the tor network by consensus weight are they? [22:11:49] over time Given them[2], the challenger (with minimal changes to fix downloader and to make Onionoo not falter)[4] will spit out the following results: - http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-bandwidth.json - http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-weights.json - http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-clients.json[uh oh, this one's empty. Why is it empty? Didn't look into it.] - http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-uptime.json The 'combined-weights.json' is probably the one you might be after. But that's all I did for now. You also said that these aren't all the vulnerable relays that there are out there. You linked to a more complete list[3], but it has some typos, etc. I haven't done anything with it, maybe someone will take over, or I will do something later on. [1]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004214.html [2]: http://ravinesmp.com/volatile/challenger-stuff/vuln_fingerprints.txt [3]: http://freehaven.net/~arma/vulnerable-keys-2014-04-08b [4]: commits: - https://github.com/wfn/challenger/commit/38d88bcb1136f97881f81152d3d883c4e9480188 - https://github.com/wfn/challenger/commit/39c800643c040474402fc62d2a2db75c25889dfc - https://github.com/wfn/challenger/commit/7425ef6fc00dedf3b2b7f2649e832fb4c93909ae -- kostas / wfn 0x0e5dce45 @ pgp.mit.edu ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Metrics for assessing EFF's Tor relay challenge?
Hi Kostas, right now, we're coding challenger against what exists in debian wheezy, which means version 0.1.2 of the requests lib using the python-requests package you mentioned, where response.json is correct, and not response.json() to get json content from the response. I'd recommend that if you want to make your own grab stuff from onionoo script suite, to work with onion-py[1] . It's very new, very spiffy and uses python 3 and the newest requests lib. (full disclosure: It's my baby and I'm desperately looking for testers/users, but that should be obvious to anyone who read this thread.) Alternatively, convince the right people (presumably Karsten and arma) that challenger should switch to a more sustainable runtime than what we can get from wheezy's repositories. ;-) Cheers, Luke [1] https://github.com/duk3luk3/onion-py signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] What fraction of the tor network by consensus weight are the openssl-vulnerable relays?
On Wed, Apr 9, 2014 at 3:49 AM, Kostas Jakeliunas kos...@jakeliunas.comwrote: Making a separate thread so as not to pollute the challenger[1] one. Roger: you wanted to know (times are UTC if anyone cares), [22:08:35] [...] we now have a list of 1000 fingerprints, and we could pretend those are in the challenge and use our graphing/etc plans on them [22:08:45] they happen to be the relays vulnerable to our openssl bug [22:11:43] what fraction of the tor network by consensus weight are they? [22:11:49] over time Given them[2], the challenger (with minimal changes to fix downloader and to make Onionoo not falter)[4] will spit out the following results: - http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-bandwidth.json - http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-weights.json - http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-clients.json [uh oh, this one's empty. Why is it empty? Didn't look into it.] - http://ravinesmp.com/volatile/challenger-stuff/vuln1024-combined-uptime.json The 'combined-weights.json' is probably the one you might be after. But that's all I did for now. You also said that these aren't all the vulnerable relays that there are out there. You linked to a more complete list[3], but it has some typos, etc. I haven't done anything with it, maybe someone will take over, or I will do something later on. fwiw, I ran the script for the larger batch of vulnerable relay fingerprints available[5], and these are the resulting files: - http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-bandwidth.json - http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-weights.json - http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-clients.json [empty] - http://ravinesmp.com/volatile/challenger-stuff/vuln1648-combined-uptime.json The whole thing (with the sleep delays included) took ~84 minutes to run. (It may be that Onionoo doesn't know (at least not in a way that allows it to provide the relevant info here) about the majority of those fingerprints (?), so not sure if this is useful much, but it can't hurt.) Okay, I'm probably done running and patching code I'm not familiar with for the time being. :) [1]: https://lists.torproject.org/pipermail/tor-relays/2014-April/004214.html [2]: http://ravinesmp.com/volatile/challenger-stuff/vuln_fingerprints.txt [3]: http://freehaven.net/~arma/vulnerable-keys-2014-04-08b [4]: commits: - https://github.com/wfn/challenger/commit/38d88bcb1136f97881f81152d3d883c4e9480188 - https://github.com/wfn/challenger/commit/39c800643c040474402fc62d2a2db75c25889dfc - https://github.com/wfn/challenger/commit/7425ef6fc00dedf3b2b7f2649e832fb4c93909ae [5]: fingerprints ready for challenger: http://ravinesmp.com/volatile/challenger-stuff/1648_vuln_fingerprints.txt -- Kostas. 0x0e5dce45 @ pgp.mit.edu ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
