The current secure timesyncing solution has some serious implications for security because they rely on an untrusted model using clearnet servers. Even though SSL is used, the broken CA model negates its protection and the adversary could easily MITM requests and send fake replies or potentially exploit the time synchornizer process running on the system.
To overcome this, a reassessment of the tordate/anondate approach was made and improved upon, to overcome the problems mentioned above and the shortcomings that led to its deprecation.
Problems and solutions:
Couldn’t the consensus data be replayed?
Not possible if forcing Tor to depend only on verified consensus data. Tor doesn’t depend on CAs and SSL is safe from cryptanalysis meaning no MITM attack is possible when communication with DirAuths
But what if a bridge feeds the client a stale consensus?
We have come up with a technique to check against this very kind of attack. In short, it involves fetching consensus data through the Tor bridge connection and cross referencing it with what the bridge gave us. If its off, the user will be warned and the stale data will be replaced by the fresh set.
If the time is off Tor attempts to connect but fails, then anondate fetches a consensus and Tor is restarted. This pattern is fingerprinatble!
Yes logically this signalling pattern could be looked for by DPI boxes sitting on the network.
The fix is to have some way, for example Systemd, or something similar if Debian stable doesn’t have it yet, constantly monitor the Tor process’ connection, and if it detects any drops, it would block Tor from reconnection attempts and triggers sdwdate/anondate fetches a fresh valid consensus and sets the time appropriately allowing Tor to connect normally.
Then after Tor connects the time is further adjusted using HS descriptors.
Use of Hidden Service descriptors to obtain more accurate time:
There are some problems with using Directory Authority consensus data, the only one IMO is the fuzzy window of three hours which makes it harder to set a realistic time.
My proposal is to have sdwdate query the DHT for specific Hidden Service descriptors from the HSDir Authorities without actually connecting to them and calculate a more finegrained time to set. Here is why i think its a good idea:
Descriptors contain a timestamp field which shows the time they are generated.Time reported is number of microseconds since 1970.
Descriptors are signed by the HS and cannot be spoofed by the HSDirAuth.
Descriptors are refreshed hourly. [1]
A "malicious" HS that want to fool our time check has to go out of its way and forge the timestamp in its descriptor. If they are doing this by just running with a wrong clock, they will make themselves inaccessible.
The damage is much limited (only and 18 hour window not 7 days) before HSDir Authorities reject these forgeries. [2]
There does exist stable, available and friendly HS besides the TPO one that was taken down. The only addresses that will be used are ones in the "pal" pool. These will be Whistleblowing and Freedom friendly sites. Some suggestions: Wikileaks, RiseUp (each service they provide has a unique HS address assigned), TheNewyorker's SecureDrop service and probably more.
The way to go about this is to fetch descriptors without connecting.
The timestamps will be compared for to get an accurate reading.
A high time resolution is possible, we can pinpoint within that one hour range the probable time because each server was started at a different time than the other so it uploads its descriptor at asyncronously.
With 1400 HSAuth Dirs on the network, I don’t think there will be much of a load problem.
[1] Trawling Tor Hidden Service – Mapping the DHT | Donncha Ó Cearbhaill
[2] torspec - Tor's protocol specifications