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. [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 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.
Won't this give off a fingeprintable network pattern when Tor restarts
after a failed connection because the fresh consensus hadn't been
fetched?
There is no reason to believe that these actions are different from any
Tor that is used in common setups. If someone suspends their machine and
Tor is running, there will be TCP connections are frozen in the middle.
And by the time they continue after a resume, the other side will
receive unexpected packets and reject them. (It thought the other side
timed out, now suddenly a closed connection wants to continue as if
nothing happened.) Freezing a TAILS session should result in the same
situation as freezing TBB on any other supported host.
[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
___
Tails-dev mailing list
Tails-dev@boum.org
https://mailman.boum.org/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
tails-dev-unsubscr...@boum.org.
