🆕 blog! “I made a mistake in verifying HTTP Message Signatures”
It's never great to find out you're wrong, but that's how learning and personal growth happens. HTTP Message Signatures are hard1. There are lots of complex parts and getting any aspect wrong means certain death2. In a previous post, I wrote A simple(ish) guide to verifying …
Part of the problem with verifying HTTP Message Signatures is that you kinda have to wait for a duff one to come along before you know whether your code works.
(Yes, I'm aware I could build a test-suite, but it's much more fun to telnet into prod and YOLO.)
@Edent Wait, you're comparing the Date header to the activity's "published" property? Is that recommended? I don't think there are restrictions on that duration, I've received hours old messages from congested servers.
What I compare (and what I believe Mastodon compares) is the difference between the signed message's Date header and my own server's time. The goal is to ensure the signature itself is current. There's less room for valid time differences there.
> An application could also put limits on how much skew there is between the Date field and the created signature parameter, in order to limit the application of a generated signature to different HTTP messages.
@Edent Okay, but Mastodon's signatures don't have a "created" signature parameter, right? I don't remember ever seeing one. Is this one of those things where Mastodon's signatures differ from the RFC?
Looking at your code now, I see you're checking both differences: between signature date and current local time, as well as between signature date and "published" property. I think the latter will keep causing problems. Multi-hour differences are not especially rare in my experience.
@julian
Ah, I see what you mean. I read that as date it was created, rather than an explicit header.
I'm not sure why a server would sign a message hours after publishing it though?
@django
Not really. All the times are in a standardised format (GMT / Zulu) and are then converted to Epoch seconds for comparison.
Biggest drift I've seen is in the order a of a couple of minutes - nothing DST related that I've seen.
First time I had a communication failure because of inaccurate timestamps was 1987. And thousands of times over the years. It became an epidemic around 2005 because of the rise of VMs. They have emulated hardware clocks in software and when they're loaded, they lose ticks. There have always been issues with Linux because they can't always decide if the hardware clock is GMT or localtime. You can be a stickler about it if you want, it's your legitimate communications you're dropping from people who have no idea there's a problem and many won't know what to do about if they did.
Add comment