Authenticated TLS “contraints” in ntpd(8)
1–9 of 9 posts
Re: Authenticated TLS “contraints” in ntpd(8)
#2That is a really wonderful extension to ntpd. Simple, robust, with the server implementation for "free".
Re: Authenticated TLS “contraints” in ntpd(8)
#3This is very similar to the functionality provided by tlsdate (https://github.com/ioerror/tlsdate). They appear to have eschewed tlsdate's default approach of using the timestamp from the handshake in favor of using the `Date:` field, which tlsdate also supports. It would be interesting to see whether the randomization of TLS timestamps in modern implementations of TLS might mean that tlsdate's default mode is no longer useful. Either way, it's really cool to see this sort of functionality being included in ntpd by default!
Re: Authenticated TLS “contraints” in ntpd(8)
#4typo in submission title
Re: Authenticated TLS “contraints” in ntpd(8)
#5typo in submission title
typo in mail subject
Re: Authenticated TLS “contraints” in ntpd(8)
#6This is very similar to the functionality provided by tlsdate ( https://github.com/ioerror/tlsdate ). They appear to have eschewed tlsdate's default approach of using the timestamp from the handshake in favor of using the `Date:` field, which tlsdate also supports. It would be interesting to see whether the randomization of TLS timestamps in modern implementations of TLS might mean that tlsdate's default mode is no l…
[deleted]
Re: Authenticated TLS “contraints” in ntpd(8)
#7This is very similar to the functionality provided by tlsdate ( https://github.com/ioerror/tlsdate ). They appear to have eschewed tlsdate's default approach of using the timestamp from the handshake in favor of using the `Date:` field, which tlsdate also supports. It would be interesting to see whether the randomization of TLS timestamps in modern implementations of TLS might mean that tlsdate's default mode is no l…
openntpd has been nothing but trouble for me, but when I switched to djb clockspeed instead, it made things better. Here's a script that runs on GFiber devices, which uses tlsdate securely for the initial timewarp, and djb clockspeed thereafter. Since switching to this we have had extremely accurate timekeeping.
https://gfiber.googlesource.com/buildroot/+/master/fs/skelet...
Re: Authenticated TLS “contraints” in ntpd(8)
#8This is very similar to the functionality provided by tlsdate ( https://github.com/ioerror/tlsdate ). They appear to have eschewed tlsdate's default approach of using the timestamp from the handshake in favor of using the `Date:` field, which tlsdate also supports. It would be interesting to see whether the randomization of TLS timestamps in modern implementations of TLS might mean that tlsdate's default mode is no l…
openntpd has been nothing but trouble for me, but when I switched to djb clockspeed instead, it made things better. Here's a script that runs on GFiber devices, which uses tlsdate securely for the initial timewarp, and djb clockspeed thereafter. Since switching to this we have had extremely accurate timekeeping. https://gfiber.googlesource.com/buildroot/+/master/fs/skelet...
Which version were you using? If you were using the portable version, I heard openntpd-portable wasn't updated for quite a while, and fell behind...missing out on some really big improvements from more recent versions.
The portable tree has apparently recently been picked up again by a new maintainer.
Re: Authenticated TLS “contraints” in ntpd(8)
#9This is very similar to the functionality provided by tlsdate ( https://github.com/ioerror/tlsdate ). They appear to have eschewed tlsdate's default approach of using the timestamp from the handshake in favor of using the `Date:` field, which tlsdate also supports. It would be interesting to see whether the randomization of TLS timestamps in modern implementations of TLS might mean that tlsdate's default mode is no l…
openntpd has been nothing but trouble for me, but when I switched to djb clockspeed instead, it made things better. Here's a script that runs on GFiber devices, which uses tlsdate securely for the initial timewarp, and djb clockspeed thereafter. Since switching to this we have had extremely accurate timekeeping. https://gfiber.googlesource.com/buildroot/+/master/fs/skelet...
If you don't mind elaborating a bit more on the troubles you had, I might be able to help get things fixed for a later release.
I have had some trouble on Solaris getting the adjtime olddelta value to settle quickly, but haven't heard of any other issues. Even if you're happy with clockspeed, it might help other users to identify the problem.