[tor-commits] [torspec/master] Proposal 222-remove-client-timestamps
nickm at torproject.org
nickm at torproject.org
Thu Aug 22 15:45:30 UTC 2013
commit 6a0694fea80168bb8d6a90fda4bf0c0af1bfe2ca
Author: Nick Mathewson <nickm at torproject.org>
Date: Thu Aug 22 11:45:26 2013 -0400
Proposal 222-remove-client-timestamps
---
proposals/222-remove-client-timestamps.txt | 244 ++++++++++++++++++++++++++++
1 file changed, 244 insertions(+)
diff --git a/proposals/222-remove-client-timestamps.txt b/proposals/222-remove-client-timestamps.txt
new file mode 100644
index 0000000..dd84bf2
--- /dev/null
+++ b/proposals/222-remove-client-timestamps.txt
@@ -0,0 +1,244 @@
+Filename: 222-remove-client-timestamps.txt
+Title: Stop sending client timestamps
+Authors: Nick Mathewson
+Created: 22 August 2013
+Target: 0.2.5.x
+Status: Open
+
+0. Summary
+
+ There are a few places in Tor where clients and servers send
+ timestamps. I list them and discuss how to eliminate them.
+
+1. Introduction
+
+ Despite this late date, many hosts aren't running NTP and
+ don't have very well synchronized clocks. Even more hosts
+ aren't running a secure NTP; it's probably easy to
+ desynchronize target hosts.
+
+ Given all of this, it's probably a fingerprinting opportunity
+ whenever clients send their view of the current time.
+ Let's try to avoid that.
+
+ I'm also going to list the places where servers send their
+ view of the current time, and propose that we eliminate some
+ of those.
+
+ Scope: This proposal is about eliminating passive timestamp
+ exposure, not about tricky active detection mechanisms where
+ you do something like offering a client a large number of
+ about-to-expire/just-expired certificates to see which ones
+ they accept.
+
+2. The Tor link protocol
+
+2.1. NETINFO (client and server)
+
+ NETINFO cells specify that both parties include a 4-byte
+ timestamp.
+
+ Instead, let's say that clients should set this timestamp to
+ 0. Nothing currently looks at a client's setting for this
+ field, so this change should be safe.
+
+2.2. AUTHENTICATE (server)
+
+ The AUTHENTICATE cell is not ordinarily sent by clients. It
+ contains an 8-byte timestamp and a 16-byte random value.
+ Instead, let's replace both with a 24-byte (truncated) HMAC of
+ the current time, using a random key.
+
+ This will achieve the goal of including a timestamp in the
+ cell (preventing replays even in the presence of bad entropy),
+ while at the same time not including the time here.
+
+2.3. TLS
+
+2.3.1. ClientRandom in the TLS handshake
+
+ See TLS proposal in appendix A.
+
+ This presents a TLS fingerprinting/censorship opportunity. I
+ propose that we investigate whether "random " or "zero" is
+ more common on the wire, choose that, and lobby for changes to
+ TLS implementations.
+
+2.3.2. Certificate validity intervals
+
+ Servers use the current time in setting certificate validity
+ for their initial certificates. They randomize this value
+ somewhat. I propose that we don't change this, since it's a
+ server-only issue, and already somewhat mitigated.
+
+3. Directory protocol
+
+3.1. Published
+
+ This field in descriptors is generated by servers only; I
+ propose no change.
+
+3.2. The Date header
+
+ This HTTP header is sent by directory servers only; I propose
+ no change.
+
+4. The hidden service protocol
+
+4.1. Descriptor publication time
+
+ Hidden service descriptors include a publication time. I
+ propose that we round this time down to the nearest N minutes,
+ perhaps for N=30.
+
+4.2. INTRODUCE2 cell timestamp
+
+ INTRODUCE2 cells once limited the duration of their replay
+ caches by including a timestamp in the INTRODUCE2 cells. Since
+ 0.2.3.9-alpha, this timestamp is ignored, and key lifetime is
+ used instead.
+
+ When we determine that no hidden services are running on
+ 0.2.2.x (and really, no hidden services should be running on
+ 0.2.2.x!), we can simply send 0 instead. (See ticket #7803).
+
+ This might be a good place to use a consensus parameter, so
+ that a large number of clients switch at the same time.
+
+ I claim this would be suitable for backport to 0.2.4.
+
+5. The application layer
+
+ The application layer is mostly out of scope for this proposal,
+ except:
+
+ TorBrowser already (I hear) drops the timestamp from the
+ ClientRandom field in TLS. We should encourage other TLS
+ applications to do so. (See Appendix A.)
+
+
+
+=================================================================
+APPENDIX A: "Let's replace gmt_unix_time in TLS"
+
+PROBLEM:
+
+The gmt_unix_time field in the Random field in the TLS handshake
+provides a way for an observer to fingerprint clients.
+
+Despite the late date, much of the world is still not
+synchronized to the second via an ntp-like service. This means
+that different clients have different views of the current time,
+which provides a fingerprint that helps to track and distinguish
+them. This fingerprint is useful for tracking clients as they
+move around. It can also distinguish clients using a single VPN,
+NAT, or privacy network. (Tor's modified firefox avoids this by
+not sending the time.)
+
+Worse, some implementations don't send the current time, but the
+process time, or the computer's uptime, both of which are far
+more distinguishing than the current time() value.
+
+The information fingerprint here is strong enough to uniquely
+identify some TLS users (the ones whose clocks are hours off).
+Even for the ones whose clocks are mostly right (within a second
+or two), the field leaks a bit of information, and it only takes
+so many bits to make a user unique.
+
+
+WHY gmt_unix_time IN THE FIRST PLACE?
+
+According to third-hand reports -- (and correct me if I'm wrong!)
+it was introduced in SSL 3.0 to prevent complete failure in cases
+where the PRNG was completely broken, by making a part of the
+Random field that would definitely vary between TLS handshakes.
+
+I doubt that this goal is really achieved: on modern desktop
+environments, it's not really so strange to start two TLS
+connections within the same second.
+
+WHY ELSE IS gmt_unix_time USED?
+
+The consensus among implementors seems to be that it's unwise to
+depend on any particular value or interpretation for the field.
+The TLS 1.2 standard, RFC 5246, says that "Clocks are not
+required to be set correctly by the basic TLS protocol;
+higher-level or application protocols may define additional
+requirements."
+
+Some implementations set the entire field randomly; this appears
+not to have broken TLS on the internet.
+
+At least one tool (tlsdate) uses the server-side value of the
+field as an authenticated view of the current time.
+
+
+
+PROPOSAL 1:
+
+Declare that implementations MAY replace gmt_unix_time either
+with four more random bytes, or four bytes of zeroes.
+
+Make your implementation just do that.
+
+(Rationale: some implementations (like TorBrowser) are already
+doing this in practice. It's sensible and simple. You're
+unlikely to mess it up, or cause trouble.)
+
+
+
+PROPOSAL 2:
+
+Okay, if you really want to preserve the security allegedly
+provided by gmt_unix_time, allow the following approach instead:
+
+Set the Random field, not to 32 bytes from your PRNG, but to the
+HMAC-SHA256 of any high resolution timer that you have, using 32
+bytes from your PRNG as a key. In other words, replace this:
+
+ Random.gmt_unix_time = time();
+ Random.random_bytes = get_random_bytes(28)
+
+with this:
+
+ now = hires_time(); // clock_gettime(), or concatenate time()
+ // with a CPU timer, or process
+ // uptime, or whatever.
+ key = get_random_bytes(32);
+ Random = hmac_sha256(key, now);
+
+This approach is better than the status quo on the following
+counts:
+
+ * It doesn't leak your view of the current time, assuming that
+ your PRNG isn't busted.
+
+ * It actually fixes the problem that gmt_unix_time purported to
+ fix, by using a high-resolution time that's much less likely to
+ be used twice. Even if the PRNG is broken, the value is still
+ nonrepeating.
+
+It is not worse than the status quo:
+
+ * It is unpredictable from an attacker's POV, assuming that the
+ PRNG works. (Because an HMAC, even of known data, with an
+ unknown random key is supposed to look random).
+
+
+CONSIDERATIONS:
+
+I'd personally suggest proposal 1 (just set the field at random) for
+most users. Yes, it makes things a little worse if your PRNG can
+generate repeat values... but nearly everything in cryptography
+fails if your PRNG is broken.
+
+
+You might want to apply this fix on clients only. With a few
+exceptions (like hidden services) the server's view of the current
+time is not sensitive.
+
+
+Implementors might want to make this feature optional and
+on-by-default, just in case some higher-level application protocol
+really does depend on it.
+==================================================================
More information about the tor-commits
mailing list