3 ms·

As pointed out by jwilk, this comes from the "Date:" HTTP header, NOT the TLS timestamp. To clarify, they aren't intended to be exact or high-precision, like NT

As pointed out by jwilk, this comes from the "Date:" HTTP header, NOT the TLS timestamp. To clarify, they aren't intended to be exact or high-precision, like NTP timestamps. They are simply meant to give the NTP client some confidence that the (unauthenticated) timestamps being received from NTP servers/peers are accurate (and not being manipulated by an attacker). OpenNTPD supports both the singular and plural versions [0] of the directive and they operate in the same fashion as chrony's "server" and "pool" directives do (i.e. single vs. multiple hosts). With several such sources configured, outliers here can also be easily detected. Personally, I use several sources across many different organizations (U.S. government, U.S. tech companies, foreign entities, and my own servers) and it gives me much more confidence that an attacker can't manipulate the time on any of the hosts under my control. Please do reconsider adding this feature! If you'd like, I'd be more than happy to open a bug/file a feature request/whatever. [0]: https://man.openbsd.org/ntpd.conf https://man.openbsd.org/ntpd.conf

xyzzy_plugh 9y ago
This is a good point. There is a bit of a chicken-egg issue if the system time is set improperly such that you can't perform a secure TLS handshake. The issue we were concerned with is factory resets (say you resold the appliance or had issues) would accept old certificates. Malicious actors could use a brief window to exploit the system and perform permanent modifications that could withstand factory resets. IoT is especially scary, since often the first authority is a local Wi-Fi network. Users can easily be deceived to configure the wrong network, and become exploited. Additionally, users can easily exploit system clocks in many products to install custom firmware which, when resold or returned may then be passed on to other users. Does Amazon reflash all consumer electronics that are returned? Lastly, we decided to use a combination of HTTPS, certificate pinning, and client certificates to fetch a remote timestamp. We also use other, signed timestamps when available, but permanently record the most accurate time we suspect we have received. Devices cannot rewind prior to this, so if you have a device that has been offline for four or five years, you may be vulnerable, but chances are you are very vulnerable at that point anyways. If your device connects at least once a year, you should be good. Most devices connect constantly throughout the day.

xyzzy_plugh 9y ago

This is a good point. There is a bit of a chicken-egg issue if the system time is set improperly such that you can't perform a secure TLS handshake. The issue we were concerned with is factory resets (say you resold the appliance or had issues) would accept old certificates. Malicious actors could use a brief window to exploit the system and perform permanent modifications that could withstand factory resets. IoT is especially scary, since often the first authority is a local Wi-Fi network. Users can easily be deceived to configure the wrong network, and become exploited. Additionally, users can easily exploit system clocks in many products to install custom firmware which, when resold or returned may then be passed on to other users. Does Amazon reflash all consumer electronics that are returned? Lastly, we decided to use a combination of HTTPS, certificate pinning, and client certificates to fetch a remote timestamp. We also use other, signed timestamps when available, but permanently record the most accurate time we suspect we have received. Devices cannot rewind prior to this, so if you have a device that has been offline for four or five years, you may be vulnerable, but chances are you are very vulnerable at that point anyways. If your device connects at least once a year, you should be good. Most devices connect constantly throughout the day.