6 ms·

API responses should be signed

40 points by edent 7y ago

greatjack613 7y ago
Cool concept but totally overblown need. If the usage for api signing is to verify that leaked private messages are legit then I don't think we should have such tech in place. If anyone has any more legitimate use cases that auth does not account for I would love to hear.
- edent 7y ago
  Here are a few that I considered including in the post... The city's car park API told me I could park here - why have I been given a parking ticket? The hospital's drug API told me I could mix these two tablets. The bank's API told me a client hadn't received the funds I sent. Basically, if I have to go to court and say "I have proof that your system told me XYZ."
  - DarkWiiPlayer 7y ago
    Better yet: Someone sends you a tweet with your address, a picture of your house and a picture of a gun, then deletes the tweet the next day.
jayd16 7y ago
This might not be the most salient place to start when critiquing this article but it did irk me that they get the definition of idempotent wrong even while linking to Wikipedia. >That is, the data returned from a query is always the same. That is not correct. Only the system state remains the same. As stated in the linked wiki page: >[...] the end result is always the same as the result of the initial execution, even if the response differs.
- edent 7y ago
  That's a fair criticism. What is the correct word for "this request always generates an identical response"?
  - matharmin 7y ago
    Immutable
    - edent 7y ago
      Aha! Yes. Thanks. I'll update the blog post.
    - DarkWiiPlayer 7y ago
      Immuteble describes data, whereas an API call is more like a function call, in which case we'd call the property "referential transparency", which means, a function always returns the same result for a given input value. "referential transparency" makes up half the definition of a "pure" function, with the other half being the absence of side effects.
  - marton78 7y ago
    Pure
    - DarkWiiPlayer 7y ago
      Pure also means no side effects, which isn't, strictly speaking, what OP means :)
  - opifex 7y ago
    Deterministic
speedplane 7y ago
This article brazenly glosses over HTTPS, which is designed to tackle the very issues that are raised (privacy and authenticity). APIs do not need to sign every response, they just need to properly use HTTPS.
- jayd16 7y ago
  The author seems to be aware that https has this function as they seem to state using it ensures the response they see is valid. However, they don't seem to understand why that is or that the raw response would remain verifiable to others.
- kelnos 7y ago
  This is addressed in the article specifically. They're not talking about the person making the API request needing a signature to verify its authenticity. It's about if someone else sends you an API response that they retrieved, you should be able to verify it wasn't tampered with.
  - speedplane 7y ago
    > They're not talking about the person making the API request needing a signature to verify its authenticity. It's about if someone else sends you an API response that they retrieved, you should be able to verify it wasn't tampered with. If a system retrieves data, it should do so with HTTPS, and then it's authenticity can be guaranteed. If it does not use HTTPS (or some similar protocol), then it's authenticity cannot be guaranteed and no amount of signing or hashing can fix that.
    - notduncansmith 7y ago
      Most access to HTTPS is transparent, i.e. signatures are not that easy to extract and independently verify (not to mention all the issues with CA infrastructure)... Basically, while maybe you could technically accomplish it with HTTPS, there are huge usability gains to be had in exchange for the inefficiency of duplicating some lower-level functionality at a higher level.
cjslep 7y ago
Isn't this solved by HTTP-Signatures, which is a draft RFC? I guess not, as there's no way to forward that signature to a third party without some imposter-ing, depending on the HTTP headers that were signed.
skybrian 7y ago
Code signing does something similar; it allows data to be published on untrusted mirror sites. But it's not clear why most API owners should care about this use case? In particular, Twitter allows users to delete their Tweets. If you think it's good to be able to take back what you said, signing tweets doesn't help.
solatic 7y ago
Author presumes that the platform (in charge of signing the response) finds the signature valuable. This presumption is faulty - indeed, plausible deniability is a feature, not a bug for these platforms. Which platform wants to give the government a loaded gun by cryptographically verifying that they hosted content or behavior that broke the law?
EGreg 7y ago
Basically this is the raison d’etrê of Verified Claims. Not every API response is a verified claim. Next?
adrianmonk 7y ago
The author seems to have written this article in a very web-centric way, as if "API" could only possibly refer to web service APIs that go over the open internet. But of course sometimes (you might even say often) APIs don't go over a network at all and don't cross the sort of boundaries that require signing. For example, the Linux kernel has an API that applications can use. There's no need for the response to open(2) to be signed. If you can't trust the result, you can't trust anything else that is happening either since you are at the mercy of the kernel.
- edent 7y ago
  The author primarily works with web APIs. But, for example, the Kernel's USB API may want to verify that it is communicating with a specific device. And, for audit purposes, log the signed input.
