Opened 6 years ago

Closed 5 years ago

Last modified 3 years ago

#9767 closed defect (implemented)

Implement proposal 222: Eliminate client timestamps in Tor

Reported by: nickm Owned by:
Priority: High Milestone: Tor: 0.2.4.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client, fingerprinting, time, prop222, 2016-bug-retrospective
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I have an implementation for proposal 222 in branch "no_client_timestamps_024" in my public tor repository. It seems very simple and straightforward. The corresponding specification changes are in branch "implement_prop222" of my public torspec repository.

The corresponding 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.

Child Tickets

TicketStatusOwnerSummaryComponent
#4852closedClients send NETINFO with timeCore Tor/Tor
#7277closedtimestamp leaked in TLS client helloApplications/Tor bundles/installation

Change History (18)

comment:1 Changed 6 years ago by nickm

Status: newneeds_review

comment:2 Changed 6 years ago by nickm

Keywords: prop222 added

comment:3 Changed 6 years ago by andrea

Some thoughts:

  • Since the standard specifies the use of a timestamp, it seems unlikely to get this patch merged into OpenSSL - maybe supporting an option to disable the timestamp instead would improve the odds there?
    • It would also make an easy autoconf test for whether the OpenSSL we're building against has it; for the utility thereof, see below.
  • After the Munich meeting, ioerror and I had discussed techniques for doing this on the assumption of *not* having an OpenSSL patch. If libc is dynamically linked and we're on an ELF system, we can define a time() routine in Tor to override libc's and then dlsym(time, RTLD_NEXT) to get the real symbol from libc, so we can effectively hook the system call in *some* cases (again, this would have to be an autoconf test and couldn't be supported *portably* or necessarily on all systems).
    • Using this technique, we could selectively override time() to pass a 32-bit random value to openssl at the right point, allowing us to disable the timestamps without patching OpenSSL.

The second option is ugly enough I think we should only do it if a patched OpenSSL isn't available, but there are probably going to be plenty of machines out there where we don't get a say about the system OpenSSL. Therefore, I suggest changing the OpenSSL patch to use timestamps by default but add an option to disable them, and use an autoconf test in Tor for this. Then we have the option of adding a second test to check if we can override time() in that manner in the case that we don't have a patched OpenSSL, and can warn about timestamp fingerprinting if neither is available. Feel free to ignore if you think it's too hairy.

comment:4 Changed 6 years ago by nickm

When I last spoke to Ben, and based on my conversations on the tls-wg mailing list, I got the impression that maybe just killing off gmt_unix_time for everybody might be a winning proposition. Let's see how that goes before permanently deciding that we'll never get adoption. After all, the grounds for putting the timestamp in the standard are deeply stupid. Perhaps sanity will win? :) ... :(

As for how to do this without an openssl patch, there's also the silly approach I described in https://trac.torproject.org/projects/tor/ticket/7277#comment:8 .

But other than the openssl part, how was the Tor patch? :)

comment:5 Changed 6 years ago by andrea

As for the changes to Tor in no_client_timestamps_024:

  • c78e5b07a6a32f2de46f9c628e37e2fbc3aa90ca: this looks okay to me; I'm assuming I remember the protocol correctly and it's always possible for anyone receiving a NETINFO to know anyway whether it came from a client or relay, so this doesn't leak any new information.
  • ae0fe705dbcfba056988667c04c355f8aaa1669d: the changes file mentions INTRODUCE2 cells, but the change affects code that generates INTRODUCE1 cells at the client end.
  • 5c22af4bef9d3ce820c50b09f0ebde91b90246f9: this looks okay to me
  • 64a139f8db9515b99513d50d3a1b9f524a6f8ad3: this looks okay to me; can we get rid of the timestamps in the descriptors when we have a new HS protocol, perhaps?

comment:6 in reply to:  4 Changed 6 years ago by andrea

Replying to nickm:

When I last spoke to Ben, and based on my conversations on the tls-wg mailing list, I got the impression that maybe just killing off gmt_unix_time for everybody might be a winning proposition. Let's see how that goes before permanently deciding that we'll never get adoption. After all, the grounds for putting the timestamp in the standard are deeply stupid. Perhaps sanity will win? :) ... :(

We can hope...

As for how to do this without an openssl patch, there's also the silly approach I described in https://trac.torproject.org/projects/tor/ticket/7277#comment:8 .

Yeah, that's possible too. I'm not 100% sure off the top of my head ELF lets you get away with intercepting a call that doesn't cross library boundaries like that, but it's worth a shot.

Hmm, actually, isn't RAND_* in libcrypto and the call we need to worry about in libssl?

But other than the openssl part, how was the Tor patch? :)

See my other comment :)

comment:7 Changed 6 years ago by andrea

Further thought on TLS/SSL timestamps: if NSA can MITM the connection and forge a server certificate with an expiration date of their choice, and the client strictly tests the expiration date against the local clock, then whether the client continues the handshake also leaks information about clock skew. The client is probably fucked regardless in that case, but in the NAT/mobile client scenario under discussion it is a capability beyond just what the MITM alone would give them.

comment:8 Changed 6 years ago by nickm

Replying to andrea:

As for how to do this without an openssl patch, there's also the silly approach I described in https://trac.torproject.org/projects/tor/ticket/7277#comment:8 .

Yeah, that's possible too. I'm not 100% sure off the top of my head ELF lets you get away with intercepting a call that doesn't cross library boundaries like that, but it's worth a shot.

