- tor-relays - lists.torproject.org

Torservers.net relays not updated yet?
by Nusenu 19 Sep '14

19 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi torservers, since you haven't updated most of your relays to address [1] released on 2014-07-28 yet, I was wondering if everything is ok? collective vacation? Since you are operating a significant chunk of the tor network's bw - timely patching is appreciated. The tor network is currently at 64% of the bandwidth being served by relays running a recommended version according to torstatus.blutmagie.de. I updated a previous metrics feature request so we might see nice graphs about patching progress in the future [2]. [1] https://lists.torproject.org/pipermail/tor-announce/2014-July/000094.html [2] https://trac.torproject.org/projects/tor/ticket/6856#comment:2 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT7+R/AAoJEDcK3SCCSvoeevcP/06Jg2ubrbbD+SKe32necCd2 OCp4auBI3M8LjxVwJMaMi1aBW81Y513shnghYvAVLRe8NCFuem0mnWfeZq6fjrqd kKvksRhCUo2ERK7covRaoVJ8Aqs37MDJh7B48v/FYcbQYbeRIw6+OUmysC6qMPvP gi+ReWFL77kW4hAK+05z6VeaBq6FfKA8L2FRF12ahtGokCO9BnPM1DijHnA4kLJG Fh2YxbWegd5wVna3PJrubjyJ5ANHM0L5pS0dPZZNobat7Sdrux7dhLo2VdHqZFT5 etykHjc18iJhm7z0r4qjYo58gEAx9CebTqdq2w22TBQFnXPaEt9oPktpdG1Q+Ba+ wPiOOBODyngqSUICD6LRGFq3L9Xa+1RrxORD+d+XmsrGhire+83BLkxDZ/JqUB0Z ZY4NEc13tTQqxPfqB6yQyU/XjTPl45zYWsaAxBjzX/AqoXgkwAQkBwdpFrUeu0O3 UiHe4DLhYtcoeOJjisqfl8t7xbyi5TduKfFH10Erglr3WX/OJ/Pau1N/tDtNqey8 GbrZSXVtv0ch7T31Cp6hYrZwxYnucUBcotcOX01+k158zpI5wv87WCwpc9ncDO3t Oj8ORAL/MbgtYh0JaE1wIP0zSuhhWY2Y+qzdXnTwoYMbfDNnLUjcgZzbZNOhEu+E Y3LfuCsT+DI5TpwIp6tK =FZKz -----END PGP SIGNATURE-----

3 9

RELAY_EARLY tor network update status (CVE-2014-5117)
by Nusenu 18 Sep '14

18 Sep '14

(if you are on the CC list of this email you are probably one of the tor relay operators running one of the 10 fastest vulnerable [CVE-2014-5117] relays on the tor network. Please upgrade your tor relay) > The tor network is currently at 64% of the bandwidth being served by > relays running a recommended version according to torstatus.blutmagie.de. > I updated a previous metrics feature request so we might see nice > graphs about patching progress in the future [2]. Since we are seeing active RELAY_EARLY attacks again (or new buggy tor implemantations) I was wondering what the current update stats look like. ~85%* of the tor network's bandwidth is provided by patched relays. (~66% 0.2.4.23, ~11% 0.2.5.6-alpha, ~7% 0.2.5.7-rc) *) according to data from torstatus.blutmagie.de 10 fastest relays still running a vulnerable version: https://atlas.torproject.org/#details/EC98311F9EC02BEAA183651CE8402249CD036… https://atlas.torproject.org/#details/D1271A1E15C568DA709D3A1E68188EEAE8DDB… https://atlas.torproject.org/#details/12AD30E5D25AA67F519780E2111E611A455FD… https://atlas.torproject.org/#details/1B9FACF25E17D26E307EA7CFA7D455B144B03… https://atlas.torproject.org/#details/2F57987F3942BA0BBD706D623F1FF86A89684… https://atlas.torproject.org/#details/379FB450010D17078B3766C2273303C358C3A… https://atlas.torproject.org/#details/935BABE2564F82016C19AEF63C0C40B5753BA… https://atlas.torproject.org/#details/B83DC1558F0D34353BB992EF93AFEAFDB226A… https://atlas.torproject.org/#details/104A9453FD93BDBEAE9E2024898266AD2051A… https://atlas.torproject.org/#details/C11650E31F83E149C855D574B3171CC9CF9BE…

3 2

Re: [tor-relays] BBC and UK Lottery blocking ip addresses running relay
by Dan Hanley 18 Sep '14

