- tor-relays - lists.torproject.org

Re: [tor-relays] NSA knew about Heartbleed
by Eric Giannini 12 Apr '14

12 Apr '14

This is an excellent email. ------------------------------ On Fri, Apr 11, 2014 5:32 PM PDT Jesse Victors wrote: > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA512 > > >Saw this article: >http://www.bloomberg.com/news/2014-04-11/nsa-said-to-have-used-heartbleed-b… > >"The U.S. National Security Agency knew for at least two years about a >flaw in the way that many websites send sensitive information, now >dubbed the Heartbleed bug, and regularly used it to gather critical >intelligence, two people familiar with the matter said. The NSA said in >response to a Bloomberg News article that it wasn?t aware of Heartbleed >until the vulnerability was made public by a private security report. >The agency?s reported decision to keep the bug secret in pursuit of >national security interests threatens to renew the rancorous debate over >the role of the government?s top computer experts." > >Thanks NSA, glad you've got our backs there. > >If you run a relay and you have been on one of the affected versions of >OpenSSL, I would urge you to STRONGLY CONSIDER your relay compromised. >Delete your keys per the recommendations and let Tor generate new ones. >It's better to cripple the network temporarily while we come back from >this, rather than preserving the uptime with possibly compromised keys. >Security matters here. Please follow the best practice recommendations. >If you run a web server, rekey your SSL certificates. Basically, if you >were affected, consider encryption to have been bypassed and passwords >and other sensitive information compromised. We cannot afford to take >chances here. If the NSA knew it, you can also bet that someone else >with a good static analyzer discovered it as well, I'll let you imagine one. > >Good luck out there everyone, we really need to revoke our keys if we >were affected. Seriously, guys. It's worth it. > >On a lighter note, https://xkcd.com/1354/ > >Stay safe. Live long and prosper. >Jesse V. > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.4.14 (GNU/Linux) >Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > >iQF8BAEBCgBmBQJTSImHXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w >ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB >RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yA0nIIAKj1lOXRGcwMFd39CxjnymSN >FVzrPUa/JomCJHqW/A0xSFdxbVAZIvio6C1phuWHmiiDKhsBuBGwLNzXQMGFltaw >BnaTO1lLCvvSbEdmXPg12hR3YqR1d5D7Xnb0iTlSfrjZ7gGDEsXoJG3pU/V/RCFo >IOEqxfZtVcI3DdrImlwcR6gPw6ip9JlTo49w8ncy6/K4cHED2liCQ13JvWjaQzSl >uB06eWNsNo1IhPCKkZ7gFzharhN/4kAQrytC+ZcTmIrXdPrsd1lUaVICHWK9AEon >sciDu5lI77srXWwt77YVAKw6Jrls41N3USgvKBSrxZhfBVQlCPOmoXtTHdwbhks= >=pmBQ >-----END PGP SIGNATURE----- > >_______________________________________________ >tor-relays mailing list >tor-relays(a)lists.torproject.org >https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Long-term effect of Heartbleed on Tor
by Tom van der Woerdt 10 Apr '14

10 Apr '14

What's the long-term effect of Heartbleed on Tor? * Should we consider every key that was created before Tuesday a bad key and lower their consensus weight? * Should authorities scan for bad OpenSSL versions and force their weight down to 20? A lot of relays will continue running bad OpenSSL versions which seriously hurts the security of Tor. A month from now the NSA/CGHQ/CIVD/etc may know the private keys of a large chunk of these relays and possibly be able to decode a big chunk of traffic... Tom

6 7

Re: [tor-relays] Strange Problem Browsing Blocked Websites‏
by sssheep 10 Apr '14

10 Apr '14

On Thu, 10 Apr 2014 04:26:27 +0000 (UTC) Enrique Fynn <enriquefynn(a)gmail.com> wrote: > On 10 April 2014 01:01, Tor Relays at brwyatt.net <tor(a)brwyatt.net> > wrote: > > > > If I remember correctly, Firefox has a bug where it won't do DNS > > lookups over a SOCKS proxy. It will, however do DNS lookups through > > an HTTP proxy that supports it, such as Polipo. If you configure > > Polipo to act as an HTTP proxy that forwards to the Tor SOCKS > > proxy, and add Polipo to your Firefox config as an HTTP proxy (you > > can leave Tor's SOCKS proxy entry), this may resolve the issue your > > are seeing, assuming DNS blocking/filtering in your country. > > > > Bryan > > That's not a bug, it's firefox default behavior. To change this: > 1- Go to about:config > 2- Set network.proxy.socks_remote_dns to true > This is set already in TBB which you should be using. It exists for a reason, use it instead of attempting to create your own solution.

1 0

Strange Problem Browsing Blocked Websites‏
by Ferdi GULER 10 Apr '14

10 Apr '14

Hello All, Today I have installed tor on my raspberry pi and also set it up as a relay. I can monitor tor traffic using arm so it means it is working. My SocksPort configuration is 9050, 192.168.1.187:9050 where 192.168.1.187 is internal ip of my raspberry pi.In order to anonymize my browsing traffic on my main windows PC, I configured Firefox to use my raspberry pi as proxy on port 9050. When I visit the page https://check.torproject.org/, it says my configuration is successful and I see different ip address. From that point I assume everything should work properly but if I try to browse web sites that are blocked in my country such as youtube it just does not connect. However if I use VPN I can see those blocked web sites. So could anyone please tell me what is wrong with my configuration? I'm realy confused... Thanks in advance!

4 4

Atlas Entry
by Tor Relay 09 Apr '14

09 Apr '14

My several attempts to update to TBB 3.5.4 (XP)unsuccessfully made Tor exit upon starting, so I fell back to 3.5.3. Atlas shows that my efforts hadn't gone unnoticed; OnionTorte now appears four times w/ my IP address. 0D50D43BAA728D6E0C4EB181AB79E5C1D7036D08 is the correct one but it somehow has my bandwidth as 489 KB when it should be 921.6 KB, reflecting my RelayBandwidthRate. Does anybody have a way of clearing the ghost entries and setting Atlas straight on my bandwidth? Thanks, P -- Dirt kicked to the curb goes into the gutter. Professionals kicked to the curb go into retail.

2 1

Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
by tor＠t-3.net 09 Apr '14

09 Apr '14

