API responses should be signed

Re:API responses should be signed by tsimionescu on Monday January 20, 2020 @04:23AM (#22097584)

Depend on your use case, HTTPS may not give you the right guarantees. For example, if you are trying to check an online license (where the client running the current application is essentially a potential adversary), HTTPS gives you no guarantees that the license server you think you are talking to is the real license server. You could pin the certificate to work around this, but then you have to reinvent revocation and renewal of the certificate for your own application. A longer lived, application specific signature may be a better option.

In other cases, HTTPS's end-to-end encryption may not be completely desirable - for example, apt does not use HTTPS as it would interfere with simple caching proxies, and it offers no extra assurances than a verified signature does.

[ Parent | on HN ]

Re:API responses should be signed by speedplane on Friday January 24, 2020 @12:11AM (#22135571)

> HTTPS gives you no guarantees that the license server you think you are talking to is the real license server

What? This is the entire purpose of HTTPS! To do this securely:

1 - you create your server;

2 - you tell a certificate authority (like Symantec, Digicert, or Let's Encrypt) how to find your server, and they do the diligence to make sure you're not trying to redirect another person's server;

3 - they provide you with a private encryption key and expose the public decryption key;

4 - you save the encryption key on your server.

Now, anyone who receives any information from your server can be sure that it came from you because (a) your server is the only one with the encryption key and (b) we trust Symantec, Digitcert, etc to distribute the public decryption key.

[ Parent | on HN ]