4 ms·

tl;dr: machine is unable synchronize its clock because it won't trust the NTP server's DNSSEC certificate because its clock isn't synchronized. Oof.

iforgotpassword 2y ago
Yeah in hindsight it might not be the best idea to enable this for ntp.org, especially when the ntp protocol itself isn't secure.
kakkoko 2y ago
https://github.com/systemd/systemd/commit/abf4e5c1d3ad767bc0ed67883e8e4d916af095ec https://github.com/systemd/systemd/commit/abf4e5c1d3ad767bc0... While systemd-timesyncd contains a workaround for this, chrony does not seem to.
jandrese 2y ago
This is the perennial problem with trying to secure NTP. I've also seen people suggest that we just use HTTPS for time sync, not realizing that if your clocks are too far off you can't make a HTTPS connection.
- toast0 2y ago
  It takes more creativity, but you can start to make a narrowing range of times if you're careful. You'll have to ignore DNSSEC time based validation while you start up, of course... Start with the last time you were properly synced: it's most likely less than a month behind then. Then take a sampling of certificates offered from well known sites. If the certificates validate, other than time, no reasonable CA that you trust issues not-before dates in the future, so it's not before the most recent not-before date in a certificate. It's probably not much after the not-after dates either, well know sites tend to replace their certificates (but maybe you're getting MITMed with a compromised, old certificate). Maybe ask for OSCP stapling, which should get you a more narrow range of times. I think OSCP responses are valid for a week? But if you get several from different https servers, chances are good you'll narrow the range. In the case as suggested that the time was only off by about a day, IMHO, something is seriously wrong if it can't get to sync from there, but I guess I'm not really surprised either.
- creeble 2y ago
  You can use plain HTTP for time sync. Almost all HTTP servers respond with a time header.
  - jandrese 2y ago
    The whole point of the exercise was to make it secure though. If you don't care about MITM attackers then NTP works great.
    - numpad0 2y ago
      I don't get the supposed security aspect of getting false time. Hacker gives you 1980-01-01 or 4096-13-32 and mess up CRL and ruin your day...how. Years ago I've tried privilege escalation exploit to play with a phone and it involved rolling back date to unexpire signature, so I know there is exploit potential, but it... it just feels like RTC bootstrap problem should be something solvable.
    - creeble 2y ago
      Isn't that a provably pointless exercise though? Security protocols (at least the ones in common use) require certificates or keys that eventually expire, because of the risk of a permanent key being compromised. If they expire, the protocol needs time. QED.
deleted 2y ago
[deleted]

iforgotpassword 2y ago

Yeah in hindsight it might not be the best idea to enable this for ntp.org, especially when the ntp protocol itself isn't secure.

kakkoko 2y ago

https://github.com/systemd/systemd/commit/abf4e5c1d3ad767bc0ed67883e8e4d916af095ec https://github.com/systemd/systemd/commit/abf4e5c1d3ad767bc0... While systemd-timesyncd contains a workaround for this, chrony does not seem to.

jandrese 2y ago

This is the perennial problem with trying to secure NTP. I've also seen people suggest that we just use HTTPS for time sync, not realizing that if your clocks are too far off you can't make a HTTPS connection.

toast0 2y ago
It takes more creativity, but you can start to make a narrowing range of times if you're careful. You'll have to ignore DNSSEC time based validation while you start up, of course... Start with the last time you were properly synced: it's most likely less than a month behind then. Then take a sampling of certificates offered from well known sites. If the certificates validate, other than time, no reasonable CA that you trust issues not-before dates in the future, so it's not before the most recent not-before date in a certificate. It's probably not much after the not-after dates either, well know sites tend to replace their certificates (but maybe you're getting MITMed with a compromised, old certificate). Maybe ask for OSCP stapling, which should get you a more narrow range of times. I think OSCP responses are valid for a week? But if you get several from different https servers, chances are good you'll narrow the range. In the case as suggested that the time was only off by about a day, IMHO, something is seriously wrong if it can't get to sync from there, but I guess I'm not really surprised either.
creeble 2y ago
You can use plain HTTP for time sync. Almost all HTTP servers respond with a time header.
- jandrese 2y ago
  The whole point of the exercise was to make it secure though. If you don't care about MITM attackers then NTP works great.
  - numpad0 2y ago
    I don't get the supposed security aspect of getting false time. Hacker gives you 1980-01-01 or 4096-13-32 and mess up CRL and ruin your day...how. Years ago I've tried privilege escalation exploit to play with a phone and it involved rolling back date to unexpire signature, so I know there is exploit potential, but it... it just feels like RTC bootstrap problem should be something solvable.
  - creeble 2y ago
    Isn't that a provably pointless exercise though? Security protocols (at least the ones in common use) require certificates or keys that eventually expire, because of the risk of a permanent key being compromised. If they expire, the protocol needs time. QED.

deleted 2y ago

[deleted]