18 Sep '14

> > > I have just received a slightly more positive reply: "At present, our GeoIP data provider classes Tor nodes as proxies, regardless of whether or not they're an exit node. We understand that there is room for improvement in this model, since non-exit relays do not present traffic on behalf of other users. We have asked our provider to give us a way of differentiating Tor exit nodes from non-exit relays, to allow us to block exit nodes only." So perhaps they will make a change... certainly reporting the issue seems to raise its importance :-) atb Dan > 5. Re: BBC and UK Lottery blocking ip addresses running relay > nodes (Chris Whittleston) > ---------- Forwarded message ---------- > From: Chris Whittleston <csw34(a)cam.ac.uk> > To: tor-relays(a)lists.torproject.org > Cc: > Date: Thu, 18 Sep 2014 01:40:31 +0100 > Subject: Re: [tor-relays] BBC and UK Lottery blocking ip addresses running > relay nodes > Yeah ouch - maybe I just got someone a bit more helpful. I'm with Matt > though, it seems like they still don't get the difference between using Tor > as a client and running a relay, so this isn't the end of the road there. > You are going to have to rely on them wanting to actually think about it > though. > > If all else fails, you could always try to simply report the issue again > using the form I linked before, but this time just don't mention Tor at all > and see if you get a different customer service person... > > http://iplayerhelp.external.bbc.co.uk/tv/incorrect_location_may2014 > > I suspect you'll end up having to explain that you're running a relay in > the end anyway, but you never know. > > Chris > > On 17 September 2014 21:48, Matt Puckey <matt(a)puckey.org> wrote: > >> Stephen Mollett: >> > [...] >> > "Thank you for contacting the BBC iPlayer support team. >> > >> > "I understand you’re experiencing problems accessing BBC iPlayer as >> > you’re told that you are outside of the UK. >> > >> > "Please note that if you run TOR, then I’m afraid as per our development >> > team’s confirmation you’ll not be able to access BBC iPlayer. If you >> > continue to use TOR then your IP address may be blacklisted against UK >> > only services across bbc.co.uk." >> > >> > I made a point of stating explicitly in my original case filing that I >> > run a middle relay and that no traffic exits from my node to the BBC's >> > website or to anywhere else, along with a link to my node's stats on >> > blutmagie confirming the (non-)exit policy. >> > [...] >> >> Hi Stephen, >> >> I'm not sure whether I'm surprised at the BBC or not! >> >> It is a shame if they seem to be doing blanket blocking of Tor relay IP >> addresses. I suppose this >> ( >> https://blog.torproject.org/blog/call-arms-helping-internet-services-accept… >> ) >> has /some/ relevance. >> >> The problem is obviously convincing a organisation like the BBC to treat >> individual IP addresses different from other Tor relay IP addresses (and >> whether they should be doing that at all). Although it seems Chris >> Whittleston obviously managed it! Maybe you simply got 'the wrong person >> at the other end'. Personally, I would continue to pursue this with them! >> >> --Matt >> >> >> >> _______________________________________________ >> tor-relays mailing list >> tor-relays(a)lists.torproject.org >> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >> > > > > -- > *Dr Chris Whittleston 栗主* > Department of Chemistry > University of Cambridge > Lensfield Road, Cambridge, CB2 1EW > Email: csw34(a)cam.ac.uk > Tel: +44 (0)1223 336423 > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > >

3 2

Where to report relay warnings
by Sebastian Urbach 18 Sep '14

18 Sep '14

Hi, I also found a lot of the mentioned log entries. The comment from Arma within the ticket is just right "Bonus points for using the name in the NSA document" Rofl :-) -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Where to report relay warnings
by Jens Müller 18 Sep '14

18 Sep '14

Hi there My relay logged the following warning this morning: Sep 18 04:52:58.387 [Warning] Received an inbound RELAY_EARLY cell on circuit 2147511747. Closing circuit. Please report this event, along with the following message. Sep 18 04:52:58.388 [Warning] upstream=85.159.214.57:9003 Now, I have checked the FAQs but didn't found any information where to report this, so I hope you can help me out. Thank you already and kind regards Jens

2 1

Bridge Offer
by Sebastian Urbach 18 Sep '14

18 Sep '14

Hi, If there is still not enough bridge capacity available after a few people already offered their help, i would be able to help with 400 Mbit (no traffic limit). -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

1 0

Fwd: Call for a big fast bridge (to be the meek backend)
by Mike Perry 18 Sep '14

