Re: [httpapi] Using Date in requests

[Martin Thomson <[e-mail]>]

Hi Ben,

You will note that the system I describe is almost exactly like the one you have.  It's just that the "arbitrary number" is formatted as a Date field.  The resulting change (if any) is stored in the same way as a cookie, with all the same considerations.

I agree that this is suboptimal, but we're dealing with a system that exists.  More expansive solutions are less likely to get implemented, particularly for niche use cases.  Not many people want to include dates in requests.  Many of those that do can use something like JWT/JWS rather than a Date field (same problems of course).  

Spelling it differently won't change much, except make the change more disruptive.  I'm looking to make a surgical tweak that many people won't notice in order to deal with the problem.  I think that's an easier change to enact than a more comprehensive change, even if that change might be more principled.

Also, for all those cases where people do use dates and get the problems you cite, the draft proposes a nice problem message ... and automated remediation strategy.

Cheers,
Martin

p.s., Funny you should say that clocks might be wrong by minutes.  I've seen years and have credible reports of *decades*.

On Wed, Feb 9, 2022, at 18:25, Ben Bucksch wrote:
> Am 09.02.22 um 06:29 schrieb Martin Thomson:
>> I've just posted https://www.ietf.org/archive/id/draft-thomson-httpapi-date-requests-00.html which talks about how to use Date in requests.  ... use Date for managing anti-replay. 
>
>
> Hello Martin,
>
> thanks for posting this and asking for feedback.
>
> I appreciate that you acknowledge the problem of clock screw in the 
> spec. Some clocks are so bad that they can easily be minutes out of 
> sync. Yet others are simply set to the completely wrong time, but the 
> user doesn't use that clock, so he doesn't know. This leads to serious 
> problems in such systems that compare clocks of different systems, 
> particularly if the systems are managed by different entities, like in 
> most client/server scenarios.
>
> I ran into that very painfully with JWT [1]. It took multiple 
> developers several days to debug a failure, which eventually turned out 
> to be a simple clock screw.
>
> I came to the conclusion that any system that compares clocks of two 
> different systems is inherently flawed. That general idea should be 
> avoided in any system - be it a custom site-specific security measure, 
> or an Internet standard.
>
> Rather, time should always be *relative*. Coincidentally, Einstein agreed ;-).
>
> So, what I would propose is rather something that works like a special 
> browser cookie. For the sake of the discussion, I call it "time 
> cookie", but it doesn't need to be technically a cookie, but it should 
> have the same storage properties and lifetime as a cookie, for privacy 
> and tracking purposes. This time cookie would contain a simple Integer, 
> and the only special thing about it is that the browser stores the 
> local time when it was received, and when it's sent, the browser adds 
> the *time difference between receiving and sending*, in the form of the 
> difference of Unixtime.
>
> For example, the server sends 1,000,000 . That's an arbitary Integer 
> value, but let's say the server uses the Unixtime of its local server. 
> When receiving, the browser stores this value, together with the 
> current local time, on the client system, e.g. as Unixtime (which is 
> let's say 1,001,000, i.e. client and server disagree by 1 000 seconds = 
> 17 minutes, but that doesn't matter). 10 seconds later, the browser 
> makes another request to the same server, and the browser sends the 
> server-supplied value of 1,000,000 plus 10 (seconds) = 1,000,010. The 
> server recieves this, the server compares it to its own local Unixtime 
> (or any other base value), and it matches, and the request works.
>
> If you were to send the client time, the client would have sent 
> 1,001,010, and the value would not have matched and the request would 
> have failed.
>
> I believe that such a system that sends *only* the time difference is 
> inherently safer and more reliable, less prone to security attacks, and 
> also eventually simpler to implement, if you consider all the 
> counter-measures that a system based on absolute time would have to 
> implement against clock screw and security attacks.
>
> I appreciate very much the thought that you put into all the problems 
> of clock screw, security attacks manipulating local time, and even 
> privacy threats that abuse the stored server-time for tracking. Very 
> well done. But I believe that all of these could be avoided by a system 
> and simply uses only relative time and never ever compares clocks 
> between two systems.
>
> Due to these known problems, I would recommend to explicitly *avoid* to 
> use a format that uses an absolute date/time format and instead to 
> intentionally specify that the browser sends the time difference in the 
> form of seconds or milliseconds. You all have experienced first hand 
> how often even the most simple things (like HTTP error codes) are 
> implemented without reading the specs carefully, so I am concerned that 
> many implementations will not consider the extensive thoughts about 
> clock screw that you put in, or probably won't even read any part of 
> the spec, but if there's a "Date" header in datetime format, many devs 
> will simply send the current local time, without any adjustment or 
> consideration. So, a system that is explicitly specced to transmit 
> *only* the time *difference* and does not use the format of an absolute 
> time is far more likely to be implemented correctly.
>
> Let's just forget the idea that there is an universally agreed absolute time. 
>
> Repectfully,
>
> Ben Bucksch
>
>
>
>
>
>
>
> [1] Very painful experience with JWT 
> <https://github.com/mozilla/addons-server/issues/1072>
>
> We wrote a script to upload [something to a third-party server] as part 
> of our build process. The code was working for [the dev who] wrote the 
> script, but I just got "Invalid authentication credentials".
>
> We were debugging it for hours and hours, suspecting shell argument 
> passing and parsing, OS differences and what not. We compared 
> credentials and confirmed they are identical. Still, the result was 
> different. During debugging, once, by coincidence, it worked. At a time 
> when it should be expired.
>
> What was the reason? My clock on my computer was fast.
>
> I was screaming. Client server protocols must NEVER EVER compare client 
> clocks with server clocks, because clocks are very often off. Even if 
> it was originally set exactly right by the second, clocks always have a 
> drift in one way or another. If you have 5 million users, you will 
> surely have [many] users whose clocks are off... In my case, my clock 
> was 95 seconds fast. That's not uncommon. I don't run ntpdate 
> regularly, because ntp regularly has security problems, too.
>
> This is a fatal misdesign of the protocol. You simply cannot compare 
> client clock with server clocks. That something that engineers 
> generally know from experience. Often hard lessons, like mine above. 
> Sometimes worse lessons, when 5 million people were hit by this problem.
>
>
>
>
> -- 
> httpapi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpapi