Subject: [TLS] Let's remove gmt_unix_time from TLS

From: Nick Mathewson <[email-masked]>
Date: Wed, 11 Sep 2013 11:43:53 -0400

Hi, all.

Here's something I wrote about removing a fingerprinting opportunity
from the current TLS protocol.  I was going to just send it to the tls
list, but Ben Laurie suggested that I send it to the perpass list as
well.

I have little standards-body experience; if this ought to turn into an
RFC or something, I'd be happy to write a draft if need be.

(Tor currently plans to implement this by patching OpenSSL; any
feedback or advice would be appreciated.  The first three approaches
below are implemented in OpenSSL branches named "no_client_timestamp",
"no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git
repository at https://github.com/nmathewson/openssl .  We have long
shipped our privacy-enhanced browser with a feature like this enabled
through an NSS patch.)

====
SYNOPSIS:

In TLS as currently specified, clients and servers each send their
current view of "the time" in the clear as part of their handshake.
This provides a fingerprint that can track users in spite of other
attempts to make them untrackable.  I propose several ways to stop
doing sending this cleartext timestamp; some trivial and some more
complex.

ACKNOWLEDGEMENTS:

Thanks to Adam Langley, Ben Laurie, and everybody else who gave me
feedback here.

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.

Of course, I realize that the gmt_unix_time fingerprint is not the
only way to track a typical client as it moves from network to
network, and not the only way to distinguish different clients
behind a NAT.

BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE?

According to third-hand reports (and correct me if I'm wrong!)
gmt_unix_time 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, for two reasons:

   * On modern desktop environments, it's not really so strange to
     start two or more TLS connections within the same second.  When
     this occurs, the gmt_unix_time fails in its intended purpose of
     preventing repeated Random values.

   * Nonwithstanding the gmt_unix_time workaround, TLS in general
     does not withstand broken PRNGs.  For one example, if an
     implementation's PRNG is prone to repeating ClientRandom
     values, it is probably prone to repeating those some values as
     ephemeral Diffie-Hellman private values.

Nevertheless, if the goal of providing unique-looking output

WHY ELSE IS gmt_unix_time USED?

The consensus among implementors I've asked 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 gmt_unix_time 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.

Rationale:
   * Some implementations (like TorBrowser) are already doing this
     in practice.

   * It's sensible and simple.  Implementors are quite unlikely to
     mess it up.

PROPOSAL 2:

Suppose that we do not accept the argument about the pointlessness
of gmt_unit_time that I make above, and we want to preserve the
security it allegedly provides.

In that case, we can 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.

I do not think this 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).

PROPOSAL 3

As a hybrid alternative, one could set part of the ClientRandom
field (perhaps 12 bytes or so) based on the HMAC of the time, and
the rest of the ClientRandom field based on the PRNG:

   N = 12

   now = hires_time();
   key = get_random_bytes(32);
   mac = hmac_sha256(key, now)[0:N];  // First N bytes.
   rand = get_random_bytes(32 - N)
   Random = mac ++ rand               // concatenate.

But this seems to be getting pointlessly baroque.

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.

We 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.

---

From: Alfredo Pironti <[email-masked]>
Date: Wed, 11 Sep 2013 18:01:33 +0200

I'm in favor of proposal 1, and second the considerations about it;
essentially, a broken crypto implementation cannot be fixed by a
timestamp.

If proposal 2 (and 3) was to be implemented on a server, it would also
make DoS easier, because a cheap ClientHello (even generated with weak
randomness) would trigger an extra HMAC computation on the server,
with respect to the current server load.

Hence, relying on PRNG on both client and server sides looks like a
reasonable way to go. I also don't particularly like the asymmetry
that proposal 2 may bring: client generating randomness with HMAC, and
servers still using the timestamp in clear.

Cheers,
Alfredo

On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Russ Housley <[email-masked]>
Date: Wed, 11 Sep 2013 12:04:23 -0400

The tlsdate program (with origins in the TOR project) makes use of this value in the nonce portion of the handshake.

I think that the time is an important part of the nonce.  Even if the implementation has a crappy random number generator, the time value does a good job of ensuring that the nonce value is not repeated.  Obviously, the time value does not help with the unpredictability, but the random value is supposed to do that.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Sep 2013 09:06:49 -0700

