405652 - In the TLS ClientHello message the gmt_unix_time is incorrect

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P2)

Description

[fms09]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.8.1.8) Gecko/20071015 SUSE/2.0.0.8-1.1 Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.8.1.8) Gecko/20071015 SUSE/2.0.0.8-1.1 Firefox/2.0.0.8

In the TLS ClientHello message the gmt_unix_time sent is 
Jan 26, 1970, 06:44:27 but the correct time was 
Nov 27, 2007, 17:39:35

Reproducible: Always

Steps to Reproduce:
1. Open wireshark or a similar program and capture the packets
2. Open a SSL/TLS session with mozilla
3. In wireshark, edit the clien hello message 
Actual Results:  
Jan 26, 1970, 06:44:27

Expected Results:  
Nov 27, 2007, 17:39:35

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

Please provide evidence.

Comment 2

[fms09]

Attachment: Detailed Handsake

Frames 14 and 16
Frames 84 and 87

Comment 3

[Nelson Bolyard (seldom reads bugmail)]

You've provided evidence that the program that produced this output thinks
the dates are in 1970.  But what is the actual data on the wire?  
Can you provide Hex dumps of the messages in question?

Comment 4

[fms09]

Attachment: Data captured with wireshark

I do not know if I have understood well that it is what it requests to me. 
I attach the packages captured with wireshark.

Comment 5

[Julien Pierre]

Reporter,

The data you posted is only the output of the program, not the source bytes. Nelson is asking you to post the bytes that went on the wire in the client hello message.

Comment 6

[Julien Pierre]

