timestamp leaked in TLS client hello
From #4852 (moved) (Clients send NETINFO with time):
The guard can read client's timestamp from TLS client hello.
Can you do something about it?
Activity
Interesting idea. Probably this would require an OpenSSL patch. The impact here, if I understand right, would be that the guard (or anybody else who can see the initial connection) can probabilistically track a client with a skewed clock even as it changes IPs.
Of course, the set of guards also makes that possible right now, as does the NETINFO time, as other stuff probably does too.
The worse affect of the timestamp in the TLS hello would be the TLS hello in application connections sent over Tor. If TBB can't do anything about that, it's a probabilistic linkability issue for skewed clients.
Trac:
Keywords: N/A deleted, tor-client added
Replying to nickm:
Interesting idea. Probably this would require an OpenSSL patch. The impact here, if I understand right, would be that the guard (or anybody else who can see the initial connection) can probabilistically track a client with a skewed clock even as it changes IPs.
Of course, the set of guards also makes that possible right now, as does the NETINFO time, as other stuff probably does too.
True. Although, the whole set of guards of a client is not visible by a single evil guard (in contrast with NETINFO or the TLS handshake).
Talking about NETINFO, is the
timestampon theNETINFOcell of clients actually used anywhere? It seems like no:if (labs(apparent_skew) > NETINFO_NOTICE_SKEW && router_get_by_id_digest(chan->conn->identity_digest)) {I know that we like protocol properties to be symmetric on clients and servers, but since we agree that timestamp leaking is potentially dangerous, would it make sense to wipe the NETINFO
timestampin the case of clients/bridges?-
Replying to asn:
I know that we like protocol properties to be symmetric on clients and servers, but since we agree that timestamp leaking is potentially dangerous, would it make sense to wipe the NETINFO
timestampin the case of clients/bridges?That's #4852 (moved). The comment there was saying, if I interpret correctly "Why even bother removing the timestamp from netinfo so long as the TLS timestamp still exists? What would that achieve?" arma's response there seems plausible to me.
-
Sounds good. I guess the next step to figure out is whether we can do callback hacks to play with OpenSSL's
ssl3_state_st.client_randomat the correct time.Maybe another long-term step would be to write a #5488 (moved)-like proposal in an attempt to persuade implementations and IETF to stop putting their timestamps inside
{Client,Server}Hello.random? Why does it happen anyway? The reasos is not explained in RFC5246. -
The only options I see for doing this without a SSL patch are pretty questionable:
-
Override time() when ssl3_client_hello() might be getting called,
-
Override RAND_bytes and RAND_pseudo_bytes to see when they're getting called with a pointer that happens to be 4 bytes from the start of a the s3->client_random field of an SSL object, and if so, overwrite the first 4 bytes as well.
To do the first one, you need a portable way to override libc/system calls.
To do the second one, you can override RAND_* with RAND_set_rand_method. You'd want to have the rand_engine implementation call the methods from RAND_get_rand_method. To keep track of which pointers deserve the "write 4 extra bytes" treatment, you'd want to do something clever with some data structure to determine whether a pointer matches the value of some ssl->s3->client_random + 4. I think that client_random is allocated when the SSL structure is allocated, and that it doesn't change, but we should definitely examine that more closely.
Be aware that multiple ClientHello messages can get sent for a single SSL, if renegotiation happens.
-
Hey, isn't the timestamp in the clienthello (and serverhello), and thus visible to external observers too?
So a) a passive adversary of the client can do this tracking too, not just the guard
and b) if we stop putting (something similar to) the time there, we have introduced an "is it tor tls or other tls" identifier.
-
Replying to arma:
Hey, isn't the timestamp in the clienthello (and serverhello), and thus visible to external observers too?
That's what we're talking about here, I believe.
So a) a passive adversary of the client can do this tracking too, not just the guard
Yes.
and b) if we stop putting (something similar to) the time there, we have introduced an "is it tor tls or other tls" identifier.
Yes. The only way to avoid having a fingerprint while at the same time avoiding skew-based tracking would to ensure that all Tor client clocks are synchonized with high accuracy. The next-best thing would be to round off with high granularity, but I'm not sure that's actually a win.
-
I have an OpenSSL patch (done on top of 1.0.1e) is in on https://github.com/nmathewson/openssl.git , with signed tag openssl-101e-no-gmt-time-v1 ; it needs testing and review. I've submitted it to a friendly openssl committer for evaluation; I'll see what he says.
Trac:
Status: new to needs_review
Milestone: Tor: 0.2.5.x-final to Tor: 0.2.4.x-final -
Trac:
Parent: N/A to #9767 (moved) -
OpenSSL has merged my openssl patches. Later versions of 1.0.1 and later will have gmt_unix_time off by default.
To get this patch before 1.0.1f comes out (and who knows when that will be), just use my https://github.com/nmathewson/openssl/tree/no_gmt_unix_time branch. It has a few patches on top of 1.0.1e.
To get the OpenSSL people to release 1.0.1f, the historically most reliable method has been to discover a new vulnerability. ;)
Trac:
Component: Tor to Tor bundles/installation mentioned in issue #17911 (moved)
mentioned in issue tpo/core/tor#17911 (closed)
