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

Nick Mathewson <> Wed, 11 September 2013 17:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2FFA211E80D3 for <>; Wed, 11 Sep 2013 10:18:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.059
X-Spam-Status: No, score=-1.059 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, NO_RELAYS=-0.001, SARE_LWSHORTT=1.24]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NNYarIVW8jJB for <>; Wed, 11 Sep 2013 10:18:14 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c01::232]) by (Postfix) with ESMTP id 9B51611E81EA for <>; Wed, 11 Sep 2013 10:17:34 -0700 (PDT)
Received: by with SMTP id r5so5403021qcx.23 for <>; Wed, 11 Sep 2013 10:17:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=v2PbisQoJia3DGskho6Kgl1k6rzvayUiBP7iH3fyJQw=; b=ECw/0InN4HCbzGPvNuzyn31RLZVRuMZAY1h1LRsGjnsZJIE05k4gjWDigJAdz9lGXB /jXuRUYOOCMl6f4ZQonEfqeQgKfJDVX578jsdMNFw4vvGYBjMDu/ez/PUeyTCnaXLDE2 NJkR09euXdSyhtjT9ZTpQhGkj9uSx4hVCe8pMPjKDWBq8F64ZrwiQq9K3IJtLTxk4D9r C0JSdAI3ySZXV/1j+pdjOWWnSybFgnkoVBxCa+34wrTKEwiCCOP3ysj0EQ+Yzd2xp1ZG q5DeEUelHu4zHEz2nLfuDar+TMMIWfuQGZRgXtPoUP6ELTUwSnu+SsvMSOUlkW35D0tD Ynww==
MIME-Version: 1.0
X-Received: by with SMTP id f10mr5238195qcs.16.1378919854287; Wed, 11 Sep 2013 10:17:34 -0700 (PDT)
Received: by with HTTP; Wed, 11 Sep 2013 10:17:34 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Wed, 11 Sep 2013 13:17:34 -0400
X-Google-Sender-Auth: Vf5XxFFFEukN4IA3X-dJBeyQs68
Message-ID: <>
From: Nick Mathewson <>
To: =?ISO-8859-1?Q?Hanno_B=F6ck?= <>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 11 Sep 2013 17:18:16 -0000

On Wed, Sep 11, 2013 at 12:53 PM, Hanno Böck <> wrote:
> On Wed, 11 Sep 2013 11:43:53 -0400
> Nick Mathewson <> wrote:
>> 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.)
> 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.

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

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

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

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

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.