Opened 5 years ago

Last modified 3 years ago

#12999 new enhancement

Use one clock skew per URL bar domain

Reported by: arthuredelstein Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-time-skew
Cc: gk, adrelanos@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by arthuredelstein)

When #3455 lands, Tor Browser will have a separate Identity (i.e., circuit) for each URL bar domain. JavaScript clock skew fingerprinting is one way attackers can try to link Identities. Tor Browser could counter this by maintaining a separate clock skew for each URL bar domain.

When the user browses to a new URL bar domain, Tor Browser would

  1. Create a new circuit
  2. Request clock time from exit node (already tied to Identity)
  3. Store clock skew in a one-to-one mapping of skews->URL bar domains
  4. Apply clock skew to any JS clock requests under that domain

Child Tickets

Change History (7)

comment:1 Changed 5 years ago by arthuredelstein

Description: modified (diff)

comment:2 Changed 5 years ago by gk

Cc: gk added

comment:3 Changed 5 years ago by mikeperry

Keywords: tbb-fingerprinting-time-skew added; tbb-fingerprinting removed

See also #3652 and #2940.

comment:4 Changed 5 years ago by mikeperry

Parent ID: #3059

One thing that Arthur and I discussed today was adding some kind of RELAY cell command to obtain the current time from the exit. In retrospect, this also seems bad, because the exit could use this to lie to you about the current time to get you to accept an expired or invalid SSL cert, or to generally cause havock on your notion of time for a webapp.

Another option is to periodically run tlsdate-style time lookups using a helper app independent from Tor, and use that for time. I think this may actually be the sanest approach.

comment:5 in reply to:  4 Changed 5 years ago by arthuredelstein

Replying to mikeperry:

One thing that Arthur and I discussed today was adding some kind of RELAY cell command to obtain the current time from the exit. In retrospect, this also seems bad, because the exit could use this to lie to you about the current time to get you to accept an expired or invalid SSL cert, or to generally cause havock on your notion of time for a webapp.

Good point. I guess there needs to be a way to detect lying, perhaps by comparing to a time consensus. Though I'm not sure SSL cert validation needs to be using the exit node clock in any case.

Another option is to periodically run tlsdate-style time lookups using a helper app independent from Tor, and use that for time. I think this may actually be the sanest approach.

I agree this would be a simpler approach. My concern with it is that the global system time on the client might have a skew that could be used to link identities across different circuits. The worst case would be a hostile time server. I also worry that an exit node imposing an arbitrary latency to timing messages from the time server could result in a detectable clock skew in the client.

comment:6 Changed 5 years ago by proper

Cc: adrelanos@… added

comment:7 Changed 3 years ago by cypherpunks

Severity: Normal

any progress on this?

Note: See TracTickets for help on using tickets.