adrelanos:
> 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)?
>
Well, if we have a file on the disk, we don't even have to touch the
network to jump the clock, right?
> Is the parasitic approach future proof anyway? Won't that cost the
> remote server admins cpu load and traffic?
Probably and probably not?
>
> What if the remote server admins install some "intelligent" filter,
> which blocks Tor? (for other unrelated spam/ddos issues)
Which server admins? People offering TLS?
>
> 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.
>
Yeah, I'm aware. Really, well aware. People keep telling me over and
over again - it's not demotivating though as zero of those people
suggest replacements, write the code and then show that it is actually
as secure or more secure.
Whenever a less friendly person gives me a hard time about the obvious
futility of tlsdate, I think:
"Let me know how your ntp replacement project goes and I'll gladly use
it when my shitty one trick pony isn't beating the pants off of your arm
chair hacking."
I'd say I'm kidding but really, we need a secure network time client and
we need one badly. If we don't have one, we can't hold certain
assumptions to be correct and entire systems can be broken. There is
also the attack surface and architecture of other ntp/ntp-like clients.
> 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.
Sure - We have discussed extending the Tor protocol specifically and
also with a small set of changes we can already extract the remote
server time. We can even do this anonymously and quite easily. That
won't solve it for everyone else using who isn't using Tor... which is
basically the entire planet! :)
>
> Parse Tor consensus approach... Well, what if that format changes in
> future? Why not build the required features into Tor itself?
I'll update tlsdate and fix it? The stat of the file will give us a time
reference in any case - that won't change unless posix changes and if
that happens, I am fine with porting tlsdate to this future system. :)
>
> 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.
That isn't happening - they can't figure out a UX way to offer a full
Tor client. They did ship Tor in their base OS for a while but basically
the UI/UX issues made them remove the binary from the system - elly, my
co-author on tlsdate was the one who ported it over and maintained it.
>
> Just sharing my thoughts. Not complaining. Whatever you decide, thanks
> for your work! :)
I've commented on
https://trac.torproject.org/projects/tor/ticket/6894
and I'll try to implement it after I write a proposal.
All the best,
Jacob
