273
this post was submitted on 25 Aug 2023
273 points (97.9% liked)
Technology
33602 readers
232 users here now
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.