Jacob Appelbaum:
> If I were to reinvent the wheel without having read any of tordate's
> source, I would:
>
> open the consensus or the cached-microdescs
> parse the absolute minimum time
> stat the respective file to see the last possible atime/mtime/ctime
> pick the later time of the two
> jump the clock forward again
What in case the directory authority is not reachable (censored area)?
Is the parasitic approach future proof anyway? Won't that cost the
remote server admins cpu load and traffic?
What if the remote server admins install some "intelligent" filter,
which blocks Tor? (for other unrelated spam/ddos issues)
Why trust and get the time of some remote server admins who are not
really willing to run a network time server? They most likely get their
own time over unauthenticated NTP. Getting time from TLS is more a hack
than a replacement for non-existing tcp, authenticated and distributed NTP.
Instead I can imagine a better approach. The Tor network and Tor client
itself are a good base for an alternative, safe, non-SSL-CA-dependant,
Tor-safe, authenticated time server network.
Parse Tor consensus approach... Well, what if that format changes in
future? Why not build the required features into Tor itself?
My suggestions are here:
https://trac.torproject.org/projects/tor/ticket/6894
https://trac.torproject.org/projects/tor/ticket/8170
If Chrome OS where to connect to Tor because of the new time sync
feature of Tor, that makes connections to Tor less suspicious and adds
more Tor clients.
Just sharing my thoughts. Not complaining. Whatever you decide, thanks
for your work! :)
Cheers!
adrelanos
