Only send netinfo clock_skew to controller if an authority told us so

We were triggering a CLOCK_SKEW controller status event whenever
we connect via the v2 connection protocol to any relay that has
a wrong clock. Instead, we should only inform the controller when
it's a trusted authority that claims our clock is wrong. Bugfix
on 0.2.0.20-rc; starts to fix bug 1074. Reported by SwissTorExit.
This commit is contained in:
Roger Dingledine 2009-08-28 03:42:09 -04:00
parent d52284559b
commit 64f393d56f
3 changed files with 23 additions and 10 deletions

View File

@ -18,6 +18,11 @@ Changes in version 0.2.1.20 - 2009-??-??
- Fix an extremely rare infinite recursion bug that could occur if
we tried to log a message after shutting down the log subsystem.
Found by Matt Edman. Bugfix on 0.2.0.16-alpha.
- We were triggering a CLOCK_SKEW controller status event whenever
we connect via the v2 connection protocol to any relay that has
a wrong clock. Instead, we should only inform the controller when
it's a trusted authority that claims our clock is wrong. Bugfix
on 0.2.0.20-rc; starts to fix bug 1074. Reported by SwissTorExit.
Changes in version 0.2.1.19 - 2009-07-28

View File

@ -1255,20 +1255,26 @@ $Id$
CLOCK_SKEW
SKEW="+" / "-" SECONDS
MIN_SKEW="+" / "-" SECONDS.
SOURCE="DIRSERV:IP:Port" / "NETWORKSTATUS:IP:PORT" / "CONSENSUS"
SOURCE="DIRSERV:" IP ":" Port /
"NETWORKSTATUS:" IP ":" Port /
"OR:" IP ":" Port /
"CONSENSUS"
If "SKEW" is present, it's an estimate of how far we are from the
time declared in the source. (In other words, if we're an hour in
the past, the value is -3600.) "MIN_SKEW" is present, it's a lower
bound. If the source is a DIRSERV, we got the current time from a
connection to a dirserver. If the source is a NETWORKSTATUS, we
decided we're skewed because we got a v2 networkstatus from far in
the future. If the source is CONSENSUS, we decided we're skewed
because we got a networkstatus consensus from the future.
the future. If the source is OR, the skew comes from a NETINFO
cell from a connection to another relay. If the source is
CONSENSUS, we decided we're skewed because we got a networkstatus
consensus from the future.
{Controllers may want to warn the user if the skew is high, or if
multiple skew messages appear at severity WARN. Controllers
shouldn't blindly adjust the clock, since the more accurate source
of skew info (DIRSERV) is currently unauthenticated.}
{Tor should send this message to controllers when it thinks the
skew is so high that it will interfere with proper Tor operation.
Controllers shouldn't blindly adjust the clock, since the more
accurate source of skew info (DIRSERV) is currently
unauthenticated.}
BAD_LIBEVENT
"METHOD=" libevent method

View File

@ -610,9 +610,11 @@ command_process_netinfo_cell(cell_t *cell, or_connection_t *conn)
conn->_base.address, (int)conn->_base.port,
apparent_skew>0 ? "ahead" : "behind", dbuf,
apparent_skew>0 ? "behind" : "ahead");
control_event_general_status(LOG_WARN,
"CLOCK_SKEW SKEW=%ld SOURCE=OR:%s:%d",
apparent_skew, conn->_base.address, conn->_base.port);
if (severity == LOG_WARN) /* only tell the controller if an authority */
control_event_general_status(LOG_WARN,
"CLOCK_SKEW SKEW=%ld SOURCE=OR:%s:%d",
apparent_skew,
conn->_base.address, conn->_base.port);
}
/* XXX maybe act on my_apparent_addr, if the source is sufficiently