Use one clock skew per URL bar domain
When legacy/trac#3455 (moved) 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
- Create a new circuit
- Request clock time from exit node (already tied to Identity)
- Store clock skew in a one-to-one mapping of skews->URL bar domains
- Apply clock skew to any JS clock requests under that domain
Activity
Trac:
Description: When legacy/trac#3455 (moved) 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
- Create a new circuit
- Request clock skew from exit node (already tied to Identity)
- Store clock skew in a skew->URL bar domain mapping
- Apply clock skew to any JS clock requests under that domain
to
When legacy/trac#3455 (moved) 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
- Create a new circuit
- Request clock time from exit node (already tied to Identity)
- Store clock skew in a one-to-one mapping of skews->URL bar domains
- Apply clock skew to any JS clock requests under that domain
See also legacy/trac#3652 (moved) and legacy/trac#2940 (moved).
Trac:
Keywords: tbb-fingerprinting deleted, tbb-fingerprinting-time-skew added-
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.
Trac:
Parent: legacy/trac#3059 (moved) to N/A 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.
Trac:
Cc: gk to gk, adrelanos@riseup.netmoved from legacy/trac#12999 (moved)
added Feature label and removed 1 deleted label
added Fingerprinting label and removed 1 deleted label
