Opened 7 years ago

Closed 6 years ago

#7277 closed defect (fixed)

timestamp leaked in TLS client hello

Reported by: proper Owned by:
Priority: Medium Milestone:
Component: Applications/Tor bundles/installation Version:
Severity: Keywords: tor-client
Cc: proper, arma, nickm Actual Points:
Parent ID: #9767 Points:
Reviewer: Sponsor:

Description

From #4852 (Clients send NETINFO with time):

The guard can read client's timestamp from TLS client hello.

Can you do something about it?

Child Tickets

Attachments (1)

tls-clientrandom-proposal (4.2 KB) - added by nickm 6 years ago.

Download all attachments as: .zip

Change History (22)

comment:1 Changed 7 years ago by nickm

Keywords: tor-client added

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.

comment:2 in reply to:  1 ; Changed 7 years ago by asn

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 timestamp on the NETINFO cell 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 timestamp in the case of clients/bridges?

comment:3 in reply to:  2 Changed 7 years ago by nickm

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 timestamp in the case of clients/bridges?

That's #4852. 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.

comment:4 Changed 7 years ago by asn

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_random at the correct time.

Maybe another long-term step would be to write a #5488-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.

comment:5 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: unspecified

comment:6 Changed 6 years ago by nickm

Looks like folks are interested in this again. I'm pulling it into 0.2.5 so we don't forget it.

comment:7 Changed 6 years ago by nickm

Milestone: Tor: unspecifiedTor: 0.2.5.x-final

comment:8 Changed 6 years ago by nickm

The only options I see for doing this without a SSL patch are pretty questionable:

1) Override time() when ssl3_client_hello() might be getting called,

2) 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.

comment:9 Changed 6 years ago by arma

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.

comment:10 in reply to:  9 Changed 6 years ago by nickm

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.

Changed 6 years ago by nickm

Attachment: tls-clientrandom-proposal added

comment:11 Changed 6 years ago by nickm

Just attached a little proposal document so I have something to tell implementors that we're targeting.

comment:12 Changed 6 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.4.x-final
Status: newneeds_review

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.

comment:13 Changed 6 years ago by nickm

Parent ID: #9767

comment:14 Changed 6 years ago by asn

The OpenSSL patch looks good to me.

comment:15 Changed 6 years ago by nickm

Component: TorTor bundles/installation

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. ;)

comment:16 Changed 6 years ago by nickm

Milestone: Tor: 0.2.4.x-final

comment:17 Changed 6 years ago by mikeperry

Keywords: MikePerry201311 added

comment:18 Changed 6 years ago by mikeperry

Ok, I have switched TBB3 over to this branch + signed tag. It will be used in the next 3.0 release.

comment:19 Changed 6 years ago by mikeperry

Keywords: MikePerry201311 removed

comment:20 Changed 6 years ago by nickm

TBB has this fixed; OpenSSL has this fixed; NSS has this fixed. Any reason not to call this fixed?

comment:21 Changed 6 years ago by mikeperry

Resolution: fixed
Status: needs_reviewclosed

Let's call it fixed then.

Note: See TracTickets for help on using tickets.