- tor-relays - lists.torproject.org

Heartbleed: Exchange of keys now or later?
by Paul Görgen 08 Apr '14

08 Apr '14

Hi all, the discussion during the last days was inconclusive to me: Should everyone who was using a vulnerable openssl exchange their keys right now/right after the update, or should we wait for some random amount of time as to not lose all the guard relays at the same time? My guard relay went up in traffic by 50-100% since monday and I guess that is a sign that already now there is a lack of guard relays. Also I am not sure about the risks, given that probably the number of middle and exit nodes with safe keys is rising. ~Paul

1 0

Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
by Jesse Victors 08 Apr '14

08 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I've updated OpenSSL, deleted the keys on my exit per the recommendations, and restarted the whole box. I got a new fingerprint. I'll watch to see how long the flags take to come back, but I predict it will be like a new relay. I wonder how this changes the flow rates across the Tor network. Perhaps adversary-controlled exits may not be upgraded so that they can keep their percentage advantages and take advantage of the disruption. In due time things will come back to normal. I'd recommend that every relay operator delete their keys as well, just to be safe. Pure speculation on my part here, but a well-resourced adversary might have seized the moment and done some attacking, or perhaps they knew about it beforehand. This is a major vulnerability. Admins are revoking SSL certificates, and that's for web servers. The blog post is very helpful for outlining how this exploit affects us, but let's assume the worst here. While we're updating, how about we all make sure we are running the 0.2.4 series of Tor, preferably 0.2.4.21. Switch to the Tor Project's repositories if you haven't already. Good luck guys. Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCgBmBQJTRKL/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAsk4H/RezKq0rEPbdbk9HG3Wjz0rE wUWBfGh3J4oultac256USLXHBHdyWnp8sT73ZhHm9H9i+ja/OjGpEwvXFIzIW09j cLMSZTf3AwTIeA8PO3S3qZsuNUwMC6kz5XhyFeRbuaBjD93Dr29Q4/zehGtPU02j 4CEqFqegjxXWL6WoKt2JyhOaV2meEz5d2GN/F6oguzk3orwX8FWc5jOewvNcRknv stFaz17JBrzqHUQY1NDx29Dw81dO5H4+sTzM+DRvTSSLKx8R1Zbw5ApevNkoWTFg ldhv/v/pHR1UnB9gsQ+r61BK3OQIWzAaVXgeZh3PDtkfX7yg1LnrdNZ2+NhUi6w= =eBTS -----END PGP SIGNATURE-----

2 1

Re: [tor-relays] Metrics for assessing EFF's Tor relay challenge?
by Karsten Loesing 08 Apr '14

08 Apr '14

