- tor-relays - lists.torproject.org

Re: [tor-relays] bad validity timestamps on authority certificates
by Scott Bennett 05 Nov '11

05 Nov '11

On Sat, 5 Nov 2011 02:14:43 -0400 Roger Dingledine <arma(a)mit.edu> wrote: >On Fri, Nov 04, 2011 at 06:06:41PM -0500, Scott Bennett wrote: >> Nov 04 15:51:00.273 [warn] Certificate not yet valid: is your system clock set incorrectly? >> Nov 04 15:51:00.274 [warn] (certificate lifetime runs from Nov 5 04:26:47 2011 GMT through Nov 4 04:26:47 2012 GMT. Your time is Nov 04 20:51:00 2011 GMT.) >[snip] >> My system's clock gets adjusted to the network timeservers' values once per >> hour. I've checked the logs and found that the each adjustment has been less >> than 71 ms during this time. >> So the question is why are the authorities putting out new certificates >> with valid time periods beginning six or more hours in the future? Also, when >> will the authorities be corrected? > >These aren't directory authorities. These are just random relays that >you're connecting to who have clocks more than an hour off, and an >over-active log message. Oh, okay. I had thought that only the authorities passed out "certificates", which then got stored into cached-certs. I didn't know that just any old relay could do so, too. > >See >https://trac.torproject.org/projects/tor/ticket/4370 >https://trac.torproject.org/projects/tor/ticket/4371 Thanks for the explanation, Roger. BTW, those messages seem to have stopped a few hours ago. > >This is the alpha Tor, with a shiny new (and still somewhat >sharp-around-the-edges) v3 link handshake. I'm glad this one doesn't >crash, like the last one did. :) > Yup. After seeing the notes about that bug, I just waited an extra day or two to upgrade, skipping 0.2.3.6-alpha and going straight to 0.2.3.7-alpha when it became available. :-) Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

1 0

bad validity timestamps on authority certificates
by Scott Bennett 05 Nov '11

05 Nov '11

For the last day or so, my relay has been logging messages like these: Nov 04 15:51:00.273 [warn] Certificate not yet valid: is your system clock set incorrectly? Nov 04 15:51:00.274 [warn] (certificate lifetime runs from Nov 5 04:26:47 2011 GMT through Nov 4 04:26:47 2012 GMT. Your time is Nov 04 20:51:00 2011 GMT.) Nov 04 17:28:37.359 [warn] Certificate not yet valid: is your system clock set incorrectly? Nov 04 17:28:37.361 [warn] (certificate lifetime runs from Nov 5 06:26:47 2011 GMT through Nov 4 06:26:47 2012 GMT. Your time is Nov 04 22:28:37 2011 GMT.) Nov 04 17:56:47.782 [warn] Certificate not yet valid: is your system clock set incorrectly? Nov 04 17:56:47.782 [warn] (certificate lifetime runs from Nov 5 06:26:47 2011 GMT through Nov 4 06:26:47 2012 GMT. Your time is Nov 04 22:56:47 2011 GMT.) My system's clock gets adjusted to the network timeservers' values once per hour. I've checked the logs and found that the each adjustment has been less than 71 ms during this time. So the question is why are the authorities putting out new certificates with valid time periods beginning six or more hours in the future? Also, when will the authorities be corrected? Scott Bennett, Comm. ASMELG, CFIAG ********************************************************************** * Internet: bennett at cs.niu.edu * *--------------------------------------------------------------------* * "A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army." * * -- Gov. John Hancock, New York Journal, 28 January 1790 * **********************************************************************

2 1

TOR notice.log is spammed with "Certificate not yet valid" warnings
by Klaus Layer 03 Nov '11

03 Nov '11

Hi, since 0.2.3.6-alpha the logs of my instances are full of these messages: 14:56:23 [WARN] (certificate lifetime runs from Nov 3 16:15:34 2011 GMT through Nov 2 16:15:34 2012 GMT. Your time is Nov 03 13:56:23 2011 GMT.) 14:56:23 [WARN] Certificate not yet valid: is your system clock set incorrectly? Any idea how I can get rid off these warnings? Best regards, Klaus

3 3

ARM: Client locales on connections page
by Klaus Layer 23 Oct '11