Before we discuss mechanisms, it would be good to verify that in general
clients and servers don't become unhappy if the timestamp is radically
wrong. Has someone done measurements to verify that this is in fact
the case at a broad scale?

-Ekr

---

From: Adam Langley <[email-masked]>
Date: Wed, 11 Sep 2013 12:11:58 -0400

> the case at a broad scale?

I've observed that some small fraction of traffic to Google puts
random bytes in the first-four bytes of the nonce. It was less than
1%, but some clients clearly do this already.

Cheers

AGL

---

From: Nick Mathewson <[email-masked]>
Date: Wed, 11 Sep 2013 12:14:57 -0400

> The tlsdate program (with origins in the TOR project) makes use of this value in the nonce portion of the handshake.

That's true, and it's one reason that I would propose this as a
client-only change (by default).

>     ephemeral Diffie-Hellman private values.

In other words, sending gmt_unix_time in the clear will not save you
from a bad RNG.  (Later in the proposal, in the HMAC-based section, I
explain how sending the gmt_unix_time in the clear is not necessary to
save you from a bad RNG.)

best wishes,
-- 
Nick

---

From: Ryan Hurst <[email-masked]>
Date: Wed, 11 Sep 2013 09:19:06 -0700

I have looked at this some, network appliances such as F5s Big IP use a random value instead of time.

I recall seeing some clients also do this but I don't recall which ones.

Basically such a change should be safe.

That said as Russ has pointed out TPSDATE uses this mechanism and though it doesn't solve a broken cryptographic subsystem it is kind of belt and suspenders approach.

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
email: [email-masked]
phone: 206-650-7926

Sent from my phone, please forgive the brevity.

---

From: Nick Mathewson <[email-masked]>
Date: Wed, 11 Sep 2013 12:32:40 -0400

> the case at a broad scale?

Tor Browser has omitted this field for over five years now to no ill effect.

It would appear (assuming that I'm reading old NSS source right, which
I might not be!) that from about 2000 to 2008, Firefox was sending the
time since the process started, not the unix time, and nobody noticed
until 2007:
     https://bugzilla.mozilla.org/show_bug.cgi?id=405652

So at least on the client side, there seems to be strong evidence that
sending something other than the correct time does not cause obvious
problems in the wild.

yrs,
-- 
Nick

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Sep 2013 12:40:31 -0400 (EDT)

> I think that the time is an important part of the nonce.  Even if the implementation has a crappy random number generator, the time value does a good job of ensuring that the nonce value is not rep…

Note that tlsdate is a stowaway on board a TLS server. If we can
accomodate, then fine. But we shouldn't go out of our way to support it.

Between making tls less vulnerable to fingerprinting (which helps tor)
and supporting tlsdate, I'd opt for the former.

Paul

---

From: <[email-masked]>
Date: Wed, 11 Sep 2013 18:42:19 +0200

I can confirm that PolarSSL has no issues with receiving random data instead
of the timestamp.

On Wed, Sep 11, 2013 at 12:06 PM, Eric Rescorla <[email-masked]> wrote:
> Before we discuss mechanisms, it would be good to verify that in
> general clients and servers don't become unhappy if the timestamp is
> radically wrong. Has someone done measurements to verify that this is
> in fact the case at a broad scale?

---

From: Hanno Böck <[email-masked]>
Date: Wed, 11 Sep 2013 18:53:29 +0200

On Wed, 11 Sep 2013 11:43:53 -0400

> NAT, or privacy network.  (Tor's modified firefox avoids this by

I can't help getting the feeling that you're trying to fix the wrong
thing here. People use computers with a wrong clock. That's the problem
here. You should try to fix that and not workaround it.

My suggestion: Tor could detect on startup if the time is correct via
ntp (or even through the tor network itself with the next server). If
its not, it refuses to start unless an option like
"iknowmytimeisbrokenandidontcare" is set. For the gui, issue a warning
and an easy option to fix the time.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Nick Mathewson <[email-masked]>
Date: Wed, 11 Sep 2013 13:17:34 -0400

> here. You should try to fix that and not workaround it.

I respect your argument, and I used to think the same way myself.
Unfortunately, this doesn't seem to work so well in practice.

Consider that NTP has been around since before the web, and yet
typical consumer computers in the wild still have seconds to minutes
of clock skew.  Consider also that authenticated NTP is even less well
deployed than regular NTP, and that the possibility of
adversary-introduced clock skew reintroduces the fingerprinting
problem.

Also, consider that although fingerprinting issue is worst with large
skew, even less than a second of skew can be used to partition users:
If Alice's clock is only .1 second behind Bob's, a passive observer
can still conclude of 10% of Alice's TLS connections that they could
not have been sent by Bob, and of 10% of Bob's TLS connections that
they could not have been sent by Alice.  Over time, little
observations like this can add up to a lot of information for a clever
attacker.

Also, one could as easily argue that a broken PRNG is a problem that
needs to be fixed and not worked-around, and so gmt_unix_time should
not be supported. ;)

