Do not include a timestamp in the Client/ServerHello Random field.
authorNick Mathewson <nickm@torproject.org>
Sun, 20 Oct 2013 22:03:24 +0000 (15:03 -0700)
committerBen Laurie <ben@links.org>
Mon, 21 Oct 2013 02:37:20 +0000 (03:37 +0100)
commit2016265dfbab162ec30718b5e7480add42598158
tree9025eb6e5e30a9f6cd914b06cadbe11d9646d130
parentf3efeaad540b000779277b4fc49a239529ee616e
Do not include a timestamp in the Client/ServerHello Random field.

Instead, send random bytes, unless SSL_SEND_{CLIENT,SERVER}RANDOM_MODE
is set.

This is a forward-port of commits:
  4af793036f6ef4f0a1078e5d7155426a98d50e37
  f4c93b46edb51da71f09eda99e83eaf193a33c08
  3da721dac9382c48812c8eba455528fd59af2eef
  2583270191a8b27eed303c03ece1da97b9b69fd3

While the gmt_unix_time record was added in an ostensible attempt to
mitigate the dangers of a bad RNG, its presence leaks the host's view
of the current time in the clear.  This minor leak can help
fingerprint TLS instances across networks and protocols... and what's
worse, it's doubtful thet the gmt_unix_time record does any good at
all for its intended purpose, since:

    * It's quite possible to open two TLS connections in one second.

    * If the PRNG output is prone to repeat itself, ephemeral
      handshakes (and who knows what else besides) are broken.
ssl/s23_clnt.c
ssl/s3_clnt.c
ssl/s3_srvr.c
ssl/ssl.h
ssl/ssl_locl.h