Autor: Jacob Appelbaum Data: A: The Tails public development discussion list CC: tor-talk Assumpte: Re: [Tails-dev] [tor-talk] secure and simple network time (hack)
Maxim Kammerer: > On Thu, Apr 18, 2013 at 1:18 AM, Jacob Appelbaum <jacob@???> wrote:
>> 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.
>
> There are now apparently enough openly accessible and stable
> authenticated NTP servers around to rely on them in a distro. The
> problem is that authenticated NTP protocol (more precisely, its
> asymmetric crypto Autokey variant) does not support NAT traversal in
> either the server *or* the client, since both IP addresses are signed.
> I guess the reason is that NTP has no clear distinction between client
> and server.
>
There are a lot of issues with ntp - my favorite is that a basic (eg:
shipping with OS X) ntp client will hit the default Apple NTP servers.
These servers may be queried by external third parties and the
information returned is enough to attack any client who is using the
server. The information returned includes the client ip, the udp source
port, the udp destination and of course, the attacker knows the server
ip. This means that an attacker may now send packets as the server -
thus the attacker can even attack ntp clients behind a nat or a stateful
firewall. UDP is part of the problem, the lack of the client/server
authentication is another part of the problem, the fact that the ntp
clients aren't written with security in mind is yet another problem.
This says nothing of an attacker who controls the network path - such an
attacker has an even larger number of attacks and ntp falls over for
nearly all of them. The entire idea of a False Ticker relies on the
notion that you have some path to some honest ntp server, so you can
have some phase locked loops and determine which of the set is wrong or
bad. Good luck without authentication, integrity, confidentiality in
syncing that clock...
So again, I understand you don't like my hack and I'd just like to be
clear - we can't use the current ntp tools to safely, securely or
anonymously set our clock in nearly any use case. I'm working on
alternative ways to do it and I'm using IETF compliant protocols on the
network to ensure that it is actually more than a silly hack that only
works for a while.
