Now that Tor v0.2.4.x has reached Release Candidate status, could someone please inform those who haven't been following the development process what is new?
I just mean the broad strokes. Like: What changes to a working relay are required or recommended when moving to v0.2.4.x?
What are the major new features of this release? (Any benefit now to using more than 2 CPU cores? IPv6 support for non-bridge relays? That sort of thing.)
Thanks.
thomas.hluchnik(a)netcologne.de:
> Hello all, please help me understanding this:
>
> supposed, the NSA were able to break into a large scale of tor nodes,
> stealing the tor private server key. At the same time they were able
> to gather all traffic they can get. Wouldnt this increase the
> likelihood that data from complete circuits can be decrypted and
> traced back to the original sender?
If their intercepts are passive, merely stealing relays' private
identity key won't accomplish much because Tor uses Forward Secrecy for
both the relay TLS links and for circuit setup.
https://en.wikipedia.org/wiki/Perfect_forward_secrecy
However, if their intercepts are active (as in they can arbitrarily
manipulate traffic in-flight), then stealing either Guard node keys or
directory authority keys allows complete route capture and traffic
discovery of targeted clients.
So you are right to worry about this, in my opinion. I am also very
concerned.
I want to make some changes to Tor to make such key theft easier to
detect, less damaging, and harder to make use of:
https://trac.torproject.org/projects/tor/ticket/7126https://trac.torproject.org/projects/tor/ticket/5968
However, I want to do a lot of other things in 0.2.5.x though too, and
there's this whole browser thing that I'm technically supposed to be
paying attention to too, so I might not get to those. :/
That first one (#7126) is probably a good volunteer/student project for
someone who likes Python, though. It would be easy to make a prototype
with Stem, txtorcon, or even TorCtl.
> Maybe this is paranoid, but this arises the question for me: what
> would happen when I stop my tor node once a week, throw away my keys
> and restart tor so that new server keys were generated. So NSA would
> have to break into my system again, but this would make it harder for
> NSA agency to decrypt circuits where my host is involved.
I am in favor of regular identity key rotation for relays, and I want to
work towards supporting that better by default:
https://trac.torproject.org/projects/tor/ticket/5563
I think keeping your keys on a ramdisk or encrypted filesystem with a
memory-only random key (so if you experience unexplained reboots, etc
they go away) is a good idea.
Also, since Tor reads/creates its identity key at startup and doesn't
need the file afterwords, you can even 'shred'/'wipe' it after that, so
the adversary can't easily pull them off the FS while the system is
running.
Better still, you can load a Kernel module to disable gdb debugger
support so the adversary has to actually dig through/manipulate raw
memory to get the key (which will be error prone and is more likely to
lead to crashes/panics/reboots): https://gist.github.com/1216637
I started describing these and related ideas here:
https://trac.torproject.org/projects/tor/wiki/doc/TorRelaySecurity
But I got distracted by more pressing issues before I could finish the
scripts.. Also, many of those encrypted+authenticated Tor container
things probably don't make much sense without Secure Boot to
authenticate the boot process up until you can start up Tor. :/
> What were the disadvantages for the tor network? Would this confuse
> the tor director in any way?
Sort of. Weekly identity key rotation is too frequent to recommend for
people to do for a few reasons.
First, it takes the bandwidth measurement servers a couple days to ramp
up your capacity of your new identity key, so you will spend a lot of
time below your max throughput. Second, you would also likely never get
the Guard flag. Third, there are also load balancing issues with Guard
nodes where as soon as you get the Guard flag, it will take 1-2 months
before clients switch to your new Guard, so you will also likely spend
that time at less than your full capacity.
> Would it be able to keep the nickname or would it have to change also?
> Would this have effect on the onion address if I had a hidden server?
No and no, but your hidden server might have brief downtimes/descriptor
publish times that correlate with your key rotation. Not sure how severe
that is in practice.
--
Mike Perry
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
I am running an exit node on a VPS. For some reason (I've opened a support ticket) a) my systems clock is off by 2 hours (even though its hosted in CEST land) and b) I cannot change it, even though I am root.
As a result, I am getting recurring skewed time errors as below:
Accounting (awake) Time to reset: 29:12:02:58
21 GB / 1 PB 22 GB / 1 PB
Events (TOR/ARM NOTICE - ERR):
│ 12:25:39 [WARN] Received directory with skewed time (server '86.59.21.38:80'): It seems that our clock is ahead by 2 hours, 3 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time, timezone, and date settings.
│ 12:25:03 [WARN] Received NETINFO cell with skewed time from server at 76.73.17.194:9090. It seems that our clock is ahead by 2 hours, 3 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings.
I haven't found any mention in the archives of this (except [1] which is NOT the same, just mentions wrong time), if it results in issues to the network overall.
Until I can get it resolved (today hopefully) is there any negative affects on the network of having a node with bad time?
thanks,
Bernard
[1] https://lists.torproject.org/pipermail/tor-relays/2011-November/001001.html
- --------------------------------------
Bernard / bluboxthief / ei8fdb
IO91XM / www.ei8fdb.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJR0o/WAAoJENsz1IO7MIrr8SoIALW8W1+SawsVv6r2sLCEPetp
u05dGZ4E2vyuey5VIRfPsG1Lc2kPmE+dzY2jgHm2Q66htBqMXtv+WQ1P8TMBYyzj
ke/LkXOW2aE2NkyJ95navfnImJGWS+Ie4eyk+PnHL0d6RoRc9K2JKnQKTCPLRQvQ
kiFUkKWuHVn/aRzalrlKH7yFdoPosh5pdqqyRLQ4sDQ0dAye0u4GxfvMsrdCP8oO
ediSXiRaupSr24V+yK7ceZNUiEBcdNp6VudwJXQ+YH1uF4obSHeVWQFC7ZRpAbAI
VrqNVqBx7Xbij0wC83VR6ifz/AYJNoKlG56H72w/jg1hVwi7x58CIuLWBOm1bUM=
=2AY7
-----END PGP SIGNATURE-----
Hello everybody,
I am running a Tor exit node since some year´s. In the last month I
experienced problems with Skype.
Skype won´t connect anymore....but if I shutdown the EXIT NODE Skype
connects again.
Just want to ask all of you if you experienced similar problems?
I also opened a ticket at Skype.com
So if you got the same problem like me pls go there and post some
additional information.
> http://community.skype.com/t5/Security-Privacy-Trust-and/Is-Skype-blocking-…
Cheers
VarVarna
Hi fast-relay operators,
I'm looking for some Munin graphs (or similar) showing the effect of
turning on crypto acceleration on fast relays.
Does anyone have such graphs to share that show decrease in CPU load and
corresponding increase in bandwidth use?
Thanks!
Karsten
Hi,
I've set up my relays as obfuscated bridges and when I run arm, I see that there's been ~100MB of data downloaded but only ~20MB of data uploaded.
Is it the desired behaviour, or is there a config issue on my side?
Cheers,
--
Torry
Roger Dingledine:
> Tor 0.2.4.13-alpha fixes a variety of potential remote crash
> vulnerabilities, makes socks5 username/password circuit isolation
> actually actually work (this time for sure!), and cleans up a bunch
> of other issues in preparation for a release candidate.
>
> https://www.torproject.org/dist/
As a heads up, a bug was introduced in this release that allows
malicious websites to discover a client's Guard nodes in a very short
amount of time (on the order an hour), if those Guard nodes upgrade to
this release.
Unfortunately, the bug was introduced by fixing another issue that
allows Guard nodes to be selectively DoSed with an OOM condition, so
Guard node (and Guard+Exit node) operators are kind of in a jam.
I think the best course of action is to suggest that nodes with the
Guard flag *not* upgrade to this release, unless they are experiencing
unexplained OOMing?
If we can't find a solution that rigorously fixes both issues, I think
that future releases should have the OOM DoS fix off by default but
available through a torrc option.
See also:
https://trac.torproject.org/projects/tor/ticket/9072
> Changes in version 0.2.4.13-alpha - 2013-06-14
> o Major bugfixes (robustness):
> - Close any circuit that has too many cells queued on it. Fixes
> bug 9063; bugfix on the 54th commit of Tor. This bug is a further
> fix beyond bug 6252, whose fix was merged into 0.2.3.21-rc.
> - Prevent the get_freelists() function from running off the end of
> the list of freelists if it somehow gets an unrecognized
> allocation. Fixes bug 8844; bugfix on 0.2.0.16-alpha. Reported by
> eugenis.
> - Avoid an assertion failure on OpenBSD (and perhaps other BSDs)
> when an exit connection with optimistic data succeeds immediately
> rather than returning EINPROGRESS. Fixes bug 9017; bugfix on
> 0.2.3.1-alpha.
> - Fix a directory authority crash bug when building a consensus
> using an older consensus as its basis. Fixes bug 8833. Bugfix
> on 0.2.4.12-alpha.
>
> o Major bugfixes:
> - Avoid a memory leak where we would leak a consensus body when we
> find that a consensus which we couldn't previously verify due to
> missing certificates is now verifiable. Fixes bug 8719; bugfix
> on 0.2.0.10-alpha.
> - We used to always request authority certificates by identity digest,
> meaning we'd get the newest one even when we wanted one with a
> different signing key. Then we would complain about being given
> a certificate we already had, and never get the one we really
> wanted. Now we use the "fp-sk/" resource as well as the "fp/"
> resource to request the one we want. Fixes bug 5595; bugfix on
> 0.2.0.8-alpha.
> - Follow the socks5 protocol when offering username/password
> authentication. The fix for bug 8117 exposed this bug, and it
> turns out real-world applications like Pidgin do care. Bugfix on
> 0.2.3.2-alpha; fixes bug 8879.
> - Prevent failures on Windows Vista and later when rebuilding the
> microdescriptor cache. Diagnosed by Robert Ransom. Fixes bug 8822;
> bugfix on 0.2.4.12-alpha.
>
> o Minor bugfixes:
> - Fix an impossible buffer overrun in the AES unit tests. Fixes
> bug 8845; bugfix on 0.2.0.7-alpha. Found by eugenis.
> - If for some reason we fail to write a microdescriptor while
> rebuilding the cache, do not let the annotations from that
> microdescriptor linger in the cache file, and do not let the
> microdescriptor stay recorded as present in its old location.
> Fixes bug 9047; bugfix on 0.2.2.6-alpha.
> - Fix a memory leak that would occur whenever a configuration
> option changed. Fixes bug 8718; bugfix on 0.2.3.3-alpha.
> - Paste the description for PathBias parameters from the man
> page into or.h, so the code documents them too. Fixes bug 7982;
> bugfix on 0.2.3.17-beta and 0.2.4.8-alpha.
> - Relays now treat a changed IPv6 ORPort as sufficient reason to
> publish an updated descriptor. Fixes bug 6026; bugfix on
> 0.2.4.1-alpha.
> - When launching a resolve request on behalf of an AF_UNIX control
> socket, omit the address field of the new entry connection, used in
> subsequent controller events, rather than letting tor_dup_addr()
> set it to "<unknown address type>". Fixes bug 8639; bugfix on
> 0.2.4.12-alpha.
>
> o Minor bugfixes (log messages):
> - Fix a scaling issue in the path bias accounting code that
> resulted in "Bug:" log messages from either
> pathbias_scale_close_rates() or pathbias_count_build_success().
> This represents a bugfix on a previous bugfix: the original fix
> attempted in 0.2.4.10-alpha was incomplete. Fixes bug 8235; bugfix
> on 0.2.4.1-alpha.
> - Give a less useless error message when the user asks for an IPv4
> address on an IPv6-only port, or vice versa. Fixes bug 8846; bugfix
> on 0.2.4.7-alpha.
>
> o Minor features:
> - Downgrade "unexpected SENDME" warnings to protocol-warn for 0.2.4.x,
> to tolerate bug 8093 for now.
> - Add an "ignoring-advertised-bws" boolean to the flag-threshold lines
> in directory authority votes to describe whether they have enough
> measured bandwidths to ignore advertised (relay descriptor)
> bandwidth claims. Resolves ticket 8711.
> - Update to the June 5 2013 Maxmind GeoLite Country database.
>
> o Removed documentation:
> - Remove some of the older contents of doc/ as obsolete; move others
> to torspec.git. Fixes bug 8965.
>
> o Code simplification and refactoring:
> - Avoid using character buffers when constructing most directory
> objects: this approach was unwieldy and error-prone. Instead,
> build smartlists of strings, and concatenate them when done.
>
> _______________________________________________
> tor-talk mailing list
> tor-talk(a)lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
--
Mike Perry
Greetings!
I currently have 1 bridge relay running on my AWS account.
Is it possible to add another 2 bridge relays to run as separate
instances from the same AWS account?
I'm wondering if there might be issues with IP address allocation?
For example, would I need to make any ammendment to the tor
configuration file a la 'tor family' to differentiate between the
different nodes running on the same amazon account?
Any advise appreciated.
Best regards,
Johnnie
Dear all,
I have now been running an exit node for approximately two weeks, it has
a fast connection (100Mbit) but I have a traffic limit of 1000GB per
month. I have been closely monitoring it via [1] and Munin.
I believe to have read that using accounting/hibernation is preferrable
over rate limiting with fast connections, but I can't seem to find the
exact page at the moment.
As you can see (well, guess) from [1], the node is up for about 6-8
hours until its daily quota (currently 10GB, may become a little more)
is exhausted, with peaks of around 900K/s but usually around 400-500K/s.
In my quest to maximize the usefulness of my node, I would very much
appreciate if someone could explain or make educated guesses about the
following questions:
1. Note that there are two significant dips in the exit probability
chart [1]. The first one I can explain, because I had to reconfigure and
restart the server. Nothing special happened after that. What may have
caused the second dip? What tools could I use to figure it out/monitor
it in the future?
2. My server is bored in terms of memory/CPU usage. I set NumCPUs to 2
and BandwidthRate 100 MB, BandwidthBurst 200 MB as suggested in [2].
Besides the fact that I wouldn't want to exhaust my daily quota in a few
hours, shouldn't the traffic become more than 900K/s peaks?
3. What is a good trade-off in terms of speed and uptime with such a
daily quota? Should I go for speed? If so, are there any pretty graphs
that show at what time of the day the Tor network needs the most
bandwidth? If I should go for uptime, what is a good bandwidth limit to
keep this a fast node?
4. I enabled directory mirroring, but apparently this does not work with
hibernation (i.e. it is not advertised). If I understand correctly,
directory mirrors are very useful, so how does that weigh in on the
decision to maybe limit the bandwidth to keep the node up 24/7?
5. Related to 4., why is DirPort not advertised when hibernation is
configured? References to papers are sufficient if this requires a
complicated answer :)
[1]
https://atlas.torproject.org/#details/5A91910C1B3F3FCC15EA6C6538FB9A5FAF360…
[2] http://archives.seul.org/or/relays/Aug-2010/msg00034.html
Thank you very much for any pointer on any of these questions!
Cheers, Conrad