Christian, Lukas, everyone, I learned today that we should have something working in a week or two. That's why I started hacking on this today and produced some code: https://github.com/kloesing/challenger Here are a few things I could use help with: - Anybody want to help turning this script into a web app, possibly using Flask? See the first next step in README.md. - Lukas, you announced OnionPy on tor-dev@ the other day. Want to look into the "Add local cache for ..." bullet points under "Next steps"? Is this something OnionPy could support? Want to write the glue code? - Christian, want to help write the graphing code that visualizes the `combined-*.json` files produced by that tool? The README.md suggests a few possible graphs. Thanks in advance! You're all helping grow the Tor network! Also replying to Christian's mail inline. On 28/03/14 09:07, Christian wrote: > On 27.03.2014 16:25, Karsten Loesing wrote: >> On 27/03/14 11:57, Roger Dingledine wrote: >>> Hi Christian, other tor relay fans, >>> >>> I'm looking for some volunteers, hopefully including Christian, to work >>> on metrics and visualization of impact from new relays. >>> >>> We're working with EFF to do another "Tor relay challenge" [*], to both >>> help raise awareness of the value of Tor, and encourage many people to >>> run relays -- probably non-exit relays for the most part, since that's >>> the easiest for normal volunteers to step up and do. >>> >>> You can read about the first round from several years ago here: >>> https://www.eff.org/torchallenge >>> >>> To make it succeed, the challenge for us here is to figure out what to >>> measure to track progress, and then measure it and graph it for everybody. >>> >>> I'm figuring that like last time, EFF will collect a list of fingerprints >>> of relays that signed up "because of the challenge". >>> >>> One of the main pushes we're aiming for this year is longevity: it's >>> easy to sign up a relay for two weeks and then stop. We want to emphasize >>> consistency and encourage having the relays up for many months. > > Do you want the challenge application to simply provide some graphs or > give some sort of interactive dashboard (clientside JavaScript)? You asked Roger, and I'm not Roger, but I'd say let's start with some graphs. We can always make it more interactive later. Though I doubt it will be necessary. >> Before going through your list of things we'd want to track below, let's >> first talk about our options to turn a list of fingerprints into fancy >> graphs: >> >> 1. Write a new metrics-web module and put graphs on the metrics >> website. This means parsing relay descriptors and storing certain >> per-relay statistics for all relays. That gives us maximum flexibility >> in the kinds of statistics, but is also most expensive in terms of >> developer hours. I don't want to do this. >> >> 2. Extend Globe to show details pages for multiple relays. This >> requires us to move to the server-based Globe-node, because the poor >> browser shouldn't download graph data for all relays, but the server >> should return a single graph for all relays. It's also unclear if the >> new graphs will be of general interest for Globe users, and if the rest >> of the Globe details will be confusing to people interested in the relay >> challenge. Probably not a great idea, but I'm not sure. >> > > I agree that Globe isn't the best place to display the challenge graphs. > Currently the only focus for Globe is to provide data for single relays > and bridges. > Imo it would be better if the challenge participants list adds links to > atlas, blutmagie and globe. Agreed! >> 3. Extend Onionoo to return aggregate graph data for a given set of >> fingerprints. Seems useful. But has the big disadvantage that Onionoo >> would suddenly have to create responses dynamically. I'm worried about >> creating a new performance bottleneck there, and this is certainly not >> possible with poor overloaded yatei. >> >> 4. Write a new little tool that fetches Onionoo documents once (or >> twice) per day for all relays participating in the relay challenge and >> that produces graph data. That new tool could probably re-use some >> Compass code for the backend and some Globe code for the frontend. >> Graphs could be integrated directly into EFF's website. This is >> currently my favorite approach. >> > > I like this idea. Glad to hear! I slightly moved away from the "fetches once or twice per day" idea to a more elaborate approach. But the general idea is still the same. >> Note for 2--4: Onionoo currently only gives out data for relays that >> have been running in the past 7 days. I'd have to extend it to give out >> all data for a list of fingerprints, regardless of when relays were >> running the last time. That's 2--3 days of coding and testing for me. >> It's also potentially creating a bottleneck, so we should first have a >> replacement for yatei. >> >>> So what are the things we'd want to track? >>> >>> - Number of relays signed up that are Running, over time. >> >> We can do something here with Onionoo's new uptime documents. >> >>> - Total bandwidth history of these running relays, over time. >> >> We can sum up data from bandwidth documents for this. >> >>> - Maybe a graph showing the total number of bytes ever contributed >>> by these relays? That would impress people perhaps. >> >> Sure, same data as above. >> >>> - Total consensus weight of these running relays, over time. >> >> We only have total consensus weight *fraction*, but yes. >> >>> - Something emphasizing duration -- e.g. the total consensus weight of >>> the subset of the relays that have been in the consensus for 90% of >>> the past month, 2 months, 6 months, etc. Are there better ideas here >>> I hope? We'll want to be cognizant that if we're in the first week >>> of the challenge, the 2 month graph will be empty and thus look sad. >> >> Not sure what the 90% part is for, but yes, graphs with total consensus >> weight fraction are doable. >> >> Regarding the sad-looking 2 month graph, we can easily define the data >> when the challenge starts and not show graphs until they make sense. >> Note that the current intervals for most data are 1 week, 1 month, 3 >> months, 1 year, and 5 years. >> >>> - Something comparing the above numbers to the total numbers. Given how >>> huge some of the relays are lately, it would be easily to visualize >>> the new contribution as a tiny irrelevant fraction, which could be >>> disheartening to new relay operators even if their relays will actually >>> become a big deal with some patience. What are some strategies for >>> making this work right? E.g. a layer graph showing y layered on top of >>> x where y is the new contribution, rather than a percentage-of-total >>> graph that shows approximately 0%. >> >> Absolute contributions to consensus weight are not available, just >> relative fractions. >> >>> We could also imagine more niche categories. For example, if we're hoping >>> to get people to sign up relays at universities, we could imagine that >>> the folks running the challenge give us a list of fingerprints of relays >>> that self-identify as being at universities, and then we do up the same >>> set of graphs with that subset of relays. >> >> Sure, that's doable. >> >>> So, Christian, others, how much of this is possible as-is or with some >>> limited tweaking, with Globe and related scripts? >>> is most of it. :) I also cc Karsten because a lot of this overlaps with >>> the metrics scripts, but I am expecting Karsten to push back against >>> the idea of integrating these measurements more with the metrics project. >> >> Right, adding this to the metrics website is not a good idea, because >> then we'd have to parse raw relay descriptors. >> >> Somebody else to include here is Sreenatha who has done a pretty good >> job processing Onionoo data for the t-shirt yes/no ticket #9889. >> >>> Any other ideas for what to measure to help people know whether their >>> contribution is being worthwhile? >> >> Not yet, but new ideas may arise when we start working on the code. >> >>> [*] Please don't take this mail as any official announcement, or timeline, >>> or any of that. At this point we need to collect people to help make >>> this happen, not collect news stories. >> >> What's the timeline for this? This requires some non-trivial coding >> time, and I'm not sure how to prioritize this over existing things on my >> todo list. >> >> All the best, >> Karsten (Found nothing else to comment on.) Thanks! All the best, Karsten

