Use HMAC verification in hook payloads

[0xmichalis]

Nothing guarantees the hook payload's integrity when it is received by a third-party service. Usually, that's fixed by using a HMAC secret that third-party services can verify to ensure the payload was not tampered in transit. TLS is an overkill because we don't really care to encrypt the payload, it's not secret.

[eupn]

How the HMAC secret should be exchanged between parties in this case?

[0xmichalis]

Different issue but fwiw usually the person deploying a third party integration is the same person owning the original instance ("instance" being an account in a service, eg. a github account, or the service itself, eg. a grin node) so sharing a HMAC secret is a non-issue.

…

-------- Original Message --------

On 27 Jul 2019, 15:40, eupn wrote: How the HMAC secret should be exchanged between parties in this case? — You are receiving this because you authored the thread. Reply to this email directly, [view it on GitHub](#2955?email_source=notifications&email_token=AA5YK75FX2JH6JH7CRQGSKDQBRM5LA5CNFSM4IFKIYRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD26MUYY#issuecomment-515689059), or [mute the thread](https://github.com/notifications/unsubscribe-auth/AA5YK73PI3WPATAVWQO42YDQBRM5LANCNFSM4IFKIYRA).

[eupn]

Is it enough to specify a shared secret in the node's config file?

[mcdallas]

TLS is already supported for webhooks #2660 I agree it's overkill but there might be some service that only accepts https.

[0xmichalis]

@mcdallas I didn't know https was already supported, the TLS mention was in case it was proposed as an alternative. I think this issue can be closed.