Hmm, actually, isn't RAND_* in libcrypto and the call we need to worry about in libssl?

The thing here is that RAND_* indirects via the openssl engines mechanism, and RAND_set_rand_method() overrides it.

That said, I am inclined to declare "remove timestamps from old openssl" orthogonal to "remove all Tor client timestamps" if we can merge this one.

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

Replying to andrea:

As for the changes to Tor in no_client_timestamps_024:

  • c78e5b07a6a32f2de46f9c628e37e2fbc3aa90ca: this looks okay to me; I'm assuming I remember the protocol correctly and it's always possible for anyone receiving a NETINFO to know anyway whether it came from a client or relay, so this doesn't leak any new information.
  • ae0fe705dbcfba056988667c04c355f8aaa1669d: the changes file mentions INTRODUCE2 cells, but the change affects code that generates INTRODUCE1 cells at the client end.

Hm. Perhaps I should just say "INTRODUCE"? The INTRODUCE(n) cell has an INTRODUCE(3-n) cell inside it, but remembering whether n=2 or n=1 in that sentence is beyond me.

  • 5c22af4bef9d3ce820c50b09f0ebde91b90246f9: this looks okay to me
  • 64a139f8db9515b99513d50d3a1b9f524a6f8ad3: this looks okay to me; can we get rid of the timestamps in the descriptors when we have a new HS protocol, perhaps?

I hope so. Rather, let's pitch a fit if anybody proposes one.

It sounds like the Tor part of this is mergeable? Into 0.2.4? :)

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

Replying to andrea:

Further thought on TLS/SSL timestamps: if NSA can MITM the connection and forge a server certificate with an expiration date of their choice, and the client strictly tests the expiration date against the local clock, then whether the client continues the handshake also leaks information about clock skew. The client is probably fucked regardless in that case, but in the NAT/mobile client scenario under discussion it is a capability beyond just what the MITM alone would give them.

Sure; for this patch, I'm not hypothesizing a fast cheap RSA1024-breaker, but a simple time-recorder. We should defend against the former too (see proposal 220), but the latter is easier to exploit, and simpler to fix, I think?

comment:11 Changed 6 years ago by nickm

Replying to andrea:

Further thought on TLS/SSL timestamps: if NSA can MITM the connection and forge a server certificate with an expiration date of their choice, and the client strictly tests the expiration date against the local clock, then whether the client continues the handshake also leaks information about clock skew. The client is probably fucked regardless in that case, but in the NAT/mobile client scenario under discussion it is a capability beyond just what the MITM alone would give them.

Sure; for this patch, I'm not hypothesizing a fast cheap RSA1024-breaker, but a simple time-recorder. We should defend against the former too (see proposal 220), but the latter is easier to exploit, and simpler to fix, I think?

comment:12 in reply to:  9 Changed 6 years ago by andrea

Replying to nickm:

Replying to andrea:

As for the changes to Tor in no_client_timestamps_024:

  • c78e5b07a6a32f2de46f9c628e37e2fbc3aa90ca: this looks okay to me; I'm assuming I remember the protocol correctly and it's always possible for anyone receiving a NETINFO to know anyway whether it came from a client or relay, so this doesn't leak any new information.
  • ae0fe705dbcfba056988667c04c355f8aaa1669d: the changes file mentions INTRODUCE2 cells, but the change affects code that generates INTRODUCE1 cells at the client end.

Hm. Perhaps I should just say "INTRODUCE"? The INTRODUCE(n) cell has an INTRODUCE(3-n) cell inside it, but remembering whether n=2 or n=1 in that sentence is beyond me.

  • 5c22af4bef9d3ce820c50b09f0ebde91b90246f9: this looks okay to me
  • 64a139f8db9515b99513d50d3a1b9f524a6f8ad3: this looks okay to me; can we get rid of the timestamps in the descriptors when we have a new HS protocol, perhaps?

I hope so. Rather, let's pitch a fit if anybody proposes one.

It sounds like the Tor part of this is mergeable? Into 0.2.4? :)

Yeah, agree on mergeability there.

comment:13 in reply to:  10 Changed 6 years ago by andrea

Replying to nickm:

Replying to andrea:

Further thought on TLS/SSL timestamps: if NSA can MITM the connection and forge a server certificate with an expiration date of their choice, and the client strictly tests the expiration date against the local clock, then whether the client continues the handshake also leaks information about clock skew. The client is probably fucked regardless in that case, but in the NAT/mobile client scenario under discussion it is a capability beyond just what the MITM alone would give them.

Sure; for this patch, I'm not hypothesizing a fast cheap RSA1024-breaker, but a simple time-recorder. We should defend against the former too (see proposal 220), but the latter is easier to exploit, and simpler to fix, I think?

Yeah, I think so too - still need to read proposal 220. I was just musing on whether we really need to actually check the expiration date on the relay's server certificate I guess.

comment:14 Changed 6 years ago by nickm

Okay, merged this patch and the corresponding proposal patch into 0.2.4. Leaving this ticket open till we have the openssl patch done.

comment:15 Changed 6 years ago by arma

To be clear, there is no longer a tor patch that needs_review for 0.2.4 here?

comment:16 Changed 6 years ago by nickm

Correct.

comment:17 Changed 5 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

This is done, except for turning off the timestamp in hidden service intro cells (#7803) once 0.2.2 is dead.

comment:18 Changed 3 years ago by nickm

Keywords: 2016-bug-retrospective added

Mark the last set of tickets that came up in my last-few-years changelog hand-review.

Note: See TracTickets for help on using tickets.