18 Sep '14

Forwarded from tor-dev to here, in case any relay operators missed this: ----- Forwarded message from David Fifield <david(a)bamsoftware.com> ----- Date: Mon, 15 Sep 2014 19:12:23 -0700 From: David Fifield <david(a)bamsoftware.com> To: tor-dev(a)lists.torproject.org Subject: [tor-dev] Call for a big fast bridge (to be the meek backend) User-Agent: Mutt/1.5.23 (2014-03-12) The meek pluggable transport is currently running on the bridge I run, which also happens to be the backend bridge for flash proxy. I'd like to move it to a fast relay run by an experienced operator. I want to do this both to diffuse trust, so that I don't run all the infrastructure, and because my bridge is not especially fast and I'm not especially adept at performance tuning. All you will need to do is run the meek-server program, add some lines to your torrc, and update the software when I ask you to. The more CPU, memory, and bandwidth you have, the better, though at this point usage is low enough that you won't even notice it if you are already running a fast relay. I think it will help if your bridge is located in the U.S., because that reduces latency from Google App Engine. The meek-server plugin is basically just a little web server: https://gitweb.torproject.org/pluggable-transports/meek.git/tree/HEAD:/meek… Since meek works differently than obfs3, for example, it doesn't help us to have hundreds of medium-fast bridges. We need one (or maybe two or three) big fat fast relays, because all the traffic that is bounced through App Engine or Amazon will be pointed at it. My PGP key is at https://www.bamsoftware.com/david/david.asc if you want to talk about it. David Fifield _______________________________________________ tor-dev mailing list tor-dev(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ----- End forwarded message ----- -- Mike Perry

3 2

Re: [tor-relays] Port-Based Best-Fit Circuit Selection
by Tim 18 Sep '14

18 Sep '14