5 17

URGENT: active OpenSSL "Heartbleed" attack on Tor Nodes
by starlight.2014q2＠binnacle.cx 08 Apr '14

08 Apr '14

Have been running Tor relay with AddressSanitizer and it crashed this morning. I thought it was related to the system being close to running out of free memory until I read about the new OpenSSL vulnerability. Anyone running a Tor relay with OpenSSL 1.0.1 should update the library or rebuild against an older version immediately!!!!

2 1

Tor download signatures
by Tora Tora Tora 05 Apr '14

05 Apr '14

OK, perhaps I have missed "the how" and "which" somewhere, but which signature am I supposed to verify the new Tor 0.2.5.3 tarball against? I tried the ones mentioned on Tor signing page and none seem to stick. A typical message is: # gpg --verify tor-0.2.5.3-alpha.tar.gz{.asc,} gpg: Signature made Sun 23 Mar 2014 02:40:49 AM UTC using RSA key ID 8D29319A gpg: Good signature from "Nick Mathewson <nickm(a)alum.mit.edu>" gpg: aka "Nick Mathewson <nickm(a)wangafu.net>" gpg: aka "Nick Mathewson <nickm(a)freehaven.net>" gpg: aka "[jpeg image of size 3369]" gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: B35B F85B F194 89D0 4E28 C33C 2119 4EBB 1657 33EA Subkey fingerprint: EF00 F369 1387 FCC5 8CD6 8E13 9103 97D8 8D29 319A

3 2

Rapid multiple connections from same relay or client on data port
by Tora Tora Tora 04 Apr '14

04 Apr '14

I am running a latest 0.2.5.3-alpha Tor build. This time I am observing multiple connections within one minute established on a data port from the same address (not sure if client or relay). The latest flood of connections comes from One World Labs who claim to be a computer security company that also searches for leaked/stolen company information in the "dark Internet" or something along those lines. It seems to me that, since the circuits are connected randomly, the likelihood of the same relay having multiple connections to my single relay within such a short period of time is low. I think someone already pointed out earlier that some clients used to start a number of circuits before they needed them. I guess if such "broken" client chooses my relay as an entry point, I can imagine they might start many circuits fast. But then 0.2.5.3 release notes claimed improvements in DOS protection. >From a practical point, is there a rule at what point I should consider rapid multiple connections from the same address to my relay's directory/data port a DOS attack and take some measures?

1 0

Relay Hibernation and Wake Up Questions
by Nik 04 Apr '14

04 Apr '14

