The authenticated encryption of HTTPS similarly protects the CDN-based web clock approach. This avoids situations where an attacker-in-the-middle tampers with insecure NTP responses, messing up your system’s clock.
Almost… there is this fun thing called a delay attack that works despite encryption! (I’ll admit that it’s probably not a practical concern.)
Anyway, the article talks about time measurements through an absurd amount of abstraction layers. Please don’t ever call this “simple” or even “cloud-native time” or the like.
If you start trying to improve this setup you’ll find so many face-palm moments. Like TCP retransmissions (which the article mentions, to be fair). You’d have to use WebRTC to avoid that, which I bet the CDN network doesn’t support. Or the fact that web browser timers have intentionally reduced precision to resist fingerprinting. (Granted, if you are still in the milliseconds range it is not a problem.)
Almost… there is this fun thing called a delay attack that works despite encryption! (I’ll admit that it’s probably not a practical concern.)
Anyway, the article talks about time measurements through an absurd amount of abstraction layers. Please don’t ever call this “simple” or even “cloud-native time” or the like.
If you start trying to improve this setup you’ll find so many face-palm moments. Like TCP retransmissions (which the article mentions, to be fair). You’d have to use WebRTC to avoid that, which I bet the CDN network doesn’t support. Or the fact that web browser timers have intentionally reduced precision to resist fingerprinting. (Granted, if you are still in the milliseconds range it is not a problem.)
Ooo, great find on the delay attack. I’ll read up on that one today, but I think you’re right.
The terms I’m using for this are web-native and a demo. Certainly not simple.