On 17 Sep 2014, at 22:00, Paritesh Boyeyoko <parity.boy(a)gmail.com> wrote: > On Tuesday 16 Sep 2014 17:36:41 Toralf F?rster wrote: >> On 09/16/2014 03:35 AM, Paritesh Boyeyoko wrote: >>> Hello -- >>> So, I was thinking that in the same way that Tor relays have port-based exit policies, could they not >>> also have port-based entrance policies? I >> >> Beside the general answer (probably "NO") - you mean something, which cannot be handled by a firewall ? >> >> > > @Toralf > > Correct, this has nothing to do with firewalls. This is more about better utilisation of slow > circuits/relays by deliberately choosing to push relatively lightweight traffic across them. > IRC and XMPP do not need 10Mbit/s circuits, not even close. > > I'm not sure how Tor clients choose the relays they use to build a circuit, and I do realise that > > a) there are probably more slow relays than fast ones > b) attempting to pre-build both a "fast circuit" and a "slow circuit" will reduce the number of > candidates for each. > > I'm just looking for ways to drive more traffic across slow relays. :) Paritesh, I think it might help to make a distinction between latency (delay) and throughput (capacity), both of which are affected by router speed: IRC, XMMP and SSH need low latency circuits, which are mostly correlated with high bandwidth relays. Web Browsing (HTTP/S) and similar generally need both low-ish latency and high throughput, also correlated with high bandwidth relays. File Downloads (HTTP/S, BitTorrent) can cope with high latency as long as the throughput is high (and the reliability is sufficient, but that's another matter). But I can't actually see much need for high latency, low throughput relays - are there many protocols that would find that useful? (SMTP is the only one that comes to mind.) T

3 2

BBC and UK Lottery blocking ip addresses running relay nodes
by Dan Hanley 18 Sep '14

18 Sep '14

All I can see there was a previous thread related to this in June, but thought I'd add what I'm seeing to the discussion. After the *Data Retention and Investigatory Powers Bill (DRIP) *was rushed through parliament I decided to do my bit for the privacy cause and run a couple of Tor relays. I run one from my laptop at home and one from my desktop at work. Since doing this I have suffered deliberate disruption in service from the BBC and the National Lottery. A Tor relay is a node on The Onion Router network that traffic gets router through to anonymise where it originated from. ( https://www.eff.org/torchallenge/what-is-tor.html) Note that I am running middle relays, not exit relays, so the connection to the destination site will never come directly from one of my relay nodes. Neither have I used the Tor browser to access either site. *The BBC* Within 48 hours the http://bbc.co.uk website started redirecting me to the http://bbc.com international version. They seem to think I am no longer a licence payer, or perhaps conspiring to allow non licence payers to access their UK service. The redirect is based on my homes IP address, so all devices, laptop, phone, ipad etc get redirected. The redirect seems to trigger via Javascript, I can access http://www.bbc.co.uk with Javascript disabled. The international site recognises that my ip address is in the UK and refuses to let me access international content. The net result is that I and my family can no longer access either UK or international BBC content. *The National Lottery* The Lottery allows me to connect and browse their site but as soon as I try to make a purchase I get blocked: *Why is this odd:* Any of the popular IP checking sites/tools show that my address is located in the UK: e.g www.whatsmyip.com or https://who.is I am using two different ISPs (Zen and VirginMedia) neither can explain the behaviour. Contacting the lottery they blame the ISP, I have been unable to get a response from the BBC. Assuming I can believe the look up services and the ISPs that my IP addresses are still located in the UK, the only explanation I can come up with is that the BBC and the lottery are deliberately blocking ip addresses that are registered on the Tor network. Whether they do this independently or avail of a common third party is unknown. So the cost of trying to maintain privacy seems to be the loss of BBC and Lottery – which seems unfair. Regards Dan

4 4

help force Centos to update Tor
by I 17 Sep '14

17 Sep '14

Hej, (With very little knowledge) I can not get Centos 6 VPS to update to the newer version of Tor. Would someone please help me to do that? off list of on Robert

1 0

Multithreading
by Sebastian Urbach 17 Sep '14

17 Sep '14

Hi, Is someone able to provide a timetable for the multithreading implementation into the alpha branch ? I'll take anything ;-) Thanks -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ----------------------------------------- Definition of TOR: 10% luck, 20% skill, 15% concentrated power of will, 5% pleasure, 50% pain and 100% reason to remember the name! -----------------------------------------

4 4

Port-Based Best-Fit Circuit Selection
by Paritesh Boyeyoko 16 Sep '14

16 Sep '14

Hello -- First of all, let me apologise if this has been covered before on this list. A couple years ago I took more than a passing interest in Tor and decided to run a non-exit relay on a VPS, which lasted until an upstream provider complained. I've recently set up another one, and while it settles into the network, it got me thinking about utilization. Much has been made of the fact that Tor is circuit-based rather than packet-based, and also of the fact that faster relays attract more traffic. So, I was thinking that in the same way that Tor relays have port-based exit policies, could they not also have port-based entrance policies? In other words, cause deliberate selection of a "slow" path based on the protocol intended to be used. So for example, HTTP would favour faster circuits, while the likes of email (POP, IMAP, SMTP), XMPP and IRC would favour slower circuits (being mostly text-based). Perhaps the entrance policies could be maintained on-network (perhaps with "authority servers", with clients downloading the policies when they start up, rather than having them hard coded or configured client-side? Just some ideas. :) Best, -- Paritesh Boyeyoko parity.boy(a)gmail.com

2 2

Understanding Reduced Exit Policies..?
by Jeremy Olexa 13 Sep '14

13 Sep '14

Hello, I've setup a non-exit node so that I can contribute and understand the TOR network somewhat better. I've only had my node (jolexarelay1) up for a few weeks so it is still becoming a part of the network at guard status. So, as I understand my ISP, I can run an exit node if I "handle" abuse complaints to their standards. Now, since I have more idle bandwidth than idle time to "handle" complaints, I've often wondered about the reduced exit node strategy as seen at https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy - I'd like to allow ports in a methodical fashion such that I can test to see if a port generates complaints easily/quickly. My question: If I want to "try" being an exit node and add allowed exit ports slowly, does that help the network or not? For example, month 1: allow port 22, month 2: allow IRC ports, and so-on. How does the client path selection work in this case - is it smart enough to pick my exit when needed? Thanks for any insight, Jeremy

3 3

request at Hetzner
by Toralf Förster 13 Sep '14

13 Sep '14

3 things: 1. ========= This is what I get few days ago from Hetzer Support: >Guten Tag Herr Förster, > >laut Deutschem Recht sind Tor Server im Moment nicht verboten. >Aus diesem Grund sind Tor Server bei uns auch nicht verboten. >Aus Erfahrung raten wir jedoch vom Betrieb eines Tor Exit Node ab. >Leider wird oft ueber Tor Server Content verbreitet welcher laut >Deutschem Recht >nicht erlaubt ist. Dies kann Ermittlungen von Behoerden nach sich >ziehen. Maybe worth to update https://trac.torproject.org/projects/tor/wiki/doc/GoodBadISPs ? 2. ========= I'm planning to setup there a dedicated server now soon (with Gentoo Linux if possible) within next days - or are there too much servers already at the ISP Hetzner ? 3. ========= And for the following days I do want put the line "ExitPolicy reject *:*" before all subsequent liens like "ExitPolicy accept *:20-23 # FTP, SSH, telnet" of the reduced exit policy to just look how the system behaves as a simply relay. Worth or superflous ? Am I right, that later just commenting out that reject line enhance the Tor server from relay to "relay + exit node" ? Or does this mean that -- Toralf pgp key: 0076 E94E

6 9

What to change for v0.2.5.x?
by Steve Snyder 13 Sep '14

13 Sep '14

So now Tor v0.2.5.x Release Candidates are available. Can someone give an overview of what's new for those who don't follow the development process? What can/or should be changed in a working v0.2.4.x relay config to accommodate the changes made in the new code? Are there particular areas (IPv6, multi-threading, etc.) that one should be aware of when moving from v0.2.4 to v0.2.5? The changelogs do a great job of describing the changes between point releases but are somewhat overwhelming when attempting to determine the differences between major releases. If would be great if someone could give a brief(-ish) description of those changes. Thanks.

3 3

IPv6 - status
by Marcin Gondek 12 Sep '14

12 Sep '14

Hi, What is the current state of IPv6? ==cut== Relays to relays Relays talk to other relays. The work with relays talking to other relays over IPv6 has not been started. ==cut== Is there any plans to start? How I can help? ==cut== Directory authorities on IPv6 Clients and relays talk to directory authorities. The work with making directory authorities reachable over IPv6 has not been started. This work will be tracked in #6027. ==cut== Same as above? Clue is when it will be possible to run pure IPv6 relay/guard. Regards, -- Marcin Gondek / Drixter http://fido.e-utp.net/ AS56662

3 4

Re: [tor-relays] boost CPU on a Tor relay
by Harold Naparst 09 Sep '14

09 Sep '14

I'll just throw in my datapoint on this subject because it might be of interest. My relay (torpoint) is currently advertising a bandwidth of 58 MB/s according to Globe. Arm reports that it is pushing 50 MB/s and has 12,500 open clients. It has a Xeon E3/1220 with 8 GB ram. The load average is 0.75, and the four cores are at about 20-25% each. About 2GB of ram is being used. On the whole, this relay is probably bandwidth constrained. The ISP guarantees 150 Mbps, but I sometimes get more, like now.

1 0

Gentoo overlay
by Harold Naparst 09 Sep '14

09 Sep '14

Sorry Jeremy, I didn't realize you were a Gentoo dev. I have added the comment to the Gentoo bug discussion per your wishes.

1 0

Re: [tor-relays] enable-ec_nistp_64_gcc_128
by Harold Naparst 09 Sep '14

09 Sep '14

I thought about this also, but I decided not to do it. Gentoo has clearly decided not to include the Elliptic Curve algorithms until they can get confirmation that it works on all archs. Funtoo has taken the opposite position. >From the looks of the Gentoo thread, they should add the flag in the near future, and I think it would be more diplomatic to just let the process play out. My hope is that a Google search would lead most people to this post. I just created the ebuild in my overlay because I wanted it now and I thought some other enthusiasts would also want it now. I hope it works for you, and would be interested if it makes a difference. > Thanks for your contribution, can you also add some note to the > underlying bug report https://bugs.gentoo.org/469976 so others may see > it easier? > -Jeremy > On Mon, Sep 8, 2014 at 2:52 PM, Harold Naparst <harold(a)alum.mit.edu> wrote: >> If you want a version of openssl compiled with the >> enable-ec_nistp_64_gcc_128 option and you are using Gentoo Linux, >> you can grab it from my overlay:

1 0

enable-ec_nistp_64_gcc_128
by Harold Naparst 09 Sep '14

09 Sep '14

If you want a version of openssl compiled with the enable-ec_nistp_64_gcc_128 option and you are using Gentoo Linux, you can grab it from my overlay: layman -f layman -a hnaparst emerge openssl The new flag "nist" is turned on by default. I have 1.0.1i and 1.0.2_beta2 in the overlay. Hope it helps.

2 1

TTTT
by Sebastian Urbach 08 Sep '14

08 Sep '14

Dear list members, Just a quick update regarding TTTT: Currently we are working on a technical paper based on the so far collected data. ETA is roughly 4 weeks from now on. The paper is going to hit this list asap. -- 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

Handshake flood now on NTor
by Jobiwan Kenobi 08 Sep '14

08 Sep '14

Hi, For about 15 hours straight, my relay was being hammered by connections/handshakes. I see lots of these: Sep 02 01:03:02.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [70638 similar message(s) suppressed in last 60 seconds] Numbers vary between 30000 and 80000 per 60 seconds. Also the occasional clock jump message and other performance related messages, and of course, _lots_ of unsuccessful handshakes: Sep 01 22:31:26.000 [notice] Circuit handshake stats since last time: 5038/5038 TAP, 17771/17773 NTor. Sep 02 04:31:26.000 [notice] Circuit handshake stats since last time: 3100/3484 TAP, 465565/5417818 NTor. Sep 02 10:31:26.000 [notice] Circuit handshake stats since last time: 3139/4249 TAP, 679872/8244698 NTor. Sep 02 16:31:26.000 [notice] Circuit handshake stats since last time: 3884/5294 TAP, 502835/10443735 NTor. It is a low spec machine. I've been through episodes like this before, but this time it's different: - They are NTor handshakes, where before they would be TAP handshakes. - The amount of up and down traffic is pretty balanced, where before I would get much more down than up during these floods. - In case it matters: I am now running 0.2.4.23, before I was on 0.2.4.18-RC It stopped about 4 hours ago. Running normal now. -Job

3 3

fingerprint info propogation
by jason＠icetor.is 07 Sep '14

07 Sep '14

Sorry if asked before, made a stupid oversight restarting one of my exits yesterday, had duplicated the fingerprint file from another node. Changed the file to the correct nickname today (I know nicknames are depreciated now) and reset tor, how long will it take this change to propogate to the network? -Jason

4 4

TOR exit notice (not USA)
by Christian Gagneraud 06 Sep '14

06 Sep '14

Hi there, I've just installed the tor-exit-notice.html (from contrib/) on my exit node, and read it carefully. I think this is great to have such a text, but 2 paragraphs are USA specific, the one about ECPA and the following one about DMCA. I would like to know if anyone knows about equivalent text for the European Union, Germany, France and New Zealand (I'm French, I'm a New Zealand resident and I run a TOR exit node on a server located in Germany) Thanks, Chris

4 4

Time information
by Marcin Gondek 05 Sep '14

05 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I just looking on the logs and see: ==cut== Sep 02 21:03:54.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:443. It seems that our clock is behind by 1 hours, 24 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:06:04.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:9001. It seems that our clock is ahead by 1 hours, 4 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:06:08.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:9001. It seems that our clock is ahead by 3 hours, 35 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:06:58.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:9001. It seems that our clock is behind by 5 hours, 58 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:08:53.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:9001. It seems that our clock is behind by 1 hours, 54 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:10:49.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:9001. It seems that our clock is behind by 5 hours, 55 minutes, or that theirs is ahead. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:11:51.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:8443. It seems that our clock is ahead by 1 hours, 26 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings. Sep 02 21:11:52.000 [info] channel_tls_process_netinfo_cell(): Received NETINFO cell with skewed time from server at x.x.x.x:449. It seems that our clock is ahead by 1 hours, 19 minutes, or that theirs is behind. Tor requires an accurate clock to work: please check your time and date settings. ==cut== Should I worry about it? Logs seems to little strange and looks that other servers provide it's local time without any timezone. [root@fido tor]# ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== +x.x.x.x .PPS. 1 u 11 64 377 15.026 2.142 3.279 +x.x.x.x .PPS. 1 u 26 64 377 8.315 2.734 4.281 +x.x.x.x .PPS. 1 u 2 64 377 6.511 0.973 3.214 *x.x.x.x .PPS. 1 u 60 64 377 6.395 2.162 1.869 oGPS_NMEA(0) .GPS. 0 l 15 16 377 0.000 0.014 0.009 And server is a part of ntppool - valid. Regards, - -- Marcin Gondek / Drixter http://fido.e-utp.net/ AS56662 -----BEGIN PGP SIGNATURE----- Version: Outlook Privacy Plugin iGkEARECACkFAlQGGCoiHE1hcmNpbiBHb25kZWsgPGRyaXh0ZXJAZS11dHAubmV0 PgAKCRCBZoxYcbpnGhhSAJ0RENGRgehGCb/9m/P2lTHR/2k+kACgwOIXsUNHS6FW 1AOwVQoeTwSPCO0= =OYl2 -----END PGP SIGNATURE-----

6 8