Hello, I'm somewhat new to running relays and have a couple separate but related questions about the hibernation and waking up process. 1) I have AccountingMax and AccountingStart set (to '1850 GB' and 'month 3 15:00', respectively). Yesterday, the last day of the accounting period, my relay went into hibernation at around 7:00. I started running this relay just last month, however, and it had only used approximately 440 GB of the AccountingMax quota. Tor then tried to wake up at 15:00. Is it expected behavior with Accounting{Max,Start} to hibernate on the last/first day of the period even if you're under quota? 2) I have the relay configured to run on port 443. When Tor woke up, it was unable to bind to 443, and so the relay stayed down. Again, is this known/expected behavior that if a relay is set to run on a privileged port it needs human/root intervention to re-bind after hibernation? By the way, I'm running Debian Stable and using the system packages, so I have (I'm assuming) an old-ish version of Tor (2.3.25). Sorry if this has been answered elsewhere before. Thanks, Nik

1 0

WorldHostingDays: Let's plan for this for next year!
by Moritz Bartl 03 Apr '14

03 Apr '14

Hrm. We just missed the WorldHostingDays: "WHD.global is the largest hosting event worldwide with over 4,800 attendees in 2013 from all over the world." http://www.worldhostingdays.com/ We should plan ahead for next year and go there, at least to distribute Torservers info material in front of the entrance. It's in Europa-Park, Rust, near Strasbourg: https://maps.google.com/maps?q=europa-park,rust A ticket is 350€, too much for us if you ask me. Maybe we can find an ISP that gets free registration codes and doesn't use them? -- Moritz Bartl https://www.torservers.net/

1 0

TTTT
by Sebastian Urbach 01 Apr '14

01 Apr '14

Dear list members, It will take a bit longer than expected to bring the scoreboard and surrounding systems up again. As it turns out one system was compromised and another machine ran in some hardware trouble. We need to change settings and possible buy new hardware as well. We are working as fast as possible to get everything back on track, so please stay with us. Sorry for the interruption. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ---------------------------------------------- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. ---------------------------------------------- Benjamin Franklin (1706 - 1790), Inventor, journalist, printer, diplomat and statesman

3 2

Lots of tor relays send out sequential IP IDs; please fix that!
by Jann Horn 01 Apr '14

01 Apr '14

