My guess, since Microsoft has trouble replicating this effect and it’s mostly related to internal servers, is that there is some kind of middlebox that messes with TLS traffic (one of those plug&play “HTTPS firewalls” or whatever they’re called). Because of potential interception, every device on the network has to trust these boxes completely, potentially landing their certs in the “super duper secure” key store rather than the third party CA key store they should be in.
It’s also possible one of Microsoft’s servers has gotten the time wrong or has a bug in its TLS library, but I think MS would’ve caught that already.
STS is actually a pretty good idea because NTP attacks are pretty reliable in practice. All you need is a computer on a shitty ISP that doesn’t filter outbound traffic right (allowing spoofing of reliable NTP servers) and spamming NTP packets with fake origins, pretending to be the servers for the real NTP pool. This way you can slowly force the clock to drift (limited by the standard maximum NTP offset each time) and get your outdated credentials to work again, get your old certificates and signatures to work again, and do other kinds of time-related attacks.
NTP can’t be done over TLS the same way DNS can be protected because TLS has certificates with limited validity and you don’t know the time you should use to validate them. Using TLS traffic from known-good servers is pretty smart, since every TLS handshake already sends back and forth the current system time anyway.
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.
My guess, since Microsoft has trouble replicating this effect and it’s mostly related to internal servers, is that there is some kind of middlebox that messes with TLS traffic (one of those plug&play “HTTPS firewalls” or whatever they’re called). Because of potential interception, every device on the network has to trust these boxes completely, potentially landing their certs in the “super duper secure” key store rather than the third party CA key store they should be in.
It’s also possible one of Microsoft’s servers has gotten the time wrong or has a bug in its TLS library, but I think MS would’ve caught that already.
STS is actually a pretty good idea because NTP attacks are pretty reliable in practice. All you need is a computer on a shitty ISP that doesn’t filter outbound traffic right (allowing spoofing of reliable NTP servers) and spamming NTP packets with fake origins, pretending to be the servers for the real NTP pool. This way you can slowly force the clock to drift (limited by the standard maximum NTP offset each time) and get your outdated credentials to work again, get your old certificates and signatures to work again, and do other kinds of time-related attacks.
NTP can’t be done over TLS the same way DNS can be protected because TLS has certificates with limited validity and you don’t know the time you should use to validate them. Using TLS traffic from known-good servers is pretty smart, since every TLS handshake already sends back and forth the current system time anyway.
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.