Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Windows feature that resets system clocks based on random data is wreaking havoc

arstechnica.com

Post reply on HN
Print view View original

141–150 of 169 posts

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#141

Post by oskarw85 »

yetanotherloss wrote: post #33
deepsun wrote: post #28

Earlier quoted context omitted.

It's already discussed in the article -- because to determine that weather.gov connection is sound and not hacked, you first need to check its certificate expiration date. Chicken/Egg problem.

That's the point, if you can't trust the connection, stop trying to come up with more complicated ways to use the untrustable connection and accept that there is no safe way to update time.

That means your server could not serve HTTPS traffic at all, because you need valid timestamp for that.

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#142

Post by oskarw85 »

In my opinion writing that Microsoft fucked up where clearly other software puts bogus data in timestamp fields is laughable. Shit goes in - shit goes out.

I think MS should improve implementation in two ways: - ask known trusted sources (like their own servers) for SSL timestamp - use that timestamp only internally (as opposed to system-wide) to acquire valid NTP timestamp

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#143

Post by SAI_Peregrinus »

RetroTechie wrote: post #81
HPsquared wrote: post #20

Earlier quoted context omitted.

Computers have a lot more temperature variations than a typical quartz watch. In the absence of temperature correction, they'll be less accurate.

Enter the temperature compensated crystal oscillator (TXCO). A few $ at most should get you one. This shouldn't be overkill for a server dedicated to timekeeping on a large company network, right? In a datacenter one could even go for a matchbox sized atomic clock. Last I checked (years ago) such a miracle device could be had for ~$1500. Then: how often does atomic clock (or even TXCO) fail, in practice? My guess: on…

I've got a GPS-disciplined Oven Controlled Crystal Oscillator (OCXO) hooked up to a raspberry Pi running Chrony on my home network. It provides a pretty good time source (and more importantly for me a pretty good 10MHz reference). There are rack-mount 1U NTP servers built for the purpose for about what you estimate.