> and an easy option to fix the time.

This idea has some merit, although we would need to find a workaround
for the fact that the initial TLS connection to the Tor network would
leak what time the client had thought it was until their anonymous NTP
requests had told them the real time.

In the short term, however, removing gmt_unix_time seems like a much
simpler fix: it can be done with a one-line patch to OpenSSL and/or
NSS, to improve the privacy of a great number of users, even those who
do not yet have an authenticated anonymized byzantine-fault-tolerant
NTP client.

yrs,
-- 
Nick

---

From: [email-masked] (Martin Rex)
Date: Wed, 11 Sep 2013 19:41:35 +0200 (CEST)

> doing sending this cleartext timestamp; some trivial and some more

I would really appreciate a different approach to the underlying
issue, and less throwing of smoke grenades here.

If you're worried about being slightly "distinguishable" from some
other clients, then there are a lot more reliable identifiers available
in the average TLS handshake, so claiming that sending the actual local
time in ClientHello.Random.gmt_unix_time creates a severe fingerprinting
issue and sending random will solve the fingerprinting issue, is
bordering on lame for >99% of the clients.

Most of the time, repeated requests of the same TLS client can be
identified by the network connection having the same client IP address,
the TLS session proposed for resumption in ClientHello.session_id
or maybe someone still using TLS session tickets (rfc5077).

So rather than pointing to ClientHello.Random.gmt_unix_time as a
and claiming there would be a simple fix, one will likely have to
create and go through a long list of issues to determine which
features facilitate fingerprinting and tracking (cipher suites
and many TLS extensions (TLS caching extension, signature algorithms,
Next protocol negotiation, supported elliptic curves, etc.) may
all help in distinguishing clients, and would also have to be
taken care of.

-Martin

---

From: Xiaoyong Wu <[email-masked]>
Date: Wed, 11 Sep 2013 18:23:33 +0000

Yes, we have been using random values and have not got into any issues with clients/servers.

-Xiaoyong

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ryan Hurst
Sent: Wednesday, September 11, 2013 9:19 AM
To: Eric Rescorla
Cc: [email-masked]; [email-masked]; Alfredo Pironti
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
email: [email-masked]<mailto:[email-masked]>
phone: 206-650-7926

On Sep 11, 2013, at 9:06 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

-Ekr

On Wed, Sep 11, 2013 at 9:01 AM, Alfredo Pironti <[email-masked]<mailto:[email-masked]>> wrote:
I'm in favor of proposal 1, and second the considerations about it;
essentially, a broken crypto implementation cannot be fixed by a
timestamp.

Cheers,
Alfredo

On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>
_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Nick Mathewson <[email-masked]>
Date: Wed, 11 Sep 2013 23:51:20 -0400

> issue, and less throwing of smoke grenades here.

I assume good faith on your part; please do the favor of assuming good
faith on mine.

> bordering on lame for >99% of the clients.

Indeed, I never said this was a "severe" issue, or that it was the
only issue you need to solve to solve fingerprinting.  I said: "This
provides a fingerprint that can track users in spite of other attempts
to make them untrackable."

I know that reading perpass, one expects proposals to fundamentally
transform the Internet to make it more secure.  This is not such a
fundamental transformation. This is a little simple change to fix a
little simple little problem.

Of such simple little problems, client linkability is made.

> all help in distinguishing clients, and would also have to be

That's all true; disabling gmt_unix_time is by no means sufficient to
make multiple TLS clients look the same on the wire, or to prevent an
observer distinguishing TLS instances.

In Tor's case, we mitigate this by disabling some TLS features,
specifying required values for others, rotating some identifiers more
frequently than most implementations, and shipping all of our clients
with the same crypto libraries.  Most of the fingerprinting issues in
TLS can be ameliorated, for a single application, by defining a
profile that all of that application's users should share.

My issue here right now that, even *after* taking all these
precautions, the gmt_unix_time issue remains, and the TLS 1.2 RFC
doesn't make it optional.  Come heck or high water, Tor is going to
stop sending gmt_unix_time unless we find a really excellent reason to
send it.  We'd like to replace it with the best alternative we can. I
sent all the alternatives I could think of, because:

  1) I would like future versions of the TLS RFC to not require gmt_unix_time.
  2) I would like to know whether there's a truly legit reason to send
