41–50 of 120 posts
Earlier quoted context omitted.
There is also systemd-timesyncd and Chrony.
systemd-timesyncd is not much of an alternative. It is simply an sntp client, it does not serve time to other hosts nor can it use reference clocks.
Earlier quoted context omitted.
ntp network traffic can be authenticated with symetric keys or autokey currently, and with NTS in the future. Many national labs support authenticated time for free and even more provide authenticated ntp for a fee.[1] Moreover if you care about time you can use a cheap GPS+PPS[2] as a reference or splurge and get a CDMA card. Your "replace it with tlsdate" solution makes little sense; at some point you need NTP or P…
You need encrypted time sync when you don't have a local trusted source, and to reduce your susceptibility to to pseudo MITM attacks (though, having just said that, you're right - UTC isn't a secret, so an attacker could just use that. However, and I'm not sure the answer, the key may be in how much information is leaked to the NTP server on current clock drift state. That being said, I'm fairly sure Kerberos etc don…
I do not understand the need for confidentiality.
[1]: http://www.nist.gov/pml/div688/grp40/auth-ntp.cfm
[2]: https://www.nrc-cnrc.gc.ca/eng/solutions/advisory/calibratio...
Earlier quoted context omitted.
You could circumvent certificate revocations by replaying expired OCSP Staple responses that say a certificate is not revoked. You could also cause expired certificates to be accepted, which limits the utility of short-lived certs as a means of protecting against key compromise. And as hannob said, you can circumvent HSTS by setting the time in the future, causing all HSTS entries to be expired.
Pretty persistent attacker. It should take something like 100 days to push the clock off by one day.
This is interesting timing, I was just in the freenode #linux channel yesterday asking about security issues with NTP. I got told it was a non-issue and that I was "tilting at windmills". I have been using chronyd in Alpine linux to good effect so far, but have really been wondering how bad it would be if I just turned it all off.
having a host clock that is out of sync can be incredibly troublesome, especially if you have more than one system.
The best solution is not to use ntp anyway. It's an unencrypted, unauthenticated protocol vulnerable to Man in the Middle attacks. There was a pretty neat attack presented at BH Europe circumventing HSTS with a MitM-attack on NTP. Better just replace it with tlsdate.
ntp network traffic can be authenticated with symetric keys or autokey currently, and with NTS in the future. Many national labs support authenticated time for free and even more provide authenticated ntp for a fee.[1] Moreover if you care about time you can use a cheap GPS+PPS[2] as a reference or splurge and get a CDMA card. Your "replace it with tlsdate" solution makes little sense; at some point you need NTP or P…
A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process. Geez, in a time sync program? Nothing is safe anymore.
ntpd is a, uh, rather large time sync program.
Might want to check out OpenBSD's OpenNTPD: http://www.openntpd.org/
I've talked to several developers about the state of NTP daemons and neither OpenNTPD nor DragonflyBSD's dntpd are suitable replacements. Neither of those support NTP Authentication nor do they have all of the required algorithms required for proper timekeeping.
I hear something like that a lot, yet all my systems run openntpd and all of them are keeping proper time without issue. What exactly is so not proper about it, and which algorithm exactly does it need to be "proper"?
Earlier quoted context omitted.
having a host clock that is out of sync can be incredibly troublesome, especially if you have more than one system.
Especially if your distributed database relies on clocks, as some do.
When I did my distributed DB course way back when I was at uni it was all Lamport or vector clocks...
Bad timing for such a vulnerability with the holidays and everything. I don't have time for that.