Most atomic clocks will have 20+ year lifetimes. OCXOs age out a good bit faster, but they're rather cheap (<$200 for ones good enough to provide holdover for a GPS module). TCXOs don't age as quickly (they're not literally in an oven), I'm not sure how long they can be expected to last.

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#144

Post by kelseyfrog »

londons_explore wrote: post #66

I wonder if you could use this 'feature' to exploit a system? Set up a bunch of servers all over the internet with innocuous web pages. Get all of them to include in their SSL headers the exact identical timestamp of July 5th 1998. Then get the user to connect to all those domains (eg. with a page with a bunch of iframes). The Secure Time service will see that lots of remote servers all agree with high confidence tha…

You can, just not the one you think.

If you're a big enough customer, and you contrive a way to rely on this bug, then you've hacked the Microsoft backwards compatibility commitment. They'll have to preserve the functionality in perpetuum.

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#145

Post by 93po »

ewoodrich wrote: post #93
jmuguy wrote: post #12

Windows Time bullshit was one of the most annoying things I dealt with during my years as an IT guy. Registering and unregistering w32time, trying different NTP servers. Trying to figure out why domain systems werent getting their time from the DC. It always felt so... stupid. Surely having the correct time on a device isnt that complicated. Turns out, its not, unless you're on Windows. Somewhat ironic that these day…

I have a Windows work laptop that sometimes drifts up to 10 minutes off the correct time despite time/date settings saying it has synced every day. It won't even let me correct the time because of an enterprise policy requiring it to use network time. Then one day it will be back to the correct time and the drift cycle begins anew.

I find some humor in this being somewhat familiar with the history of clocks and watches. Forever the battle was making the most accurate time pieces possible, with wrist watches eventually reaching a few seconds per day variance before digital watches took over. And new we have something trillions of times more complicated and is performing worse

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#146

Post by solardev »

bob-09 wrote: post #100
akira2501 wrote: post #86

Earlier quoted context omitted.

There are public users and owner users. Specifically, you don't trust input from public users. You absolutely should trust input from owner users, or if you won't by default for some reason, you absolutely should give them the option to do so. Primarily, you should be giving them the choice as to what their system will do when it cannot reliably determine the actual time. The alternative is to pretend that you can so…

If your goal is to phase out local accounts and force microsoft.com logins as part of the computer setup, being able to trust your certificates seems like a prerequisite to being able to trust your users. And the correct time is a prerequisite to trusting your certificates.

This makes no sense..? If the admin wants to change the clock to something else and make their certs invalid, they can always do so. It's just for getting an initial handshake, and then after that NTP should keep working (at least until the next reset with a dead CMOS battery).

There's no way for the server to accurately determine the client's hardware clock, barring some sort of user-hostile hardware clock with a nuclear battery or hardened GPS or radio time receiver or something.

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#147

Post by arthur2e5 »

ewoodrich wrote: post #93
jmuguy wrote: post #12

Windows Time bullshit was one of the most annoying things I dealt with during my years as an IT guy. Registering and unregistering w32time, trying different NTP servers. Trying to figure out why domain systems werent getting their time from the DC. It always felt so... stupid. Surely having the correct time on a device isnt that complicated. Turns out, its not, unless you're on Windows. Somewhat ironic that these day…

I have a Windows work laptop that sometimes drifts up to 10 minutes off the correct time despite time/date settings saying it has synced every day. It won't even let me correct the time because of an enterprise policy requiring it to use network time. Then one day it will be back to the correct time and the drift cycle begins anew.

There are ways said to circumvent the enterprise policy on the autosync side, like unregistering win32tm or deleting all servers from the registry. No idea about setting the time though…

(A smarter time daemon like chrony would've kept track of the RTC drift.)

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#148

Post by biogene »

JohnFen wrote: post #58
pmontra wrote: post #55

Earlier quoted context omitted.

From the article > “The false assumption is that most SSL implementations return the server time,” Simen said. “This was probably true in a Microsoft-only ecosystem back when they implemented it, but at that time [when STS was introduced], OpenSSL was already sending random data instead.” And they link the reason for sending random data at https://mailarchive.ietf.org/arch/msg/tls/_clS-TIIlZUcid_2S4... The post start…

Yes, I read that. I think that if you're making mission-critical systems rely on nonguaranteed behavior from systems you don't control, then it's a Bad Idea.

The point is that it was guaranteed behavior before the spec was changed. As an aside, I do find it amusing that the memo was co-authored by a Googler. Google has the best fingerprinting & tracking tech baked into their core products. I guess they don't want competition! :)

https://www.ietf.org/archive/id/draft-mathewson-no-gmtunixti...

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#149

Post by extraduder_ire »

jasonfarnon wrote: post #114
macintux wrote: post #112

Earlier quoted context omitted.

In 1996 I was supporting a small dialup operation, and one of our customers was having non-stop problems connecting via modem. Their plant was 2 hours away, but I was driving past there to visit a friend, so I made arrangements to drop by and investigate. For reasons unknown, most of their Windows desktops were configured to a year in the 21st century, probably 2096 instead of 1996 but it’s been a while. Wish I knew…

A lot of shareware back then stopped working after a certain # of calendar days, which it used windows to figure out. So I always had my date set far in the future.

How does that work? Surely you'd set it to the past. Unless it's a $networkDate - $installDate > $x thing.

Re: Windows feature that resets system clocks based on random data is wreaking havoc

#150

Post by justapassenger »

lamp987 wrote: post #123
justapassenger wrote: post #41

Earlier quoted context omitted.

It does. As long as you carefully select HW.

I said 2023. Not 2013.

And? Off the top - most powerful and energy efficient laptop for last few years (M* macbooks) have either no or very little support.

I’ve been running Linux since 1990s. It’s best it ever was with the HW support, but saying it’s not an issue is just a straight up lie.

Post reply on HN