6 ms·

Why even bother with all of the STS cleverness? The article suggests a perfectly good way to get a rough but trusted time stamp by… scraping it from a known goo

by zoky 3y ago

Why even bother with all of the STS cleverness? The article suggests a perfectly good way to get a rough but trusted time stamp by… scraping it from a known good HTTP server. Anyway, STS as described is an obviously broken protocol. It’s not clear to me that it is even capable of reliably getting a rough time.

xg15 3y ago
My understanding was that they want to pull the time over a secure (TLS) connection only - but to establish a secure connection, they already have to have the time in advance. That kind of catch-22 would always appear, no matter whether the thing you want to connect to is an NTP or an HTTP server. So far, it all makes sense. It stops making sense when their attempt at breaking the catch-22 seems to do so by in fact ditching the "secure connection" requirement, just doing so in an obfuscated manner. I agree, if you already violate your own rule, you could have saved everyone a lot of hassle and just pull the time from a plaintext HTTP server. But then you might just as well ask a plaintext NTP server and go back to where everything started...
- zoky 3y ago
  I think the idea is that NTP is only supposed to work if your clock is close enough to correct, in order to prevent wackiness from ensuing due to sudden extreme jumps in the system time, presumably from a misconfiguration, compromised server, or whatever. I suppose you could just rely on an insecure NTP and force the date correction, but given that the default is not to do that and you have to force it, there’s probably some reason why you shouldn’t. So, if your goal is to get the accurate time over a secure connection, getting a “close enough” time over an insecure connection and confirming/adjusting the time over secure NTP doesn’t actually seem like the craziest way to do it. I don’t really know why bootstrapping over HTTP then adjusting via secure NTP is better than bootstrapping via plaintext NTP then confirming with SSL enabled, but I guess it at least means two servers and protocols would have to be compromised.

by zoky 3y ago

xg15 3y ago

My understanding was that they want to pull the time over a secure (TLS) connection only - but to establish a secure connection, they already have to have the time in advance. That kind of catch-22 would always appear, no matter whether the thing you want to connect to is an NTP or an HTTP server. So far, it all makes sense. It stops making sense when their attempt at breaking the catch-22 seems to do so by in fact ditching the "secure connection" requirement, just doing so in an obfuscated manner. I agree, if you already violate your own rule, you could have saved everyone a lot of hassle and just pull the time from a plaintext HTTP server. But then you might just as well ask a plaintext NTP server and go back to where everything started...

zoky 3y ago
I think the idea is that NTP is only supposed to work if your clock is close enough to correct, in order to prevent wackiness from ensuing due to sudden extreme jumps in the system time, presumably from a misconfiguration, compromised server, or whatever. I suppose you could just rely on an insecure NTP and force the date correction, but given that the default is not to do that and you have to force it, there’s probably some reason why you shouldn’t. So, if your goal is to get the accurate time over a secure connection, getting a “close enough” time over an insecure connection and confirming/adjusting the time over secure NTP doesn’t actually seem like the craziest way to do it. I don’t really know why bootstrapping over HTTP then adjusting via secure NTP is better than bootstrapping via plaintext NTP then confirming with SSL enabled, but I guess it at least means two servers and protocols would have to be compromised.