#social 2019-01-14
2019-01-14 UTC
HankG and xmpp-social joined the channel
# 
fr33domlover In HTTP Signatures, it's possible to use the Date header to prevent replay, make the sig valid only for a short time frame. Is there a recommended time frame size? Mastodon was using 30 seconds, switched to 12 hours, and other projects seem not to check at all (or at least I couldn't find the check in their source code)
# jdormit fr33domlover: I don't think there's an officially recommended time frame
# jdormit 30 seconds is pretty reasonable, assuming you don't expect any latency longer than that
KjetilK joined the channel
# jdormit 12 hours seems so long as to be functionally useless
# jdormit might as well not enforce a time frame at that point
RzR joined the channel
# RzR hi are any of you going to fosdem this year?
# fr33domlover jdormit, I'm guessing Mastodon switched to 12 hours because 30 seconds wasn't enough? Also, the commit explains why it switched although I admit I'm not sure I understand
# fr33domlover jdormit, it suggests the time check prevents replaying old vulnerable signatures, which is supposedly unlikely to happen within 12 hours idk
# rialtate[m] Servers with bad clock sync will misbehave with 30 seconds. I think 5-10 minutes is much more reasonable.
# fr33domlover rialtate[m], joyent's implementation recommends 300 seconds which is 5 minutes
# rialtate[m] Fwiw Date doesn't have to be accurate to prevent replay. It merely has to be different (and digest takes care of the body in this regard)
# fr33domlover rialtate[m], yeah technically you can set Date to be a year from now and send the request a year from now. I guess what could protect it then it key rotation i.e. by then the key can be different so the sig won't pass
# fr33domlover But either way, checking Date helps prevent the sig from passing more than once
# fr33domlover I guess either way AP servers can check the actual AP activity against their DB and not store new activities with ID URLs they've already received
# jdormit yeah, they should be doing that anyway
# jdormit but you could potentially do a replay attack with e.g. Update activities
# jdormit unless you include the digest in the signature as well
# rialtate[m] Updates are a nightmare without versioning anyway
# jdormit because different nodes get out-of-sync about the latest version of an object?
# rialtate[m] Put simply yes
# jdormit i guess the bigger danger is multiple updates arriving out-of-order
# rialtate[m] Anything that isn't a directed graph has a variety of sync issues
# jdormit not sure I follow - how does a directed graph fix the sync issues?
# jdormit the ap graph is directed, isn't it? Edges have a direction, e.g. object -['attributedTo']-> actor
# jdormit but it's not acyclic, b/c actor also has an edge pointing back to object via 'outbox' -> 'items'
# jdormit but even if it was acyclic, say by enforcing that objects could never point back to their actors, you'd still have the update problem
Guest84 joined the channel
# rialtate[m] Version graph. "this update based on version abcd". 2 updates can be based on the same version and conflict resolution can be exposed to the UI so not necessarily acyclic
jdormit joined the channel
# heluecht[m] RzR (IRC): I will be at the FOSDEM
# RzR heluecht[m], cool I'll be there too
# heluecht[m] fr33domlover (IRC): 30 seconds are much too short, just think of systems that clock is slightly unsynchronized.
# RzR heluecht[m], I saw on mastodon call about mastodons devs for pannel was this you ?
# heluecht[m] I'm no Mastodon dev. I'm developing Friendica.
# nightpool[m] if your clock is more then THIRTY seconds desync'd, then you shouldn't be federating
# nightpool[m] install ntp
# RzR heluecht[m], IIRC the call was about activitypub implementations
# heluecht[m] My clock is synchronized, but I always think of lazy admins.
jdormit joined the channel
# fr33domlover Hi heluecht[m] :) It's cool the fediverse projects' devs are here
# fr33domlover heluecht[m], yeah 30 is little for desynced servers but I wonder how common/acceptable it is to just leave it like that
# fr33domlover Versus asking admins to use ntp
# fr33domlover Which I hope is common anyway
# fr33domlover heluecht[m], does Friendica use HTTP sigs and check the date? What's the time frame size? ^_^
# fr33domlover Looks like Peertube, Pleroma Kroeg don't check
# fr33domlover *and Kroeg
# heluecht[m] We create the date in the signature, but I guess we don't check it.
# fr33domlover heluecht[m], well I suppose creating the date is a must because it's required for federation with Mastodon
# fr33domlover Looks like nobody else checks that date though
# fr33domlover Tbh the HTTP sigs draft doesn't mention such checking
# fr33domlover It's mentioned in Joyent's implementation though
# heluecht[m] For Mastodon you don't need the date.
# Chocobozzz fr33domlover: peertube checks it: https://github.com/Chocobozzz/PeerTube/blob/develop/server/tests/api/activitypub/security.ts#L78
# heluecht[m] Concerning checking the date I just found this in our code:
# heluecht[m] ```/// @todo Check if the signed date field is in an acceptable range```
# heluecht[m] So, no, we don't check it at the moment.
ahihi2 joined the channel
# fr33domlover Chocobozzz, hmmm can you show me where the check happens in the code though? I couldn't find it
# fr33domlover Chocobozzz, btw the peertube readme/docs don't say in which language it's written, I was looking for the info and couldn't find it
# fr33domlover I just guessed it's JS/TypeScript but would be nice to find this detail written in readme / architecture / contributing
# rigelk[m] fr33domlover (IRC)fr33domlover (IRC) that's at least said insupport/doc/development/server/code.md` and `support/doc/development/client/code.md`
# fr33domlover rigelk[m], thanks :) That's nice but hard to find, no big deal but I'm wondering if it could be placed somewhere more visible
# rigelk[m] fr33domlover (IRC): honestly I think people look for less specific information in the README, and infer it from the build system/file extensions/etc. anyway.
# Chocobozzz github shows the language if you click on the bar below the commits/branches/releases/contributors info
# Chocobozzz fr33domlover: it's checked by the parseHTTPSignature function https://github.com/Chocobozzz/PeerTube/blob/develop/server/tests/api/activitypub/helpers.ts#L134
# fr33domlover Chocobozzz, but that's in tests?
# nightpool[m] fr33domlover: peertube doesn't check it explicitly, they rely on a library that checks it
# rigelk[m] this one https://github.com/joyent/node-http-signature/
# fr33domlover nightpool[m], rigelk[m] ah I see! I saw that lib, just missed the clock skew parameter ^_^
# fr33domlover Looks like Peertube does't mass clock skew which means the default of 300 seconds would be used
# fr33domlover *pass
dlongley, schmittlauch[m], timbl and timbl_ joined the channel