
API responses should be signed - edent
https://shkspr.mobi/blog/2020/01/why-api-responses-should-be-signed/
======
speedplane
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.

~~~
kelnos
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.

~~~
jayd16
They can share the exact same encrypted bytes they received. Others can verify
those bytes with the cert as normal. Or do I have it wrong, and the traffic is
only signed with the user signature after the handshake?

~~~
edent
You have it wrong. I also thought that was the answer. See these responses to
my question on StackExchange
[https://security.stackexchange.com/questions/193559/saving-a...](https://security.stackexchange.com/questions/193559/saving-
and-verifying-an-https-request)

~~~
jayd16
Looks like the message is encrypted with a key derived by both parties but
this produces a symmetric encryption. The client then has the ability to spoof
encrypted server communications.

------
jayd16
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
That's a fair criticism. What is the correct word for "this request always
generates an identical response"?

~~~
matharmin
Immutable

~~~
DarkWiiPlayer
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.

------
greatjack613
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
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
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.

------
skybrian
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.

------
adrianmonk
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
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.

------
ljm
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
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
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.

------
solatic
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?

------
DarkWiiPlayer
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

------
cjslep
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.

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

------
EGreg
Basically this is the raison d’etrê of Verified Claims.

Not every API response is a verified claim.

Next?

------
LoSboccacc
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
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.

------
cprecioso
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-
exc...](https://developers.google.com/web/updates/2018/11/signed-exchanges)
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.

