If you read the article it’s explained that some SSL implementations put random data in the time field (OpenSSL was given as an example). Microsoft knows about this and so needs a certain number of closely matching timestamps to be confident about the new time to change the system time. However, if you get particularly unlucky with a string of random timestamps that match, you end up with a random time.
And most NTP clients already handle this by not changing the time automatically if it would be too much of a jump. Microsoft is trying to fix what’s not broken.
I was under the impression that this system mostly used Microsoft services, but if they take all TLS handshakes as input then that does make more sense. The fix also seems rather obvious (only use Microsoft connections with certificate pinning for time source input, since Windows will talk to Microsoft every minute anyway).
Even if openssl/boringssl was spec compliant as Microsoft assumed (hasn’t been for almost a decade of course) you’d still want to make sure the data is all close enough just in case you hit a few misconfigured servers. Otherwise you’d get a viral effect where badly configured servers start infecting each other as they communicate.
If you read the article it’s explained that some SSL implementations put random data in the time field (OpenSSL was given as an example). Microsoft knows about this and so needs a certain number of closely matching timestamps to be confident about the new time to change the system time. However, if you get particularly unlucky with a string of random timestamps that match, you end up with a random time.
Yes, it’s a dog shit implementation to rely 3rd parties to make guarantees about their data that they never agreed to.
Linux and MacOS handle this just fine. Why blame SSL when you’re the one using it wrong?
And most NTP clients already handle this by not changing the time automatically if it would be too much of a jump. Microsoft is trying to fix what’s not broken.
I was under the impression that this system mostly used Microsoft services, but if they take all TLS handshakes as input then that does make more sense. The fix also seems rather obvious (only use Microsoft connections with certificate pinning for time source input, since Windows will talk to Microsoft every minute anyway).
Even if openssl/boringssl was spec compliant as Microsoft assumed (hasn’t been for almost a decade of course) you’d still want to make sure the data is all close enough just in case you hit a few misconfigured servers. Otherwise you’d get a viral effect where badly configured servers start infecting each other as they communicate.