Well, the subject line pretty much says it all: Lots of Tor relays send out globally sequential IP IDs, which, as far as I know, allows a remote party to measure how fast the relay is sending out IP packets with high precision, possibly making statistical attacks possible that could e.g. pinpoint the entry guard a user or hidden service uses. This is how you can test whether a given relay has this issue: $ sudo hping3 -r --syn -p 443 176.199.74.186 --count 10 HPING 176.199.74.186 (eth0 176.199.74.186): S set, 40 headers + 0 data bytes len=46 ip=176.199.74.186 ttl=116 DF id=3025 sport=443 flags=SA seq=0 win=8192 rtt=33.5 ms len=46 ip=176.199.74.186 ttl=116 DF id=+38 sport=443 flags=SA seq=1 win=8192 rtt=32.7 ms len=46 ip=176.199.74.186 ttl=116 DF id=+42 sport=443 flags=SA seq=2 win=8192 rtt=32.5 ms len=46 ip=176.199.74.186 ttl=116 DF id=+34 sport=443 flags=SA seq=3 win=8192 rtt=32.3 ms len=46 ip=176.199.74.186 ttl=116 DF id=+36 sport=443 flags=SA seq=4 win=8192 rtt=33.2 ms len=46 ip=176.199.74.186 ttl=116 DF id=+36 sport=443 flags=SA seq=5 win=8192 rtt=36.4 ms len=46 ip=176.199.74.186 ttl=116 DF id=+35 sport=443 flags=SA seq=6 win=8192 rtt=33.9 ms len=46 ip=176.199.74.186 ttl=116 DF id=+56 sport=443 flags=SA seq=7 win=8192 rtt=31.7 ms len=46 ip=176.199.74.186 ttl=116 DF id=+46 sport=443 flags=SA seq=8 win=8192 rtt=33.4 ms len=46 ip=176.199.74.186 ttl=116 DF id=+34 sport=443 flags=SA seq=9 win=8192 rtt=33.7 ms In the last example, you can see that the "id" field has increased by 30-50 every second. That's an issue: It should be one of: - always 0 - totally random It can also be that it increments by one every time; that probably means that the relay uses per-IP counters or so, and as far as I know, that should be fine. After a bit of testing, I think that this issue is present on a lot of Tor relay nodes. Here are the first few in the alphabet that look suspicious (didn't want to scan the whole Tor network): 0000MiddlemanWV 65.199.52.129 9029 21948 +1 +3 +1 +8 000AAA420 86.56.139.182 9001 14461 +177 +176 +168 +145 0urHomeOnNativeLand 64.231.156.165 443 18012 +4 +16 +11 +12 0x05942 178.77.69.130 443 8387 +5 +6 +7 +4 1234bubs 2.108.151.161 443 17042 +19 +23 +22 +18 1294538115 86.195.35.119 50501 31861 +104 +116 +68 +114 2mpdhack 98.216.168.108 80 41481 +194 +162 +213 +174 404server 119.30.250.67 6699 53620 +195 +5 +1 +3 4144414D 2.120.211.98 443 28587 +1 +1 +1 +1 594ec291a82938230 199.127.56.76 49152 20690 +861 +893 +328 +338 5979ft 97.122.184.135 443 15586 +1 +1 +1 +1 69m3x1xans 98.219.70.159 443 63 +320 +286 953 +286 6cody5 76.108.230.244 443 28107 +59 +57 +73 +71 8930 71.127.151.26 443 3119 +111 +83 +53 +59 8Mu 128.71.234.171 443 19080 +578 +570 +292 +699 Absolution 94.247.41.130 9001 34427 +842 +688 +684 +636 Ace 121.211.92.6 9001 21567 +1 +1 +1 +1 Achim 79.251.152.183 452 8925 +1 +1 +1 +1 admtg 94.73.222.62 443 3025 +441 +286 +318 +286 Aeroplan 46.72.45.143 9001 29676 +166 +184 +189 +169 AetherTor 71.135.40.76 443 13379 +4 +3 +3 +3 alakazam 74.52.112.2 443 30616 +221 +234 +210 +249 aldgate 93.130.179.10 443 10989 +2 +13 +20 +4 AlfredJKwak 87.212.11.165 9031 13676 +22 +14 +2 +8 aliceandbob 66.85.144.247 9001 2869 +20 +7 +23 +30 AllCowsEatGrass 173.48.97.207 443 30159 +404 +783 +616 +401 amercury 195.64.199.236 9001 26102 +1 +1 +3 +1 amercury 87.224.217.221 9001 7043 +26 +6 +15 +13 amercury 94.31.242.41 9001 27049 +41 +33 +88 +81 AmurTor23 2.93.161.46 9002 48802 +4 +115 +14 +34 anonion 86.160.123.126 443 34526 +79 +94 +111 +57 AnonMan 173.69.9.25 443 23551 +24 +33 +43 +51 anonymous 94.208.144.120 9001 24891 +391 +392 26027 +354 anonymous123 117.16.24.142 443 6806 +19 +40 +56 +19 AnonymousW 173.57.117.197 443 9862 +1 +1 +1 +1 AnonymTorProxy2 78.42.56.35 9002 6479 +246 +266 +258 +234 ApophisGER 176.198.48.99 555 6287 +1 +2 +2 +8 ArnoNym 178.142.2.45 443 21741 +83 +112 +57 +32 Arrowslash 90.1.117.14 443 1572 +90 +166 +4 +180 Arruffapopoli 84.223.102.90 4433 56233 +59 +60 +57 +54 AsCI 158.110.41.101 9002 53052 +1 +1 +1 +1 Please, everyone, check whether your Tor relay node behaves this way, and if so, either change the behavior or take it offline until you can fix the issue. Tor is not designed to be secure if an attacker can measure traffic at both ends of a circuit (for a proof of concept for that, see <http://seclists.org/fulldisclosure/2014/Mar/414>), and if your relay has this issue, you're already allowing anyone to measure at your relay.

5 9