[tor-bugs] #8751 [TorBrowserButton]: do something about TLS HELLO gmt_unix_time

[Tor Bug Tracker & Wiki]

#8751: do something about TLS HELLO gmt_unix_time
------------------------------+---------------------------------------------
 Reporter:  proper            |          Owner:  mikeperry
     Type:  defect            |         Status:  new      
 Priority:  major             |      Milestone:           
Component:  TorBrowserButton  |        Version:           
 Keywords:                    |         Parent:  #3059    
   Points:                    |   Actualpoints:           
------------------------------+---------------------------------------------
 = Assumptions =

 When not using Tor...
 - For example, when using wget or Firefox, the user's ISP and destination
 server can watch TLS hello and thus learn about the client's clock.
 - Many updaters in background are also using TLS.

 When using Tor...
 - For example, when using TBB, Tor exit nodes, the ISP's of Tor exit nodes
 and destination servers can see client's clock.

 These are the assumptions. [3] Please tell me if they are wrong.

 = Problem =

 NTP server admins can willingly or if their server gets compromised and
 any man-in-the-middle can tamper with NTP replies and therefore introduce
 a unique clock skew.

 Almost no one is using authenticated NTP, because there are no
 instructions in a forum or blog how to enable NTP authentication.
 Therefore almost everyone uses standard configuration and is at risk.

 Also due to a clock defect, low battery, clock can skew without tampering
 with NTP.

 Since the browser [1] transmits it in TLS HELLO (gmt_unix_time), it can be
 used to track individual users. For example, a clock skew of +/-30 minutes
 may not worry the user ("That damn clock is wrong again. I use my watch
 instead.") but could identify the user even when using Tor.

 Also adversaries who didn't introduce the clock skew could use it to
 identify users. If the user visits a website under adversary control 2
 without Tor for some non-anonymous activity, it knows the clock skew.
 Later, if the user visits another website under adversary control, it can
 see the same clock skew, which is at least a strong anonymity set
 reduction.

 = Solution =

 RFC 5245 says.

 > Clocks are not required to be set correctly by the basic TLS protocol;

 So perhaps get ride of it entirely (replace it with some fixed time)?

 > higher-level or application protocols may define additional
 requirements.

 Whatever that means.

 = Implementation =

 I have no idea.

 = Related =

 #3059

 = Footnotes =

 ,,
 [1] Also #1517 "Provide JS with reduced time precision" wouldn't help
 much, since it wouldn't do something about bigger clock skews.
 [2] Nowadays with services like google analytics and facebook like button,
 there are servers which are present on a high percentage of all websites.
 [3] Haven't used wireshark, but read http://www.moserware.com/2009/06
 /first-few-milliseconds-of-https.html and http://wiki.wireshark.org/SSL.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8751>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online