LoSboccacc 7y ago
and how do you suppose to get the end user the certificate? because if it's trough the same channel, none of this matter.
- DarkWiiPlayer 7y ago
  The idea (if I understand it correctly), is that you can get a signed API resopnse from anywhere, and the public key from the signer to verify the legitimacy of the data in the API response without having to call the API again.
ljm 7y ago
This sounds like coming full circle back to SOAP. Library support for signing an XML doc and adding the cert for offline verification is pretty well established.
- akvadrako 7y ago
  The main problems with SOAP were practical problems - bad dev experience and inefficient, like almost everything XML. But the goals of SOAP were not bad.
  - ljm 7y ago
    I hated it at first but once I realised the use-cases I changed my mind. When you have regulations telling you to keep hold of documents for 5+ years, and you want to digitise them, then communicating through signed XML documents is a pretty nice solution. The format is suitable. I mean, we're not talking about Twitter searches or any such useless stuff. It's inter-bank transactions, direct debits, payment pre-authorisation, etc. Everything that you really do need a paper-trail for for years and years.
cprecioso 7y ago
Reposting the comment as top level, as I haven't seen it mentioned anywhere. Google has developed Signed HTTP Exchanges https://developers.google.com/web/updates/2018/11/signed-exchanges https://developers.google.com/web/updates/2018/11/signed-exc... that can then be bundled https://web.dev/web-bundles/ https://web.dev/web-bundles/ . Its main motivation is the rehosting of AMP pages while verifying that the cache hasn't tampered with them; but it could be extended to sign and bundle API calls for redistribution if needed.
DarkWiiPlayer 7y ago
It might make sense to also add a section to the article considering why you'd want to verify an API signature instead of calling the API again. Some examples I could think of: - You don't have access to (that part of) the API, but to its public key - The data in question has been deleted - The entire API or even Service is gone - The API call involves some complex calculations that takes a long time - The data might have to be verified without access to the API or the network as a whole - You are being Surveilled and/or your access to the API or some of its endpoints is being restricted
deleted 7y ago
[deleted]
camgunz 7y ago
Finally a use case for blockchain. Not new though, look around at the "trust economy".

40 points by edent 7y ago

Cool concept but totally overblown need. If the usage for api signing is to verify that leaked private messages are legit then I don't think we should have such tech in place. If anyone has any more legitimate use cases that auth does not account for I would love to hear.

edent 7y ago
Here are a few that I considered including in the post... The city's car park API told me I could park here - why have I been given a parking ticket? The hospital's drug API told me I could mix these two tablets. The bank's API told me a client hadn't received the funds I sent. Basically, if I have to go to court and say "I have proof that your system told me XYZ."
- DarkWiiPlayer 7y ago
  Better yet: Someone sends you a tweet with your address, a picture of your house and a picture of a gun, then deletes the tweet the next day.

jayd16 7y ago

This might not be the most salient place to start when critiquing this article but it did irk me that they get the definition of idempotent wrong even while linking to Wikipedia. >That is, the data returned from a query is always the same. That is not correct. Only the system state remains the same. As stated in the linked wiki page: >[...] the end result is always the same as the result of the initial execution, even if the response differs.

edent 7y ago
That's a fair criticism. What is the correct word for "this request always generates an identical response"?
- matharmin 7y ago
  Immutable
  - edent 7y ago
    Aha! Yes. Thanks. I'll update the blog post.
  - DarkWiiPlayer 7y ago
    Immuteble describes data, whereas an API call is more like a function call, in which case we'd call the property "referential transparency", which means, a function always returns the same result for a given input value. "referential transparency" makes up half the definition of a "pure" function, with the other half being the absence of side effects.
- marton78 7y ago
  Pure
  - DarkWiiPlayer 7y ago
    Pure also means no side effects, which isn't, strictly speaking, what OP means :)
- opifex 7y ago
  Deterministic

speedplane 7y ago

This article brazenly glosses over HTTPS, which is designed to tackle the very issues that are raised (privacy and authenticity). APIs do not need to sign every response, they just need to properly use HTTPS.

