#social 2018-09-11
2018-09-11 UTC
# 
heluecht[m] Looking in data that arrived on my system I saw that the signed data includes some "digest". Hos is this generated?
xmpp-social, rialtate[m], cwebber2, vt and edsu_ joined the channel
# puckipedia heluecht[m]: the digest in the signature is the Digest header, which just contains a hash over the body of the request
# heluecht[m] Is there some more documentation/sample code how to generate the digest? Of course I can reengineer it - but having some more documentation could be helpful. Is the digest some standard stuff in HTTP? I haven't really noticed it until now.
# puckipedia the digest is just ths SHA-256 over the raw body of the request/response
# puckipedia (which is the SHA256 of '{}')
edsu and cwebber2 joined the channel
# heluecht[m] Do I have to validate the digest manually or is it done in the protocol?
# JasonRobinson[m] none of this stuff is in AP directly
# puckipedia heluecht[m]: my suggestion, primarily, is to just validate the digest any time you receive it, even if it's not specifically signed
# nightpool[m] heluecht: digest is an actual HTTP header, yes.
# heluecht[m] The question is if the digest is checked by some internal routine - and what would happen when it was wrong. So possibly it is the best to do like puckipedia said: Just validating it on the receiving side as well, just to be sure.
# nightpool[m] the digest is computed when checking the HTTP signature, if the application supports it
# nightpool[m] I don't see a point to validating the digest separately from the signature. I'm not sure what puckipedia's point is. it's possible your http signature library doesn't support validating it though.
# heluecht[m] I want to guarantee that a signature can't be reused. So I have to use values for the signatur that changes per each single activity. But when the digest wouldn't be checked at the receiver, then an attacker could simply replicate the same digest over and over again.
# nightpool[m] that's a different concern
# nightpool[m] just make sure you're signing the Date header and the Host header, and it will be impossible to re-use a signature
# nightpool[m] because you're assumed to be transporting these over HTTPS
# heluecht[m] You could always send the same date over and over again.
# heluecht[m] Or who is checking these value at the receiving side.
# heluecht[m] I don't want to rely only upon HTTPS. Neither DFRN (Friendica) nor Diaspora are doing so. They both use signatures based upon the content.
# nightpool[m] hmm
# nightpool[m] I'm not sure what you mean
# nightpool[m] Signatures are for client -> server authentication
# nightpool[m] HTTPS is for transport confidentiality and server <- client authentication
# nightpool[m] sorry server -> client
# nightpool[m] they serve different purposes
# nightpool[m] anyway, to your point about "who is validating these things"—im not seeing anything in HTTP Signatures about recommended validation. that's probably bad
# nightpool[m] mastodon validates that the Date header is within 5 minutes and that the request target matches the actual request
vasilakisfil joined the channel
# nightpool[m] and validates the digest iff the digest is specified, but does not require it
# heluecht[m] With signatures I mean the HTTP signatures for server -> server.
# nightpool[m] sorry that was confusing
# nightpool[m] I was using client/server in the HTTP sense
# nightpool[m] not the AP sense
up201705417 joined the channel
# heluecht[m] Ah okay. I'm very good in misinterpretations ;-)
# heluecht[m] Since I made a very fast progress the last days, I guess I will invest some time in additional security checks. When AP will work reliantly with everything that currently DFRN is able to, I want to replace our own protocol completely. But to make this possible, I have to ensure our users to not compromise security.
vt joined the channel; vt left the channel
# puckipedia <nightpool[m]> I don't see a point to validating the digest separately from the signature. I'm not sure what puckipedia's point is. it's possible your http signature library doesn't support validating it though. <- Digests aren't always SHA-256
# nightpool[m] hmm
# heluecht[m] puckipedia: Is there a list of common hashes for the digests?
# puckipedia it's part of the http spec
# puckipedia seems rfc3230 specifies MD5, SHA, UNIXsum, UNIXcksum
# heluecht[m] I guess I will ignore that "sum" things, but will put the others in a list. I think that checking the digest should be specified in the specs.
# nightpool[m] this all seems to ignore the real issue
# nightpool[m] which is that we have no minimum required secure configuration for HTTP sigs
# nightpool[m] we should work to standardize that, at least for AP
# saranix "it makes sense for AP to specify more detail on that" --> no more than it makes sense for AP to specify exactly what an inbox url has to look like. There are different usecases that require different things. Guidance here: https://web-payments.org/specs/source/http-signatures-audit/
# saranix linked from main spec: https://tools.ietf.org/html/draft-cavage-http-signatures-10#ref-15
up201705417 and edsu joined the channel
up201705417 and vt joined the channel; vt left the channel