I ran NSS' ssltap against NSS' tstclnt in TLS mode and got the following.

         ClientHelloV3 {
            client_version = {3, 1}
            random = {...}
   0: 00 00 8b 02  fc 8f 4f 46  e6 59 23 9a  4a a7 7a fa  | ......OF.Y#.J.z.
  10: 0d 72 4c 7b  9a a0 78 7a  bf af 22 e0  9a 08 be ab  | .rL{..xz..".....
            session ID = {
                length = 0
                contents = {..}
            }

ssltap doesn't decode the time . It just shows 32 bytes of random data. RFC2246 says :

      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.

   random_bytes
       28 bytes generated by a secure random number generator.

So, the first four bytes shown above must be the time. It is indeed a very small  number, 8b 02, which I believe would be sometime on January 1, 1970. The number was increasing in each subsequent test, but remained small.

The number returned by the SSL server I was testing against, www.etrade.com, was 47 58 fc a2 , and increasing in subsequent tests. That appears to be an accurate value for today's date.

So, I am marking this bug confirmed. It would also be nice to enhance ssltap to isolate the time bytes and display them in the v3 hello messages.

Comment 7

[Amnon Aaronsohn]

The bug is in the ssl3_GetNewRandom function in ssl3con.c: it uses the PRIntervalTime type which can't represent absolute times.

I'm attaching an untested patch which should fix this. It would be nice to have it fixed by ff3. 

To the previous poster: the bug doesn't seem to be marked "confirmed".

Comment 8

[Amnon Aaronsohn]

Attachment: send the correct TLS gmt_unix_time field

Comment 9

[Julien Pierre]

Amnonaar, re: comment 7, I had changed the status of this bug from UNCONFIRMED to NEW on 12/07/2007. You can click on view bug activity to see that. Thanks for the patch.

Comment 10

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 308284 [details] [diff] [review]
send the correct TLS gmt_unix_time field 

Please Use ssl_Time instead of time.

Comment 11

[Amnon Aaronsohn]

Attachment: send the correct TLS gmt_unix_time field

The patch was tested and seems to work (Wireshark displays the correct time in the Client Hello message sent by Firefox).

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Comment on attachment 309936 [details] [diff] [review]
send the correct TLS gmt_unix_time field

r=nelson.
Julien or I will commit it for you.

Comment 13

[Julien Pierre]

I checked in the fix to the trunk :

Checking in ssl3con.c;
/cvsroot/mozilla/security/nss/lib/ssl/ssl3con.c,v  <--  ssl3con.c
new revision: 1.112; previous revision: 1.111
done

Comment 14

[Nelson Bolyard (seldom reads bugmail)]

I will add, for posterity, that the code was that way deliberately.
On some systems, time() is an expensive call.  It had measurable impact
on performance.  In the IETF SSL/TLS working group, it was concluded long
ago that it is improper for an implementation to rely on the specific value
of this field.  

So, the change is made now, but I won't be surprised if this change is 
identified in the next major performance project as being the cause of a
loss of performance, and pressure will come to bear to undo it.

Comment 15

[Amnon Aaronsohn]

Thanks for accepting the patch. Regarding the performance problems, I hope that if this behavior is changed it will be only for the systems that have these problems. Also, it can probably be worked around (e.g. cache the current time for the next N seconds based on PR_IntervalNow()'s return value).

Comment 16

[Mike Perry]

This bug is also a privacy issue. The uptime field doubles as a unique identifier that can potentially be used by ad networks and others to correlate users independent of cookie settings or IP address.

Is it possible to get a backport to 1.8.1.x? I doubt this will turn up as a perf issue, given that the field is only constructed once per ssl connection.

Comment 17

[Nelson Bolyard (seldom reads bugmail)]

Of course, the SSL session ID, sent in every handshake, also serves as a 
unique identifier, and it's a whole lot easier to use than one that 
increases linearly with time.  So, fixing this bug will do nothing to 
improve privacy.

Comment 18

[u307648]

While the session ID is in principle the better UID, you cannot easily group different sessions IDs together.
The uptime might be used to correlate several sessions.
E.g. assume someone monitoring traffic on the net. First it gives information about the used software, you don't blend into the whole sum of all visitors of a specific site. It may give you information about the behaviour of the user (does he reboot regularly or does he probably work from a server-type machine with long uptimes?). If you observe a session at a time with uptime y and observe 313 seconds later a new session with uptime y+313 it is a hint that it is the same machine. Especially if you have further information or suspect already a specific machine (maybe even in your local net?), it can be used to identify someone on the net, even if he uses something like Tor for anonymizing traffic. 

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

Dominik, What you're calling "uptime" is actually process lifetime.  
It doesn't measure how long the box (OS) has been up.  It measures how long
the process (e.g., browser) has been running, which is likely to be less time 
than the OS uptime because browsers get restarted more often (because they 
are less stable :).  And during that lifetime, the session ID between the 
client and any given server is likely to not change for up to 24 hours at a time.  

Now, process uptime lets you correlate SSL handshakes from the same client 
to different servers, if you can capture the traffic from that client.  
But then, so does IP address, which is even more likely to be stable than
process or even OS uptime.  

If changing this uptime really took away an avenue of attack (even passive
attack, such as monitoring) I'd be more inclined to say it's work doing 
extra work.  But I'm convinced that it is just one of many ways to do the 
same thing, and is one of the more difficult of those ways.  The other ways
aren't going to go away any time soon.  So there's really not much point.

Comment 20

[u307648]

Are you sure, that it is always a process uptime/livetime? I have something like 22 days there and the value does not decrease upon restarting Firefox. In fact, after restarting Firefox the value given is increased by the time elapsed since the last https-Request (done with the old FF session). (Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8) But admittedly it does not match my machine uptime, there is a difference of about 7 days between them.
You are right, the IP address is usually much easier to use. But this concerns here originate from the Tor community (Tor is an anonymizing network) and then the user doesn't have a constant IP. FF is popular among Tor users and the Tor project additionally tries to hide quite a bunch of information FF could give an adversary (also see the addon TorButton). I would not say, there is no point in it.
Your point about the session ID for identifying users returning to the same website by the website or a third party is nonetheless a very good one. :-/

Comment 21

[Mike Perry]

The Torbutton Firefox extension has done a lot of work to eliminate these unique identifiers. Please see: https://torbutton.torproject.org/dev/design/#adversary
and https://torbutton.torproject.org/dev/design/#requirements.

It just so happens that this is currently the best (read: most dangerous and useful to an adversary) long-term unique identifier the Tor project is aware of for correlating user activity.

And as far as the session ID is concerned, watching Firefox ssl in wireshark seems to indicate the session ID turns over pretty frequently so long as all ssl connections to a given host are closed. The uptime property, however, is a unique identifier that persists for a user until they reboot their machine (which can be a long, long time for users who suspend/hibernate as opposed to fully powering off).

Comment 22

[Nelson Bolyard (seldom reads bugmail)]

(In reply to comment #21)
> [snip] watching Firefox ssl in wireshark seems to indicate the session ID 
> turns over pretty frequently so long as all ssl connections to a given host 
> are closed. 

That behavior would indicate a server that is not using SSL session caching
to its advantage, and so is doing much more expensive public/private key 
processing than is necessary.  Perhaps some servers have that issue, but one
would not expect that most servers would behave that way.