On 04/09/2014 04:39 AM, Roger Dingledine wrote:> On Tue, Apr 08, 2014 at 07:31:43PM -0600, Jesse Victors wrote: >> I'd recommend that every relay operator delete their keys as well, > > Not every. Those on OpenSSL 0.9.8, e.g. because they're using Debian > oldstable, were never vulnerable to this bug. I imagine there are some > FreeBSD or the like people out there in a similar boat. And Centos > people, etc. > > --Roger > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > The most up-to-date CentOS was supposedly vulnerable? Same as RedHat. But I don't know how to test for the vulnerability itself so I don't really know. Redhat's emailed warning to update OpenSSL went out yesterday as "Security Advisory - RHSA-2014:0376-1". CentOS' updated OpenSSL was available right away as well, and the CentOS 6.5 boxes pulled it right down in an update. I did have some slightly older CentOS 5 boxes which had a version of SSL that was reportedly not vulnerable. Page heartbleed.com said: How about operating systems? Some operating system distributions that have shipped with potentially vulnerable OpenSSL version: Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4 Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11 CentOS 6.5, OpenSSL 1.0.1e-15 Fedora 18, OpenSSL 1.0.1e-4 OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012) FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013 NetBSD 5.0.2 (OpenSSL 1.0.1e) OpenSUSE 12.2 (OpenSSL 1.0.1c) Operating system distribution with versions that are not vulnerable: Debian Squeeze (oldstable), OpenSSL 0.9.8o-4squeeze14 SUSE Linux Enterprise Server FreeBSD 8.4 - OpenSSL 0.9.8y 5 Feb 2013 FreeBSD 9.2 - OpenSSL 0.9.8y 5 Feb 2013 FreeBSD Ports - OpenSSL 1.0.1g (At 7 Apr 21:46:40 2014 UTC)

2 1

any action required for AWS cloud relays?
by lee colleton 09 Apr '14

09 Apr '14

I have relay(s) running in AWS. Will they auto-update? Do I need to take any action?

3 3

Clarification regardind business as usual
by Sebastian Urbach 09 Apr '14

09 Apr '14

Hi, I want to clarify my mail from earlier today regarding the recovery of the network / relays. I wrote that i expect business as usual within 2-3 days for the vast majority of the relays. That does not mean that everything is the way it was before. When the content of the /keys directory is gone you have basically a new relay and therefore the process of getting flags starts from scratch. Roger posted an excellent article regarding the life cycle of relays: https://blog.torproject.org/blog/lifecycle-of-a-new-relay -- 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

1 0

TTTT
by Sebastian Urbach 09 Apr '14

09 Apr '14

Dear list members, There are also some good News in this in this sad OpenSSL days. The TTTT data collection server is back as well as the Scoreboard. Everybody who has some stored data (or new Volunteers), feel free to remove the parking brakes and start submitting ;-) New Scoreboard URL though: http://hatswitch.ece.illinois.edu/tor-traceroutes/relay_scoreboard.html Project: http://web.engr.illinois.edu/~das17/tor-traceroute_v1.html -- 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

1 0

Re: [tor-relays] Heartbleed" Exchange of keys now or later?
by tor＠t-3.net 09 Apr '14

09 Apr '14

After updating the OpenSSL, I chopped our relay's keys at noon EST yesterday. The traffic has indeed collapsed since then. Old configuration was averaging around 55Mb/s per my Cacti. A URL here: https://atlas.torproject.org/#details/566B0F92197A9D855846E68D2AEEF8266B147… This morning my Cacti graphs say it is still sitting at near nothing, like 1.5Mb. "arm" says between 500-600Kb/s. The new URL is here and at least at this time, you can really see the dropoff in the 3-day graph. https://atlas.torproject.org/#details/30C19B81981F450C402306E2E7CFB6C3F79CB… I wonder how long it will take our relays to recover? I wonder if it is a good idea, or technically feasible, to do a one time kick-over of something in the Tor network so that the system sees what the relay flags etc. should be on these emergency-redefined relays. Certainly if everyone updated at once and the traffic died like this everywhere, Tor would be pretty messed.

3 2

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

09 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 02 Apr '14

02 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

Low traffic on a small relay
by Leandro Noferini 31 Mar '14

31 Mar '14

Ciao a tutti, I have a relay CyberTorValley on a house adsl. I set up this relay to start in night and stop on morning when my adsl is poorly used but the relay makes only a few traffic, say 35-40 mb at night. The poor traffic is due to limited time the relay is up? Is there a way to change the bandwitdth on the run? I found this wiki reference https://trac.torproject.org/projects/tor/wiki/doc/BandwidthLimitChangeContr… in tor web site but it is not linked anywhere. -- Ciao leandro http://6xukrlqedfabdjrb.onion/blog/ gpg fingerprint: 54A4 2612 FD50 0313 7FED 6A91 DA5C 1552 E7A4 D6C2 "Noi di Es Toch narriamo un breve mito: all'inizio il Creatore disse un'immensa bugia. Perché non c'era proprio nulla, ma il Creatore parlò dicendo: Esiste. Ed ecco, affinché la menzogna di Dio potesse essere la verità di Dio, l'universo cominciò subito a esistere..."

1 0

Setting up AWS cloud-relay - don't reserve expensive storage!
by Nick Sheppard 31 Mar '14

31 Mar '14