23 Oct '11

Hi, I recently found the "Client locales" function on the connection page of ARM. What exactly is the number behind the country code: ir 223334 (%13) us 188412 (%11) │ it 133819 (%8 ) │ de 121516 (%7 ) │ kr 102462 (%6 ) Thanks, Klaus

2 2

TBB on same system as relay?
by Rick Huebner 21 Oct '11

21 Oct '11

I run a relay 24/7, but sometimes also want to use Tor myself as a client. Until now, I've been using the Tor Button in my normal Firefox browser to switch in and out of Tor mode as needed, but now I see that going forward, the standalone Tor Browser Bundle is the only recommended way of using Tor as a client. How can I run the TBB on my system without interfering with my relay? When I just tried it now, the TBB brought up a second Vidalia instance which then tried to command my relay's existing Tor instance instead of spawning a second one for itself. This caused it to prompt for the relay's command interface password, but I cancelled out since I suspect that allowing the TBB to interfere with my relay's Tor process would lead to Bad Things, e.g. reconfiguring its options on the fly to a client-mode config and dropping all my users. So... how do relay operators use Tor themselves, if they can't run TBB? Or is there a way to configure them to live safely together? Or have I misinterpreted the new TBB focus, and the relay bundles will continue to support use as a client in the future as they do now? I'm using Windows 7 if that matters, but I doubt it.

4 4

Metrics portal problems?
by Rick Huebner 20 Oct '11

20 Oct '11

Is the metrics portal at https://metrics.torproject.org/ partly down, or undergoing maintenance or something? I see that some of the stats don't seem to have been updated in the last week or so. Many of the graphs are truncated, e.g. https://metrics.torproject.org/users.html?graph=direct-users&start=2011-10-…, and the per-relay stats on the https://metrics.torproject.org/networkstatus.html page all seem to stop with the 2011-10-12 13:00:00.0 consensus.

2 1

How works the flag attribution?
by Ottakar 17 Oct '11

17 Oct '11

Hi people, I just start my first node, and as my English is light, many aspect of the config are mysterious for me. I just see that my node as 2 new flags: "Stable" and "Guard". Maybe someone can explain to me how this attribution works? Thanks

3 2

Questions
by francois.pasgloup＠netcmail.com 16 Oct '11

16 Oct '11

2 1

icecat
by mick 09 Oct '11

09 Oct '11

Resending because I sent from the wrong address.... Begin forwarded message: To: tor-relays(a)lists.torproject.org Subject: icecat All I have now had a total of three abuse requests from the ISP hosting one of my tor nodes from a company called icecat (rip(a)icecat.biz) On the first two occasions I pointed to the notice on my server about it being a tor node and they went away. This time they are threating to null route my server if I don't do something. So reluctantly I have added a reject of 87.255.38.35:* to my exit policy. I'd be interested to hear from any other operators who have been pestered in this way about supposed abuses of icecat. Best Mick --------------------------------------------------------------------- The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this? Douglas E Comer - Internetworking with TCP/IP Volume 1 http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------

2 1

Relay accounting calculations
by Steve Snyder 05 Oct '11

05 Oct '11

I'm not sure I understand how the relay accounting limit is calculated. The manual says that you might specify an AccountingMax limit of 1 GB, a ceiling that would be applied to each of the input and output traffic. The manual also says that it is known the output traffic can be larger than the input traffic, especially if you're running an exit node. (I imagine that the converse applies if you also have Tor clients on the same network, using the node, though the manual doesn't say so.) Given that the AccountingMax value applies to traffic in each direction, one would have to specify a rate that is half their actual limit. That is, given a 100GB limit one would specify "AccountingMax 50 GB" in the config file, causing the relay to sleep when 50GB is reached in either input or output traffic. Is the algorithm really this inflexible? If I reach 50GB on output traffic, with only 49GB of input traffic, that puts the relay into hibernation with 1GB of bandwidth left unused. That seems counter-intuitive to me. Is the manual inaccurate, or am I just missing the hidden genius of tracking input and output traffic as distinct pools? It seems more sensible to specify the full bandwidth allotment, with the relay hibernating when the sum of the input and output traffic reach that limit.

2 1