jayd16 7y ago
The author seems to be aware that https has this function as they seem to state using it ensures the response they see is valid. However, they don't seem to understand why that is or that the raw response would remain verifiable to others.
kelnos 7y ago
This is addressed in the article specifically. They're not talking about the person making the API request needing a signature to verify its authenticity. It's about if someone else sends you an API response that they retrieved, you should be able to verify it wasn't tampered with.
- speedplane 7y ago
  > They're not talking about the person making the API request needing a signature to verify its authenticity. It's about if someone else sends you an API response that they retrieved, you should be able to verify it wasn't tampered with. If a system retrieves data, it should do so with HTTPS, and then it's authenticity can be guaranteed. If it does not use HTTPS (or some similar protocol), then it's authenticity cannot be guaranteed and no amount of signing or hashing can fix that.
  - notduncansmith 7y ago
    Most access to HTTPS is transparent, i.e. signatures are not that easy to extract and independently verify (not to mention all the issues with CA infrastructure)... Basically, while maybe you could technically accomplish it with HTTPS, there are huge usability gains to be had in exchange for the inefficiency of duplicating some lower-level functionality at a higher level.

cjslep 7y ago

Isn't this solved by HTTP-Signatures, which is a draft RFC? I guess not, as there's no way to forward that signature to a third party without some imposter-ing, depending on the HTTP headers that were signed.

skybrian 7y ago

Code signing does something similar; it allows data to be published on untrusted mirror sites. But it's not clear why most API owners should care about this use case? In particular, Twitter allows users to delete their Tweets. If you think it's good to be able to take back what you said, signing tweets doesn't help.

solatic 7y ago

Author presumes that the platform (in charge of signing the response) finds the signature valuable. This presumption is faulty - indeed, plausible deniability is a feature, not a bug for these platforms. Which platform wants to give the government a loaded gun by cryptographically verifying that they hosted content or behavior that broke the law?

EGreg 7y ago

Basically this is the raison d’etrê of Verified Claims. Not every API response is a verified claim. Next?

adrianmonk 7y ago

The author seems to have written this article in a very web-centric way, as if "API" could only possibly refer to web service APIs that go over the open internet. But of course sometimes (you might even say often) APIs don't go over a network at all and don't cross the sort of boundaries that require signing. For example, the Linux kernel has an API that applications can use. There's no need for the response to open(2) to be signed. If you can't trust the result, you can't trust anything else that is happening either since you are at the mercy of the kernel.

edent 7y ago
The author primarily works with web APIs. But, for example, the Kernel's USB API may want to verify that it is communicating with a specific device. And, for audit purposes, log the signed input.

LoSboccacc 7y ago

and how do you suppose to get the end user the certificate? because if it's trough the same channel, none of this matter.

DarkWiiPlayer 7y ago
The idea (if I understand it correctly), is that you can get a signed API resopnse from anywhere, and the public key from the signer to verify the legitimacy of the data in the API response without having to call the API again.

ljm 7y ago

This sounds like coming full circle back to SOAP. Library support for signing an XML doc and adding the cert for offline verification is pretty well established.

akvadrako 7y ago
The main problems with SOAP were practical problems - bad dev experience and inefficient, like almost everything XML. But the goals of SOAP were not bad.
- ljm 7y ago
  I hated it at first but once I realised the use-cases I changed my mind. When you have regulations telling you to keep hold of documents for 5+ years, and you want to digitise them, then communicating through signed XML documents is a pretty nice solution. The format is suitable. I mean, we're not talking about Twitter searches or any such useless stuff. It's inter-bank transactions, direct debits, payment pre-authorisation, etc. Everything that you really do need a paper-trail for for years and years.

cprecioso 7y ago

Reposting the comment as top level, as I haven't seen it mentioned anywhere. Google has developed Signed HTTP Exchanges https://developers.google.com/web/updates/2018/11/signed-exchanges https://developers.google.com/web/updates/2018/11/signed-exc... that can then be bundled https://web.dev/web-bundles/ https://web.dev/web-bundles/ . Its main motivation is the rehosting of AMP pages while verifying that the cache hasn't tampered with them; but it could be extended to sign and bundle API calls for redistribution if needed.

DarkWiiPlayer 7y ago

It might make sense to also add a section to the article considering why you'd want to verify an API signature instead of calling the API again. Some examples I could think of: - You don't have access to (that part of) the API, but to its public key - The data in question has been deleted - The entire API or even Service is gone - The API call involves some complex calculations that takes a long time - The data might have to be verified without access to the API or the network as a whole - You are being Surveilled and/or your access to the API or some of its endpoints is being restricted

deleted 7y ago

[deleted]

camgunz 7y ago

Finally a use case for blockchain. Not new though, look around at the "trust economy".