Hi all, I set up an AWS EC2 cloud Tor relay a month ago and made an expensive mistake. Perhaps others may learn from my example! I followed the instructions on the tor-project website, and found that it actually is quite a simple process, as it says. I did notice that the AWS setup screens I was seeing were different from the screenshots on the website, but they were asking me similar questions so I just went with the defaults where the website said "No changes". I didn't look closely enough. Everything went to plan and I watched the relay work for a month. However, on the AWS EC2 Management console I neglected to click on "Services" then "Billing" to see how much they were charging me. At the end of the month I got a bill for 120 dollars. And Amazon were quite right - they were charging me for the 1024 GB of storage I had accidentally asked for by not changing the default when I set up the instance. The first 30 GB were free, the other 994 I was paying for. And I was only actually using 1.5 GB ... There doesn't seem to be any way of shrinking the storage of an existing instance (though it can be expanded, now, with EBS, Elastic Block Storage), so I had to terminate it (which deletes the storage) and create another instance with a more reasonable 10 GB (of which df tells me I'm now using 11%). So ... if you've recently set up an AWS EC2 cloud relay with the Tor AMI, check your storage, and your billing! I think the option to specify your storage amount (with its default of 1024 GB) may have been introduced when AWS introduce EBS instead of just instance-backed storage (which may have defaulted to the size of the AMI??). In any case, I think the tor-project website AWS screenshots urgently need to be changed to reflect the current setup procedure, with a warning not to accept the 1024 GB default and an explicit recommendation about the amount of storage to ask for (was my guess of 10 GB reasonable?). Oh well, I have gained 100 dollars worth of wisdom from the episode. My way of "Don't look too closely, and hope for the best at the end of the month" was *not* a good idea. Nick Sheppard

7 20

tor relay recommended upgrade procedure?
by Zenaan Harkness 29 Mar '14

29 Mar '14

Currently running Debian's stable/wheezy version of tor which 0.2.3.25 on my first relay, gracemissionstor. I discovered the torproject deb repository here (of course): https://www.torproject.org/docs/debian The following google search: debian upgrade site:torproject.org didn't give much. But the following search: "tor relay" upgrade site:torproject.org gave: https://blog.torproject.org/blog/lifecycle-of-a-new-relay and the FAQ which includes: https://www.torproject.org/docs/faq.html.en#UpgradeOrMove which relates how to keep the same relay id when upgrading. Is there a recommended procedure for upgrading tor relay? Should I upgrade asap now that I've realised torproject has more recent (0.2.4) stable version of tor? Or should I just wait until I have to reboot the server (don't know when that could be) or until a security alert comes around from tor developers? Perhaps I should just rely on the debian package to do the right thing regardless (which for most services is to restart the service, but I guess could be 'do nothing until next reboot' if the packager decided that was wise). Seeking some guidance on this issue thanks, Zenaan

4 7

Mikrotik implementation
by Wolle Brandstätter 28 Mar '14

28 Mar '14

*Dear list members,* *I was thinking about implementing a node on a Mikrotik Router which is located in one of my companies datacenters with an 1Gig Uplink. * *Do you already have some experience in deploying TOR on this kind of routers?I found an interesting tutorial on how to get TOR running on those kind of devices.http://wiki.mikrotik.com/wiki/Use_Metarouter_to_Implement_Tor_Anony… <http://wiki.mikrotik.com/wiki/Use_Metarouter_to_Implement_Tor_Anonymity_Sof…> * *Await your answer.* *Cheers,Wolle*

1 0

2.5.3-alpha packages
by Delton Barnes 28 Mar '14

28 Mar '14

Is the nightly repository currently the Debian repository to use for 2.5.3-alpha packages? I ask because I am looking to move off of nightlies and onto more stable packages once they are available. Am running scramblesuit so need 2.5.x. Thanks, Delton

1 0

TTTT scoreboard
by Sebastian Urbach 28 Mar '14

28 Mar '14

Dear list members, The TTTT scoreboard and the involved systems are in need for some adjustments. Anupam is working on it and we expect that the issues are resolved on this weekend. 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

1 0

Re: [tor-relays] TTTT
by Sebastian Urbach 28 Mar '14

28 Mar '14

Hi Renke, Thanks, we are looking into it asap. On March 28, 2014 2:13:42 PM renke(a)mobtm.com wrote: > Sebastian, > > > http://datarepo.cs.illinois.edu/relay_scoreboard.html > > I believe your updater script for the scoreboard is broken - the values are > unchanged since 2014-03-17 :) > > Renke > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Metrics for assessing EFF's Tor relay challenge?
by Roger Dingledine 28 Mar '14

28 Mar '14

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. So what are the things we'd want to track? - Number of relays signed up that are Running, over time. - Total bandwidth history of these running relays, over time. - Maybe a graph showing the total number of bytes ever contributed by these relays? That would impress people perhaps. - Total consensus weight of these running relays, over time. - 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. - 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%. 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. So, Christian, others, how much of this is possible as-is or with some limited tweaking, with Globe and related scripts? I am hoping the answer 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. Any other ideas for what to measure to help people know whether their contribution is being worthwhile? [*] 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. Thanks! --Roger

3 4

TTTT
by Sebastian Urbach 28 Mar '14

28 Mar '14

Dear list members, The next big data review regarding the "Trying Trusted Tor Traceroutes" project was initiated this week. It will probably take a while (weeks) before we have solid conclusions. We are very close to 100 complete runs from different IP's, in fact 99 right now. I hope that we will reach this goal very soon :-) We are not sure yet if we gathered enough data, but time will tell. We want to thank you for your support and if you want to make sure that we have more data in case the amount we collected turns out to be insufficient, then join us or keep running multiple rounds. Project: http://web.engr.illinois.edu/~das17/tor-traceroute_v1.html Results: http://datarepo.cs.illinois.edu/relay_scoreboard.html I make sure that this list is getting the results from the data review before anyone else. -- 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

4 5

Avoiding sinkholes
by ramo＠goodvikings.com 28 Mar '14

28 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Heya List I currently run a VPS which hosts both my mailserver and my tor relay / exit. Recently I sent an email from this mailserver and had it bounce back. It seems the receiving mailserver subscribes to the spambot list CBL (http://cbl.abuseat.org) and denied it because my IP address was on that list. It's on that list since at some point a botnet talking through tor to its C&C server used my exit node to do so - The C&C server has since been replaced with a sinkhole. That was logged, my server was deemed infected and bam, I'm blacklisted. The site that did the blacklisting kindly has a good description of what happended (including the sinkhole IP address) and allowed an automatic delisting. I'm able to update my exit policy so it doesn't happen again, however I'd like a somewhat more proactive approach. So my question is - Does anyone know of a publicly available list of sinkholes created for botnets? If such a list exists I can dynamically update either my exit policy or firewall appropriately. Has anyone implemented such a system already? (obviosuly this only works for sinkholed botnets - but if anyone knows how to stop all botnets I'm all ears....) Cheers Ramo -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQEcBAEBAgAGBQJTNQpGAAoJEAXQWoW8lug/mdkH/jqK5ndFWbVrRnNV7a8IqgYl 4iiR6TUYLjGEdcz8VDZ+cOkW0uCQkOvD6RWl/kWHKmA4iy7alFgbKE4Lkcg4QgBB 7EgNYww3zBbj1NX5rtRN7POge2n4ns7Y7whw0qbvHXE0ur74iLyy5H3hHZeWoosU g6t9mCsMpEpGAvbkzkDxo+idAdxYe+JiB3iaAAEUDtzeStOG5RJ/qrg8JM+U7ofA bWPehBV8+V8E//4G/XLsePCciBN0071ylg+YoGcxDpM97WHvmQKbi5VU3KfQJFTB AFaQ+7ib1BNhe7KEC7V0Iha6Yu/BTNhDRA/0i1C3pad32HQsfGvep261yq+KBjc= =Wemh -----END PGP SIGNATURE-----

3 3

the obfsproxy bundle, and decrease in number of users to my bridges
by Viking God 27 Mar '14

27 Mar '14

A repost, as I didn't get any answers when I posted in another thread: Where can I download an obfsproxy bridge bundle nowadays? It seams to have disappeared. I use both win and linux(but not debian/ubuntu). I have found dual information pages about setting up obfsproxy+tor in Debian/Ubuntu Here: https://www.torproject.org/projects/obfsproxy-instructions.html.en And here: https://www.torproject.org/projects/obfsproxy-debian-instructions.html.en Why dual instructions for Debian/Ubuntu? But no instructions for other OS:es, and no direct download links with compiled packages/programs here: https://www.torproject.org/dist/ How do you suppose that people will be able to help setting up obfsproxy bridges, when there isn't any way to get instructions or packages/programs? Previously I ran an obfsproxy bridge and saw the amount of traffic get lower and lower, at the end it was only about 2-10 MB of traffic per week and with very few users. Some weeks I go no users so I stopped wasting my electricity and stopped running the obfs-bridge. But now I would like to try again after a couple of months pause. I'm interested to see if the Internet-blocking in Turkey might have caused some more traffic. I also used to run a normal bridge up until a couple of weeks ago but saw the traffic get as low as around 50MB per week, while normally I used to get around 1-2GB per week so I shut it down too. I asked myself: "What's the point of wasting energy and at the same time making it easier to hack into my network, when I'm not even helping the world?". So I shut it down too. Perhaps some changes in the tor network after the release of Tor 0.2.4 has reduced the number of bridge and obfsproxy users globally? Due to the constant flow of bugs in the different tor-related software and bundles, my first guess is that the problem is with changes in Tor plus related software. A look at the bug tracker makes me wonder if there are more things in the Tor related software that do work or don't work??? But perhaps more bridges are blocked nowadays by the filters that various countries apply to the Internet? Or perhaps less countries block their Internet users so less people need to use bridges? Or perhaps a lot of new bridge operators have arisen, making every bridge receive less traffic? My ISP isn't known for blocking anything and I've never heard of any government blocking of Tor in the EU, so the problem is probably not with my ISP nor the EU. I have always been running the latest stable release of the bundles, so It doesn't have anything to do with old versions. So my questions: Where can I find a obfsproxy bridge bundle for rpm-linux and for windows? Is there any good explanation to why the traffic to my normal bridge and my obfsproxy bridge got lower and lower after the release of tor 0.2.4 as stable?

2 1

Tor-Plugin for munin
by Martin Weinelt 27 Mar '14

27 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Everybody likes graphs, right? I tried some of the available munin plugins, but none of those were really working anymore. So I sat down and began writing my own, using stem, which is really awesome. These are really early stages, but it already supports autoconf determination and suggestions. If you want to take a look, it is hosted on github[1]. At the moment it supports a connection graph, getting its data from orconn-status. More graphs are possible, but not yet implemented. Ideas are welcome. Regards, Martin Weinelt [1] https://github.com/mweinelt/munin-tor -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTMhmTAAoJEL1KoFKPY/F+Hs0H/2X3RwoyIMJrAximYeqMTDbN 5w5nOwi+iv0Klr2Pe4bkSIR+OHoTp7lUHFlEGHk7WC/Z6LE0luCHEmQbRS0S9a6o e0gcTczRFfxW/BNLUMeiD0SbKLromdDBJtGFM94Eqr9da/CpiicLG4sBkOwO0k8p 2NF8cBSrwqpLlg+FdA+wIomFUAl4Ph/qKRNN6NALeQqxkLFI1vQxmJarC+y9bV6Q z+g8ccn5jqhaJm4rX0j9/MzSspwtf5yQ+2pD6+QCroXynbMq5AQjU3BTb9VCk9jW eofy3LlP0LnVw9nFBKpGWWNFyYfG/cptrORLwMBfuaHqscYrbAAdcwlu0D4nxwc= =H5tI -----END PGP SIGNATURE-----

2 2

log: Error binding network socket to 203.217.31.172: Cannot assign requested address
by Zenaan Harkness 27 Mar '14

27 Mar '14

>From here: Mar 27 16:50:35.000 [warn] Error binding network socket to 203.217.31.172: Cannot assign requested address to here: Mar 27 23:56:46.000 [warn] Error binding network socket to 203.217.31.172: Cannot assign requested address I got 828 of those messages. Why no socket number, or more information in the logs to debug this? Although it only happened in that time frame above - not happening any more. TIA Zenaan

1 0

Tor relay setup
by eugene zhukovsky 26 Mar '14

26 Mar '14

Hi, I am trying to setup Tor relaying, but it doesn't work so far. Windows 8, private vpn. I opened ports 80,443,9001 and 9030 (both TCP and UDP) on my Comcast router to be forwarded to the box I'm trying to configure. I added inbound and outbound rules in the firewall setup for ports 80,443,9001 and 9030 (both TCP and UDP) but I'm still getting Mar 15 15:30:58.654 [Warning] Your server (62.210.167.197:443) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Mar 15 15:30:58.658 [Warning] Your server (62.210.167.197:9030) has not managed to confirm that its DirPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Please advise, ----------- Best wishes, Gene

5 8

ORPort is unavailable after a couple of minutes of successful self-testing
by Tachkov Sergey 25 Mar '14

25 Mar '14

Hello, We have previously set up and adjusted a non-exit node with the following key parameters: ORPort 443 NoListen ORPort 127.0.0.1:4443 NoAdvertise After upgrading tor up to the latest version (0.2.4.21) we started receiving in log the following: Mar 23 11:53:06.000 [notice] Now checking whether ORPort 1.2.3.4:443 and DirPort 1.2.3.4:9030 are reachable... (this may take up to 20 minutes -- look for log messages indicating success) Mar 23 11:53:07.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent. Mar 23 12:13:06.000 [warn] Your server (1.2.3.4:443) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Mar 23 12:33:06.000 [warn] Your server (1.2.3.4:443) has not managed to confirm that its ORPort is reachable. Please check your firewalls, ports, address, /etc/hosts file, etc. Firewall and the application which redirects traffic to the 4443 port haven't changed. What may be the cause of that?

2 2

Tor Relay Performance
by Sebastian Urbach 25 Mar '14

25 Mar '14

Hi, Everytime i speak with colleagues i wonder that the most performance related options for TOR relays are unknown. I just started to write down what i know and i would be happy if someone else could benefit from that. http://key-server.org -- 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

5 4

Port 8118 Traffic?
by Dennis Crawford 24 Mar '14

24 Mar '14

Hello - I just recently installed a Tor Relay and now I'm seeing a TON of port 8118 denied requests in my log. Mar 21 17:24:51 kendra kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=c8:0a:a9:9e:2f:02:00:90:1a:a2:a0:7e:08:00 SRC=162.211.126.188 DST=72.90.68.179 LEN=48 TOS=0x00 PREC=0x00 TTL=122 ID=16300 DF PROTO=TCP SPT=4853 DPT=8118 WINDOW=65535 RES=0x00 SYN URGP=0 Mar 21 17:24:53 kendra kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=c8:0a:a9:9e:2f:02:00:90:1a:a2:a0:7e:08:00 SRC=162.211.126.227 DST=72.90.68.179 LEN=48 TOS=0x00 PREC=0x00 TTL=122 ID=19011 DF PROTO=TCP SPT=1146 DPT=8118 WINDOW=65535 RES=0x00 SYN URGP=0 Mar 21 17:24:55 kendra kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=c8:0a:a9:9e:2f:02:00:90:1a:a2:a0:7e:08:00 SRC=162.211.126.173 DST=72.90.68.179 LEN=48 TOS=0x00 PREC=0x00 TTL=122 ID=28405 DF PROTO=TCP SPT=3137 DPT=8118 WINDOW=65535 RES=0x00 SYN URGP=0 Mar 21 17:24:57 kendra kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=c8:0a:a9:9e:2f:02:00:90:1a:a2:a0:7e:08:00 SRC=216.245.222.105 DST=72.90.68.179 LEN=52 TOS=0x00 PREC=0x00 TTL=56 ID=24995 DF PROTO=TCP SPT=2998 DPT=8118 WINDOW=65535 RES=0x00 SYN URGP=0 Mar 21 17:24:59 kendra kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=c8:0a:a9:9e:2f:02:00:90:1a:a2:a0:7e:08:00 SRC=162.211.126.180 DST=72.90.68.179 LEN=48 TOS=0x00 PREC=0x00 TTL=122 ID=21683 DF PROTO=TCP SPT=3372 DPT=8118 WINDOW=65535 RES=0x00 SYN URGP=0 Mar 21 17:25:01 kendra kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=c8:0a:a9:9e:2f:02:00:90:1a:a2:a0:7e:08:00 SRC=173.234.116.173 DST=72.90.68.179 LEN=48 TOS=0x00 PREC=0x00 TTL=247 ID=9188 PROTO=TCP SPT=1976 DPT=8118 WINDOW=65535 RES=0x00 SYN URGP=0 I'm not configured at 8118. My config: SocksPort 72.90.68.179:9050 # Bind to this adddress:port too. SocksPolicy accept 72.90.68.176/29 ControlPort 9051 ORPort 9001 DirPort 9030 # what port to advertise for directory connections On my firewall, I'm allowing: TCP_IN: 9030,9001,9050,9051 and TCP_OUT: 9030,9001,9050,9051 Am I doing something wrong? Why am I getting all this 8118 traffic? Any help would be greatly appreciated. Dennis

3 2

Raspberry Pi binary .debs - 0.2.4.21
by Gordon Morehouse 24 Mar '14

24 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hello all, I've finally released[1] signed binary .debs for Tor 0.2.4.21 for Raspberry Pi. All the usual "random dude's binaries" apply, but at least these are signed with my PGP key and distributed with hashes. They're really for temporary Pi testing or convenience, be paranoid and build from source following the procedure alluded to in the project README. Check the Cipollini Project README[2] for more information about the (very nascent) project. Best, - -Gordon M. 1. https://github.com/gordon-morehouse/cipollini/tree/master/raspbian_packages… 2. https://github.com/gordon-morehouse/cipollini -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJTLg/MAAoJED/jpRoe7/ujO+8H/3c3RJzsYEtWq8/BJcwnW0nP awxBU3Lb0iAt9JNOw7zcdtA6WdC6eIHgKYZ0nH7Vwc4+bHn/RGyvLrD4n11pgB2I eKz2ikQXSWb5jqNQD7sCwQeh5drLxH0VMedOtirpMlqyUteKJOMQfbxmDRA5MBtN KXSSsbKxatnnVA/3/9GFO8oLDEfA0IXp5/RN4bjXDqzW9jHJfC7LVRxq8LK3RRif MYTuzNV3e8CQ9+q5fyqgCBPLA7OBIhH+wVKOVwU/RLlyQTRUqtV9b9Fe7CXXj5eZ YgUgZeNVQZ3gBtSuWWuVHGPu+ZKskSvVKu8Gcj71XCnu6LfI+3DyRWmhCXRU5i4= =yTek -----END PGP SIGNATURE-----

4 7

New obfsproxy release: obfsproxy-0.2.7 [bridge operators: please upgrade!]
by George Kadianakis 24 Mar '14

24 Mar '14

Hello, a few days after the release of obfsproxy-0.2.6, we spotted a bug where scramblesuit would basically reject clients if they try to connect a second time after a short amount of time has passed [0]. This is a serious correctness bug and bridge operators are advised to upgrade to obfsproxy-0.2.7 as soon as possible (we want to start suggesting scramblesuit to users and we need to make sure that most bridges have already upgraded by then). You can use git master or pip to upgrade to 0.2.7. We have also notified the obfsproxy Debian maintainers and we should soon have obfsproxy-0.2.7 packages ready (we will send an email to this list when they are ready). Furthermore, obfsproxy-0.2.7 clients now support SOCKS5 (thanks Yawning!) and the changes also include a few performance enhancements for obfs3 and scramblesuit. Please upgrade your bridges. Thanks! PS: We will do yet another obfsproxy release soon-ish (probably in the next 2 weeks) which will include some more scramblesuit improvements and other miscellaneous code changes. Again, we will inform you by sending an email to this list. [0]: https://trac.torproject.org/projects/tor/ticket/11100

8 9

External connections to port 9050
by Greg W 24 Mar '14

24 Mar '14

I turned on some logging on my firewall today to help troubleshoot and issue and noticed a load of connections from external addresses to port 9050 on my exit node. I don't think that should be publicly accessible. Am I wrong about it being publicly accessible and does anyone else see lots of connection attempts on that port? Thanks, Greg

4 7

Why would consensus weight would be declining like this?
by Tora Tora Tora 23 Mar '14

23 Mar '14

Declining dramatically https://atlas.torproject.org/#details/90743CFA1B93295B9334CC0C625D22990AABA… vs https://atlas.torproject.org/#details/CC2F7C6ED12B67CB3882B98213E02DEF2CB82… that is holding steady

2 3

Exiting only port 8333
by Mike Hearn 23 Mar '14

23 Mar '14

I would like to be an exit for port 8333 only. I have configured my relay to do this, but I am not being listed with the relay flag and do not see any traffic exiting my node (at least not using arm). I saw an FAQ that says this is because you have to exit web traffic to get marked as an exit. I do not wish to do this. Is there any way to exit just one port?

4 7

Re: [tor-relays] tor-relays Digest, Vol 38, Issue 27
by Oliver Schönefeld 23 Mar '14

23 Mar '14

Am 22.03.2014 um 21:04 schrieb tor-relays-request(a)lists.torproject.org: > Send tor-relays mailing list submissions to > tor-relays(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > or, via email, send a message with subject or body 'help' to > tor-relays-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-relays-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-relays digest..." > Today's Topics: > > 1. new fingerprint after update (Oliver Sch?nefeld) > 2. Re: new fingerprint after update (Alexander Dietrich) > 3. Re: new fingerprint after update (I) > 4. Re: Relay configuration for FreedomBox (James Valleroy) > 5. Re: new fingerprint after update (Roger Dingledine) > 6. Re: Relay configuration for FreedomBox (Lunar) > 7. Re: Relay configuration for FreedomBox (Lance Hathaway) > > Von: Oliver Schönefeld <oliver.schoenefeld(a)me.com> > Betreff: [tor-relays] new fingerprint after update > Datum: 22 .März 2014 15:26:07 MEZ > An: tor-relays(a)lists.torproject.org > Antwort an: tor-relays(a)lists.torproject.org > > > Hi guys, > > i updated from Tor 0.2.3.25 (relay 266C0CADC79F802C554019887324A57332A1DA70) to Tor 0.2.4.21 yesterday and the relay fingerprint changed to 07E333A3B979C27739096C5B2EE10D7C8E3D8FFD. > > Is there any way to get the new version working with the old fingerprint? > I looked in the manual and tried adding a DirAuthority line in the torrc file, which looks as the following: > DirAuthority 123tor *:9030 FINGERPRINT > > But then Tor doesn't start. > > I also tried writing the old fingerprint in the fingerprint file, but it's changed to the new one everytime i start Tor. > > > So thanks for your help in advance and have a nice weekend everybody! > > Oli > > > > Von: Alexander Dietrich <alexander(a)dietrich.cx> > Betreff: Aw: [tor-relays] new fingerprint after update > Datum: 22 .März 2014 15:47:29 MEZ > An: tor-relays(a)lists.torproject.org > Antwort an: tor-relays(a)lists.torproject.org > > > Is it possible that either the "DataDirectory" setting changed due to the update or the directory content? > yes, because vidalia isn't part of the game anymore - yes i'm a little late with the update :( > Best regards, > Alexander > --- > PGP Key: 0xC55A356B | https://dietrich.cx/pgp > > On 2014-03-22 15:26, Oliver Schönefeld wrote: >> Hi guys, >> i updated from Tor 0.2.3.25 (relay >> 266C0CADC79F802C554019887324A57332A1DA70) to Tor 0.2.4.21 yesterday >> and the relay fingerprint changed to >> 07E333A3B979C27739096C5B2EE10D7C8E3D8FFD. >> Is there any way to get the new version working with the old >> fingerprint? >> I looked in the manual and tried adding a DirAuthority line in the >> torrc file, which looks as the following: >> DirAuthority 123tor *:9030 FINGERPRINT >> But then Tor doesn't start. >> I also tried writing the old fingerprint in the fingerprint file, but >> it's changed to the new one everytime i start Tor. >> So thanks for your help in advance and have a nice weekend everybody! >> Oli >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > > > Von: I <beatthebastards(a)inbox.com> > Betreff: Aw: [tor-relays] new fingerprint after update > Datum: 22 .März 2014 17:58:58 MEZ > An: tor-relays(a)lists.torproject.org > Antwort an: tor-relays(a)lists.torproject.org > > > ...and the t-shirt counter at Atlas.torproject.org resets > there are worse things than that - but thanks for the reminder to claim it ;) > > Von: James Valleroy <james.valleroy(a)gmail.com> > Betreff: Aw: [tor-relays] Relay configuration for FreedomBox > Datum: 22 .März 2014 19:56:12 MEZ > An: tor-relays(a)lists.torproject.org > Antwort an: tor-relays(a)lists.torproject.org > > > On Wed, Mar 19, 2014 at 9:25 AM, Lance Hathaway <qhltx(a)yahoo.com> wrote: >> If you're going to be running these as bridges, it seems to make sense >> to include obfsproxy support, probably with obfs3 and scramblesuit [0] >> enabled right off the bat. > > Thanks for the information. Is it likely that obfs3 and scramblesuit > will be usable in the long-term? Or will they need to be deprecated at > some point like obfs2? > > Also, if obfs3 or scramblesuit were deprecated, but some FreedomBoxes > continued to run those transports, what would be the result? Would the > worst case be that the bridge is no longer usable by some, as in [0]? > > The reason that I'm asking is that FreedomBox is currently working > within Debian "testing" but our target is Debian "stable". Once our > packaged configuration is frozen for the next stable release, it will > be more difficult for us to push changes other than security fixes. > > [0] https://trac.torproject.org/projects/tor/ticket/10314 > > > > > Von: Roger Dingledine <arma(a)mit.edu> > Betreff: Aw: [tor-relays] new fingerprint after update > Datum: 22 .März 2014 19:57:50 MEZ > An: tor-relays(a)lists.torproject.org > Antwort an: tor-relays(a)lists.torproject.org > > > On Sat, Mar 22, 2014 at 03:26:07PM +0100, Oliver Schönefeld wrote: >> i updated from Tor 0.2.3.25 (relay 266C0CADC79F802C554019887324A57332A1DA70) to Tor 0.2.4.21 yesterday and the relay fingerprint changed to 07E333A3B979C27739096C5B2EE10D7C8E3D8FFD. > > https://www.torproject.org/docs/faq#UpgradeOrMove > >> I looked in the manual and tried adding a DirAuthority line in the torrc file, which looks as the following: >> DirAuthority 123tor *:9030 FINGERPRINT >> >> But then Tor doesn't start. > > Yeah, that's not at all what DirAuthority is for. Can you help us > understand what made you think this was a good idea to try, so we can > fix it in the man page? :) > >> I also tried writing the old fingerprint in the fingerprint file, >> but it's changed to the new one everytime i start Tor. > > Hopefully the above faq entry helps. > > Thanks for running a relay! > --Roger > > thank you so much, roger! i copied the old /keys folder and it's working like a charm. i basically ctrl+f'ed "fingerprint" in the stable manual and the DirAuthority property was the only one that made sense, since i don't run a bridge. but i have to admit that i didn't read the NOTE section... shame on my head. thank y'all! > > > > Von: Lunar <lunar(a)torproject.org> > Betreff: Aw: [tor-relays] Relay configuration for FreedomBox > Datum: 22 .März 2014 20:23:49 MEZ > An: tor-relays(a)lists.torproject.org > Antwort an: tor-relays(a)lists.torproject.org > > > James Valleroy: >> The reason that I'm asking is that FreedomBox is currently working >> within Debian "testing" but our target is Debian "stable". Once our >> packaged configuration is frozen for the next stable release, it will >> be more difficult for us to push changes other than security fixes. > > (Debian hat on:) I try to keep Debian backports as up-to-date as possible. > Are official backports out of your set of allowed packages as well? > > -- > Lunar <lunar(a)torproject.org> > > > > Von: Lance Hathaway <qhltx(a)yahoo.com> > Betreff: Aw: [tor-relays] Relay configuration for FreedomBox > Datum: 22 .März 2014 21:03:43 MEZ > An: tor-relays(a)lists.torproject.org > Antwort an: tor-relays(a)lists.torproject.org > > > Signierter PGP Teil > On 22/03/2014 11:56 AM, James Valleroy wrote: > > Thanks for the information. Is it likely that obfs3 and > > scramblesuit will be usable in the long-term? Or will they need to > > be deprecated at some point like obfs2? > > > > Also, if obfs3 or scramblesuit were deprecated, but some > > FreedomBoxes continued to run those transports, what would be the > > result? Would the worst case be that the bridge is no longer usable > > by some, as in [0]? > > > > The reason that I'm asking is that FreedomBox is currently working > > within Debian "testing" but our target is Debian "stable". Once > > our packaged configuration is frozen for the next stable release, > > it will be more difficult for us to push changes other than > > security fixes. > > > > [0] https://trac.torproject.org/projects/tor/ticket/10314 > > I can't speak to whether more pluggable transports will be deprecated > in future, but I'll go out on a limb here and say "probably." The > nature of things ensures that the capabilities of censors continue to > advance. And as they do, new approaches will be found and deployed to > bypass those advancing attempts to block the network. > > When bridges were first deployed, the fact that they weren't all > openly listed in a public directory made them more difficult to block. > Now, most plain bridges are very easy to block. When obfs2 was first > deployed, it was a solid protocol (I have no doubt). These days, China > is actively hunting down and blocking obfs2. There is very little > point to deploying either a plain bridge or an obfs2 pluggable > transport these days, especially on a mass scale. > > On the plus side, obfs3 is still pretty strong, and it's one of the > common pluggable transports right now. Scramblesuit is not live in the > official bundles yet (AFAIK), but it just released and has some pretty > robust-looking defenses against active probing and other attacks. If > you're working on something new to deploy, these should be included, > without a doubt. They may indeed be deprecated in future, and in the > worst case may become unusable or make the bridge more susceptible to > being blocked. But if you go with a plain bridge or obfs2, you're > already in your worst-case scenario. You have nothing to lose and > everything to gain by enabling the newest pluggable transports. > > I would highly recommend adding the Tor package repository to the > FreedomBoxes. As explained in [0], this won't always give you the > latest version of tor, but it will provide security fixes. My hunch is > that it will almost always also be a little fresher than Debian > stable. And given that network censors and network developers are > always going to be in an escalating arms race, enabling new releases > of Tor (and obfsproxy) directly from the project is going to make the > FreedomBox much more useful in the long term. > > -Lance > > [0] https://www.torproject.org/docs/debian > > > > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

"Invalid length on ESTABLISH_RENDEZVOUS."
by Tora Tora Tora 23 Mar '14

23 Mar '14

I am testing 0.2.5.2-alpha for non-exit relay and seeing lots of "Invalid length on ESTABLISH_RENDEZVOUS" errors. Any cause for concern?

2 1

Best price/efficiency ratio
by Trigger Happy 23 Mar '14

23 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi list, I'm running tor-relay (middle) on VPS from statnet.pl (reseller form Hetzner) https://globe.torproject.org/#/relay/C528972A915EEADE37F5B11A7AB7B571C89F46… Now i'm in top 50 of all relays for only 8,3 euro/month i think it's a good deal . Do You know better options ? - -- Trigger Happy jabber: triggerhappy(a)jabber.ccc.de torchat: xruq34bnhbqlkjtn -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTLfftAAoJEEtm9wC9fGLFFJsP/RADCmlr3/8aTUrdefsOEgk8 CeDCQGasCuQ/iPNdJRCpILkiz7s+SM2FBzMLQVpDUiM5A9VD8aLOfnvhNGjKo4eo uaJUc7t1GrDlhDBzd4C7kV5o48hMeqP/61iDFR0eEO3sH5EIheV3io1fEzQc3XmW hGpgRR0SnfS0VDeQp4FhKXtxfiw4Dp7UMgRS9wQbI7TbFhdETkFjn4YvDIi1AfXg 8xH1xMUhfpJo4wa4RY1+UG+aa7X90HbF278QWlUnMdHiOr1VK3dgbRiV5cvYRF1U XZ6Jr+hDBWScn0dxxKWnebCqRIdh2mmn3G2aF9MdZ9WEaNwoNMzd+NAhUQy43vFr M3w3HZ3NJbVHA2WwQRFfVlg675Z4/PI+Uh60SGMHZoTXRVM2AFYQwUk9r4Mwbfwi qU8jj7pa228gwk5HYBgnOQMRFX/mpqe/Ww82qf/c1YispX+6JvevlfOKe2BF5X0t 66XIMNPJ+639h70XOcFJJyoe/mvbw21N0FZoShrFjAnoIDXyZek5LY1rGkdm4g5j 6w4F6RMQkEuK61eSFTC1lPhpUrUwkkCrBoU+Gg0rAFiqSYytT/rvSgtdlfbhcOlu SoMPY8rR6sG6b6Ib1YumiMXNc+fpT+9QbBxoaVxbORyLtvvb78dH8PcpQdwj79KK 9M0CeGy7A6Ex6tvcDVOf =h07G -----END PGP SIGNATURE-----

5 4

Relay configuration for FreedomBox
by James Valleroy 23 Mar '14

23 Mar '14

Hello, The FreedomBox project [1] is planning to include Tor in the upcoming 0.2 release. FreedomBox is intended to be used as an always-on server, so its Tor node has been configured as a bridge relay. There is also a need for FreedomBoxes to be able to find each other regardless of location or restrictive firewall. This feature is not yet completely implemented for FreedomBox, but it will likely involve each box running a Tor hidden service, and making the initial connection to other boxes over the Tor network. Here is the configuration that we are currently using in /etc/tor/torrc: ORPort 4431 BridgeRelay 1 Exitpolicy reject *:* It is based on example configuration for bridge relays given in the Tor documentation [2] but modified to still allow SOCKS connections. Do you see any vulnerabilities, attacks, or risks with the current configuration, and are there any changes that you would recommend? [1] https://wiki.debian.org/FreedomBox [2] https://www.torproject.org/docs/bridges#RunningABridge Thanks

4 6

new fingerprint after update
by Oliver Schönefeld 22 Mar '14

22 Mar '14

Hi guys, i updated from Tor 0.2.3.25 (relay 266C0CADC79F802C554019887324A57332A1DA70) to Tor 0.2.4.21 yesterday and the relay fingerprint changed to 07E333A3B979C27739096C5B2EE10D7C8E3D8FFD. Is there any way to get the new version working with the old fingerprint? I looked in the manual and tried adding a DirAuthority line in the torrc file, which looks as the following: DirAuthority 123tor *:9030 FINGERPRINT But then Tor doesn't start. I also tried writing the old fingerprint in the fingerprint file, but it's changed to the new one everytime i start Tor. So thanks for your help in advance and have a nice weekend everybody! Oli

4 3

Exit node re-writing PKI certificates?
by Iggy 21 Mar '14

21 Mar '14

Hey all, I use an email account from riseup.net, which I usually access via Thunderbird, running on a linux machine. My Thunderbird is configured to check mail via TOR. Earlier tonight I got a certificate warning message from thunderbird, saying that mail.riseup.net:465 was presenting a certificate that had been issued to cab.cabinethardwareparts.com on 03-01-2014, and expiring on 03-01-2015. Oddity among oddities, this does not match the issue dates of the other certificate reported below. Whois returns no match for cabinethardwareparts.com When I mentioned this on a Riseup IRC channel, I was told that there had previously (02-28-2014) been a help ticket from a riseup mail user, accessing their account via TOR, who had a certificate error involving a certificate issued to the same domain. So, I guess I just wanted to alert you all to the fact that this is happening. I'm not sure what it means. Is the exit node in question pointing my traffic at somewhere other than mail.riseup.net:465? Is the exit node re-writing the traffic to include the bad certificate? If so, why? If part of a MITM scheme, why not use a certificate issued to mall.riseup.net or mail.riseop.net, or something else less obvious than cab.cabinethardwareparts.com? I am more curious than anything, and any thoughts are appreciated. I'll paste the details from the previous help ticket below, since they actually captured more details about the bad certificate than I did. Kind Regards, -Iggy =-=-=-=-==-=-==-=- PASTED TEXT BEGINS =-=-==-=-=-=-=--=- Hi there wonderful riseup birds, Today I was attempting to sent a GPGd email to another riseup.net user but thunderbird flagged that a suspicious certificate was being served whose address did not match riseup.net. Its common name was: cab.cabinethardwareparts.com Serial 01:E3:94:E1:BD issued on: 05/03/13 expires: 05/03/14 organization: unknown The key was: Modulus (2048 bits): ba 29 4e f5 89 c8 4c 61 76 4c 08 fe 2e d9 4d af 8f 47 20 2b cb ee 00 56 d3 9b 4c 47 8c ee 75 f5 94 f8 65 f3 83 71 12 ed 32 ef 92 4e 25 90 ac df 4c 82 e6 6e 4e df b2 a9 48 f0 2a 7a 21 bd 10 01 7d fc 31 b4 93 ca ec ec 99 b2 91 e1 04 a7 5c 39 72 55 1f ee 74 49 4c e7 75 fe 84 67 a9 ff 81 74 e5 1e 35 db 2b 93 e1 f5 74 96 6b 19 3a 54 a3 0d 90 b1 8f 0c 2f e2 4f f1 13 5a ad c5 37 4e b5 93 54 70 54 7f 04 6b 30 58 fc f8 c8 15 04 c7 f6 90 25 9f 45 4b 38 9e 28 e8 ec df 7d 06 d4 0f d1 9c 2e 6c 9d ad 90 65 ce e4 de a0 5a 8a 14 fc b4 32 26 c9 2d 7e 91 fc c3 90 1c 52 9d 93 f0 47 38 d3 b1 66 27 38 0a 2f 2a 08 31 7c ea 62 fa 66 1d f2 90 4d 0f 8b 42 78 7b 69 00 c8 4a b3 84 4c c6 e0 a3 0d ce 91 b2 e7 75 6a c1 34 76 22 4e e4 df 85 1c d2 19 d5 2e ca 91 71 be 4e fd d3 81 2e e5 83 Exponent (24 bits): 65537 =-=-=-=-==-=-==-=- PASTED TEXT ENDS =-=-==-=-=-=-=--=-

4 4

Mail from a few minutes ago
by Sebastian Urbach 18 Mar '14

18 Mar '14

Hi, My last mail should have been sent to Moritz not to the list, my apologies. -- 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

1 0

Spiegel Online Artikel
by Sebastian Urbach 18 Mar '14

18 Mar '14

Hi Moritz, Ich hatte Andrew im Januar auf diesen Artikel aufmerksam gemacht und da er deutschsprachig ist hattest du dem Kollegen Böhm dazu was geschrieben (ich war CC oder BCC) Wenn ich das richtig erinnere dann sagte er das er die Spiegel Kollegen in HH um Änderung des Bildes gebeten habe. Als bitteres Fazit bleibt: 1. Bild wurde nicht geändert. 2. Er hat weder seinen eigenen Text korrigiert noch hat er wenigstens ein Update hinzugefügt um klarzustellen das sein Artikel Schrott war. 3. Von "Uns" gibt es afaik kein Statement zu dieser Sache die in verschiedenen Ländern u.a. USA gleichernassen falsch berichtet wurde. Deshalb meine Frage, war das alles oder sollte man Ihn vielleicht noch zu einer Richtigstellung auffordern ? Oder akzeptieren wir einfach jede Berichterstattung weil es zu viel Arbeit wäre dagegen anzugehen ? Das Ganze hat doch am Ruf gekratzt finde ich. http://www.spiegel.de/netzwelt/web/e-mails-fbi-hat-die-daten-der-anonym-die…

1 0