[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [DONATE]

Tails-dev malinglist secure timesync proposal

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] http://donncha.is/2013/05/trawling-tor-hidden-services/
[2] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=rend-spec.txt

Working on this one at the moment.

Revised this. But rather blindly. Because I haven’t read rend spec yet or throughly thought this through. However, it should now be a bit clearer.

References may be wrong. Reference [2] isn’t in the text.

Not sure if I missed any improvements from https://lists.torproject.org/pipermail/tor-talk/2014-September/034724.html.

Feel free to improve this again, feel free to wait a bit more for answers on tor-talk, feel free to post it on tails-dev then.

If they can be convinced, very likely I can be convinced as well.

[hr]

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 synchronizer process running on the system.

To overcome this, here is a suggestion for a reassessment of the tordate approach, to overcome the problems mentioned above and the shortcomings.

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 a time synchronizer daemon 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.
  • According to rend-spec, the damage is much limited (only and 18 hour
    window) before HSDir Authorities reject these forgeries.
  • There does exist stable, available and friendly HS besides the TPO one that was taken down. The only addresses that will be used are those of trusted organizations that will not carry out the forging attacks described above. 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 averaged to get a more 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 asynchronously.

With 1400 HSAuth Dirs on the network, I don’t think there will be much of a load problem.

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. Then after Tor connects the time is further adjusted using HS descriptors.

[1] http://donncha.is/2013/05/trawling-tor-hidden-services/
[2] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=rend-spec.txt

I try to communicate in ways, so others not involved into our recent discussions will be able to reenact what has been discussed here. So, for anyone wondering why a whole passage was removed without replacement, see:
https://github.com/Whonix/Whonix/issues/320)

Thanks for improving it. I added a few more changes then posted to the list.

https://mailman.boum.org/pipermail/tails-dev/2014-September/006876.html

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Investors] [Priority Support] [Professional Support]