gmt_unx_time.
  3) I would like to know the best thing to do instead of gmt_unix_time.

(The IP address issue is important too, but not overriding here. The
issue here is that even after a client has changed its IP addresses
either through moving around the network or going behind a NAT or VPN
or by using an IP anonymization service, this fingerprint remains.)

-- 
Nick

---

From: [email-masked] (Martin Rex)
Date: Thu, 12 Sep 2013 06:17:33 +0200 (CEST)

Nick Mathewson wrote:
> doesn't make it optional.

Huh?  where in rfc6101, rfc2246, rfc4346 or rfc5246 do you find
_anything_at_all_ that could be remotely interpreted as a
requirement for ClientHello.Random.gmt_unix_time to have any
specific value or be within any particular value range -- 
in contradiction to what section 7.4.1.2 says?

(Same for ServerHello.Random.gmt_unix_time).

   http://tools.ietf.org/html/rfc2246#section-7.4.1.2

       Structure of this message:
           The client hello message includes a random structure, which is
           used later in the protocol.

           struct {
              uint32 gmt_unix_time;
              opaque random_bytes[28];
           } Random;

       gmt_unix_time
       The current time and date in standard UNIX 32-bit format (seconds
       since the midnight starting Jan 1, 1970, GMT) according to the
       sender's internal clock. Clocks are not required to be set
       correctly by the basic TLS Protocol; higher level or application
       protocols may define additional requirements.

Which part of "Clocks are not required to be set correctly by the
basic TLS protocol" is unclear?  This explicitly spells out that
one can send _ANY_ pattern of 32 bits as gmt_unix_time, as far as
the SSLv3&TLS protocol specifications themselves are concerned.

-Martin

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Sep 2013 09:57:39 +0100

Hi Nick, Martin,

> I assume good faith on your part; please do the favor of assuming good

I think its fair to say that Martin is not renowned for
taking a laid-back zen-like approach when making his
almost-always-good technical contributions:-)

But I didn't see him questioning good faith, I interpret
him as asking (forcefully:-) why this change is worth
doing.

(And that's a common pattern actually: someone says "if we
do X that'll make privacy a bit better" and someone else
says "but there are so many other ways to leak private
info, why bother just doing X?")

> transform the Internet to make it more secure.  

Well, boiling oceans is definitely not the intent of this list.
My guess is that overbroad proposals will get the (lack of)
attention they deserve and will wither on the vine.

> This is not such a

I agree. And seems like a worthwhile one too. BTW, since
the TLS list discussion is up and running, I don't think
there's a need to cc perpass more for this. It was a good
idea to bring it here, but I suspect for this one, we can
let the TLS wg fire ahead and get someone to write up an
I-D if one is needed for this. (My guess is it'd be useful
to have a nice short RFC that updates the relevant bit of
5246 and says why.)

> profile that all of that application's users should share.

I think that'd be a fine thing to document (and worthy of a
separate thread on the perpass list). Any chance we could get
that done? (Where "that" == document the implementation steps
to reduce fingerprinting opportunities as outlined above.)
I think it'd be really useful for folks doing other protocol
work to have an example of how its been done for Tor so they
could copy some of the relevant techniques when developing
other protocols. Ping me offlist if you'd like some help with
writing it up as an I-D and I can try find someone to help,
or if you've the energy just write it up and shoot it out
and I can help figure out how best to get it turned into an
RFC. If its already written up elsewhere then a pointer would
be good regardless.

Cheers,
S.