Export clock skew opinion as getinfo command
Torbutton could make use of a getinfo command to reduce the fingerprinting issues that a user has wrt their Date() object (see #2940 (moved)).
However, the threading support in Firefox is not good enough for us to easily make a full tor controller that listens for events. It would be much easier if the current skew (ideally down to milliseconds if possible) was available as a getinfo command, so that Torbutton could just query it and update the browser's time offset.
I am making this a 'major' enhancement because clock skew is an important issue to address to reduce fingerprinting.
Activity
changed milestone to %Tor: unspecified
Hm. So as the controller interface reports CLOCK_SKEW events now, it seems that there's no notion of "our best estimate of our skew so far". Instead, we only report sources that tell us we're skewed; we don't have a notion of "the current skew" internally.
We could get one, of course. We currently take skew from:
- Any networkstatus or consensus that comes from the future.
- Any time we connect to an authority (via a netinfo or a directory request) and it tells us the correct time.
Replying to nickm:
Hm. So as the controller interface reports CLOCK_SKEW events now, it seems that there's no notion of "our best estimate of our skew so far". Instead, we only report sources that tell us we're skewed; we don't have a notion of "the current skew" internally.
We could get one, of course. We currently take skew from:
- Any networkstatus or consensus that comes from the future.
- Any time we connect to an authority (via a netinfo or a directory request) and it tells us the correct time.
Yeah, I'd need something like the latter. Roger mentioned some k of n authorities scheme you guys had briefly discussed to get an average estimate on the actual current time once drift is detected? Something like that would be ideal. The closer we can get our clock-drifted clients to the actual current time, the better. for fingerprinting reasons.
Replying to nickm:
I started doing some work here in a branch called "skew_estimate". Needs some attention and review for sanity.
Your clock-skew estimate will become invalid if the clock 'jumps'. As far as I can tell, the only thing we can reasonably do in that case is forget our current clock-skew information completely.
-
Replying to nickm:
I started doing some work here in a branch called "skew_estimate". Needs some attention and review for sanity.
In command_process_netinfo_cell(), why do you only set apparent_skew if conn->handshake_state->sent_versions_at was within 180 seconds? Is it possible that the dirauth just won't respond in any reasonable amount of time here?
In connection_dir_client_reached_eof(), you use conn->_base.timestamp_lastwritten. Is there any way to obtain the timestamp of the first byte back from the request? If you can get that, you can then do 'delta = lastwritten + (firstbyte - lastwritten)/2 - date_header' to adjust for network+dirauth processing latency...
In router_set_networkstatus_v2() and networkstatus_set_current_consensus(), you use the published/valid_after time. This is probably too low of a resolution to bother to record it to report for TBB. We care about precision down to the second (possibly even sub-second)... Recording this value will just cause all TBB users to all have weird, messed up clocks. If we want that property, we can get it other ways than through the control port command...
Trac:
Owner: N/A to nickm
Status: needs_review to assigned -
WRT networkstatus_set_current_consensus(): I guess it is probably better than having a clock that is 10 years off (or whatever offset people who set their clocks to pirate time-limited demos will have).
Also, how often can we expect clients to actually talk to actual dirauths for command_process_netinfo_cell() and connection_dir_client_reached_eof() to record values from them?
Replying to mikeperry:
Replying to nickm:
I started doing some work here in a branch called "skew_estimate". Needs some attention and review for sanity.
In command_process_netinfo_cell(), why do you only set apparent_skew if conn->handshake_state->sent_versions_at was within 180 seconds? Is it possible that the dirauth just won't respond in any reasonable amount of time here?
The SSL handshake itself is our only assurance that we are actually talking to the server we think we are talking to in something like 'real time'. After the handshake completes, an active attacker can delay the NETINFO and VERSIONS cells for arbitrarily long periods of time. We should probably decrease the 180-second window to around 30 seconds or less.
In router_set_networkstatus_v2() and networkstatus_set_current_consensus(), you use the published/valid_after time. This is probably too low of a resolution to bother to record it to report for TBB. We care about precision down to the second (possibly even sub-second)... Recording this value will just cause all TBB users to all have weird, messed up clocks. If we want that property, we can get it other ways than through the control port command...
The timestamp on a published consensus is only used as a lower bound on the current time. Tor reports this timestamp to its clock skew reporting system so that it can complain if the system clock is definitely skewed.
-
Replying to rransom:
Replying to mikeperry:
Replying to nickm:
I started doing some work here in a branch called "skew_estimate". Needs some attention and review for sanity.
In command_process_netinfo_cell(), why do you only set apparent_skew if conn->handshake_state->sent_versions_at was within 180 seconds? Is it possible that the dirauth just won't respond in any reasonable amount of time here?
The SSL handshake itself is our only assurance that we are actually talking to the server we think we are talking to in something like 'real time'. After the handshake completes, an active attacker can delay the NETINFO and VERSIONS cells for arbitrarily long periods of time. We should probably decrease the 180-second window to around 30 seconds or less.
Hrmm, effectively fingerprinting the user. Very nice. I didn't see that. There should definitely be a comment on this line then. If you and nick had died before this merged, I might have removed that check. A future me might still try to remove it :).
I agree that it should be lowered, but I think we should use the circuit build timeout (perhaps div 3) to give us a floor for the value. 30s might be too low of a value on a satellite connection or protest-laden link.
In router_set_networkstatus_v2() and networkstatus_set_current_consensus(), you use the published/valid_after time. This is probably too low of a resolution to bother to record it to report for TBB. We care about precision down to the second (possibly even sub-second)... Recording this value will just cause all TBB users to all have weird, messed up clocks. If we want that property, we can get it other ways than through the control port command...
The timestamp on a published consensus is only used as a lower bound on the current time. Tor reports this timestamp to its clock skew reporting system so that it can complain if the system clock is definitely skewed.
I uh, failed to substract these two checks properly I guess ;). I didn't realize they were updating only in the case of the documents being from the future.. At the risk of asking another dumb question now, why 60s for the consensus but a whole day for the ns2 documents? Also, why 60s? Isn't any amount of time in the future evidence of drift?
Trac:
Cc: N/A to g.koppen@jondos.de-
On review, I'm going to kick this into 0.2.4.x, and solicit ideas for how to make it better. As it stands, it isn't too wrong, but it isn't actually useful: we only venture an opinion as to our skew if we have talked to >3 directory authorities. But that will practically never happen for clients; only for caches or relays, which generally don't do torbutton and don't have a great use for this info.
IOW, this exposes the info we have, but we don't typically have enough info here to be useful for clients.
Trac:
Milestone: Tor: 0.2.3.x-final to Tor: 0.2.4.x-final Trac:
Cc: g.koppen@jondos.de to g.koppen@jondos.de, adrelanos@riseup.net
Parent: N/A to #3059 (moved)-
I called #6894 (moved) a duplicate of this bug.
-
Trac:
Parent: #3059 (moved) to N/A 
Has there been any further development in this area? #17739 (moved) was merged and so the clock skew code should be somewhat consistent but it still uses the date header and the related ticket #17728 (moved) was removed from the milestone.
Trac:
Username: femme
Sponsor: N/A to N/A
Reviewer: N/A to N/A
Severity: N/A to Normal
Trac:
Cc: g.koppen@jondos.de, adrelanos@riseup.net, arthuredelstein@gmail.com to g.koppen@jondos.de, adrelanos@riseup.net, arthuredelstein@gmail.com, brade., mcsThis could be used to implement #9675 (moved) (clock skew warning) in Tor Browser.
Trac:
Keywords: small-feature needs-proposal tor-client deleted, tbb-wants small-feature needs-proposal tor-client addedReplying to femme:
Has there been any further development in this area? #17739 (moved) was merged and so the clock skew code should be somewhat consistent but it still uses the date header
No, Tor uses both the date header and NETINFO cells to trigger CLOCK_SKEW events.
and the related ticket #17728 (moved) was removed from the milestone.
Early aborts on authority connections (to check the time, but avoid downloading directory documents from them) are irrelevant to how Tor exports the clock skew to applications.
-
Trac:
Cc: g.koppen@jondos.de, adrelanos@riseup.net, arthuredelstein@gmail.com, brade., mcs to gk, adrelanos@riseup.net, arthuredelstein@gmail.com, brade, mcs Trac:
Keywords: tbb-wants small-feature needs-proposal tor-client deleted, tbb-wants small-feature needs-proposal tor-client clock-skew added
Cc: gk, adrelanos@riseup.net, arthuredelstein@gmail.com, brade, mcs to gk, adrelanos@riseup.net, arthuredelstein@gmail.com, brade, mcs, catalystTrac:
Cc: gk, adrelanos@riseup.net, arthuredelstein@gmail.com, brade, mcs, catalyst to gk, adrelanos@riseup.net, arthuredelstein@gmail.com, brade, mcs, catalyst, dmrmentioned in issue #6894 (moved)
mentioned in issue #9675 (moved)
mentioned in issue #12999 (moved)
moved to tpo/core/tor#3652 (closed)