NetBSD-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: ntpdate(8) and unbound(8) dependencies during boot

On 2020-10-17 05:54, Martin Husemann wrote:
On Sat, Oct 17, 2020 at 01:16:57PM +0100, Sad Clouds wrote:
I'm not an expert on NTP, but what sort of information do you think it
could leak that could compromise your system security? There are ways
for hackers to abuse NTP protocol, but that is where you should be using
NTS extensions.
No, this is not about NTP, but leaking the information that an RTC-less
device booted and did the magic handshake to get time correct (by sending
standard queries to cloudflare).

I actually do run a local ntpd inside the protected network, which is
why I'm happy with hard coded or dhcp provided (local) IPs.


Hi Martin,

There is no "magic handshake", it's a standard TLS handshake, and the traffic should look the same as any old DNS over HTTPS query (as done by default by Firefox, Chrome and a number of other products now adays).

There's also nothing that "leaks" the fact you have an RTC-less machine - by default, the HTTPS constraint checks are performed for all machines, in an attempt to mitigate possible NTP man-in-the-middle attacks (see my previous email that mentions the two complementary use case scenarios for this solution). Also, nobody seems to have a problem using fixed IP addresses for DNS servers (whats the alternative?) So I don't think including a couple trustworthy providers (that are easily changeable if desired) would be that big of a deal. The paranoiacs over in OpenBSD land seemed to think this solution was adequate, so I image any privacy or information disclosure possibilities would have been addressed. As I see it, it's just a couple TLS handshakes which look identical to DNS over HTTPS traffic (which use the ubiquitous port 443). Unless there's something I'm missing (or that the paranoiacs failed to address) I'm pretty sure this is one of the only viable solutions for combating the chicken and egg clock problem TODAY.



Home | Main Index | Thread Index | Old Index