4

We have a B2B REST API with Client Certificate authentication.
Are there any reasons to add also a payload signature check to this API?

I'm seeing many service providers which add a digital signature payload parameter to their API.

Having already a Client Certificate authentication in place, is it a redundant check or it serves another purpose?

I read that it could help for non-repudiation of the transaction.

Improve this question

4 Answers 4

Reset to default
3

I suspect this will be a big "It depends on your architecture" and so random internet people won't be able to give you a complete answer.

Off the top of my head, here's some scenarios where it might make sense to have client-auth TLS and payload signatures. The first are network constraints:

  • The TLS is terminated by CloudFront and the app server / backend doesn't get to see the client cert.
  • You want the message retains its tamper-protection even while bouncing around the server back-end in plaintext.

Then there are a host of ways that you could have a logical separation between the TLS connection and the API requests:

  • There's one Server <-> Server TLS connection that is routing requests for all logged-in users.
  • The payload signature is tied to some sort of API key, maybe for licencing reasons.
  • Non-repudiation and auditing: users have non-repudiation keys which are kept at a higher security level than the TLS certs.
Improve this answer
2

One reason for requiring both is when the API is being used on infrastructure which separates the client certification verification and the payload verification. In some environments, the checking of client certificates is performed at an edge level, while the payload verification is carried out at the application level, after passing through some layers of load balancing or proxy systems.

This in turn can allow for a subtle form of attack, where the client certificate is valid for connection to the system, but the inner payload actually corresponds to another client - the edge system allows access, since the client certificate is valid, and the application system allows the action to be performed, since it has no way of verifying which user made the request, but trusts the edge layer to only allow valid requests through.

If the payload is signed, however, the application can now verify that the requested action is appropriate for the connecting client, even if it does not have access to the client certificate check.

Improve this answer
2

In addition to the answers regarding TLS terminating on a separate system than the one verifying the payload, you heard correctly that it can help with non-repudiation even if TLS terminates on the same host.

The client certificate only authenticates the client to the server, it doesn't (directly) authenticate any data sent after. Normally this is not an issue, as the data sent between client and server is encrypted and MACed with a key known only to the client and server. Since the server can check the MAC of the data it receives, it can easily prove to itself that it must have come from the client (since the server didn't send it, it must have been the client), but the server can't easily prove to others that it didn't fabricate the data and use the TLS key to encrypt and MAC it.

Here's a related answer.

Improve this answer
1

Proposing an alternate to Mutual TLS...

We have had many many support problems when our corporate customers try to set up Mutual TLS with our SAAS servers. Plus there is no good solution for maintaining 100% uptime while changing/updating the leaf cert.

I suggest that you consider using dual HMAC headers instead.

Also, HMAC provides an end to end check of the contents validity unlike the transport layer check of TLS / Mutual TLS

See the write up from Box for a good solution:

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .