3 ms·

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

> 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.
- speedplane 7y ago
  > 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 If you are not using HTTPS, you cannot just build your own "higher level" version of secure and authenticated communication. HTTPS works because trusted certificates are pre-installed on each of the machines before they start communicating. Without those pre-existing trusted certificates, no amount of encryption, signing, or hashing can guarantee secure and authenticated communication.
  - deleted 7y ago
    [deleted]
  - notduncansmith 7y ago
    I agree that from a practical perspective, the best way to secure one’s communications with a web server is to enable it with HTTPS. I also think though that it’s possible, for any number of reasons, that one might want signed API responses independently of that (e.g. OTA software updates). Once you get into cryptographic identity though, you’re back to CA/PKI all over again...
    - speedplane 7y ago
      > it's s possible, for any number of reasons, that one might want signed API responses independently At it's core, HTTPS works because there is a distributed system of trust. The principle is that you don't need to directly trust the server that you're communicating with, but you trust another computer that has vouched for the one you are communicating with. If you roll your own security in any way, at some point you need to send an encryption or decryption key. Even "unhackable" encryption algorithms are worthless if your adversary knows the key. Thus, you need a way to communicate that initial key information securely. Currently, the only way to do that is by (1) manually entering the key on each server, (2) using near sci-fi technology like quantum communication, or (3) by having the keys pre-installed on every machine by the hardware manufacturer or OS provider. The option that has worked, HTTPS, uses option 3. Maybe you can roll your own encrypted communication system, but you'll either have to rely on manually entering the keys (which in turn rely on other insecure methods like email and phone), or trust the computer's manufacturer to pre-install the keys on the system your using. There really is no way to "roll your own" system securely without these steps.
codegladiator 7y ago
OP is talking about system 1 getting a response generated by system 3 VIA system 2 (potentially trusted man in the middle). And they are already assuming that system 1 and 2 talk using https and system 2 and 3 talk using https.
- speedplane 7y ago
  > OP is talking about system 1 getting a response generated by system 3 VIA system 2 (potentially trusted man in the middle). So they are effectively saying that they do not trust system 2. If that's the case, a signature from system 2 would not help because the signature itself could not be trusted. They would need the signature from the original source, system 3.
  - codegladiator 7y ago
    > a signature from system 2 That's why they are talking about signature from system 3 along with the payload. So even if they trust system 2, they can be sure system 2 has not tampered with the message generated by system 3.
    - speedplane 7y ago
      > That's why they are talking about signature from system 3 along with the payload. So even if they trust system 2, they can be sure system 2 has not tampered with the message generated by system 3. No that wouldn't work by itself. System 2 could tamper the data, create their own signature, and send it to system 1. The only way it could work is if System 1 got the signature directly from System 3, or at least got System 3's public signing certificate. Either way, System 1 needs to communicate directly with System 3 to ensure the data it's getting from System 2 is authentic.
      - codegladiator 7y ago
        I think you are right. At some point system 1 will need to talk to system 3 to validate the message (unless system 1 and 3 have an already shared secret or public key)
kelnos 7y ago
I'm not really sure how to explain this any better, but let's try: Our cast of characters: Service A, Person 1, and Person 2. Person 1 makes an API request to Service A. It's done over HTTPS, and Person 1 trusts that the response received is genuine, because it came over HTTPS, and certs were verified and so forth. Person 1 sends the text of the API response to Person 2. Let's say Person 2 is a journalist, and Person 1 is a potential source. Person 2 doesn't know Person 1, and so logically doesn't blindly trust them. But Person 2 wants to report on some factual thing about the API response. How can Person 2 be sure that Person 1 hasn't modified the API response before Person 2 receives it? If the API response is signed somehow, Person 2 could go retrieve Service A's public key (directly from Service A) and independently validate that the API response was actually received from Service A, and that it hasn't been tampered with. I'm not sure I agree with the original author that this is a critical problem that needs to be solved, but that's the gist of it.
- speedplane 7y ago
  > How can Person 2 be sure that Person 1 hasn't modified the API response before Person 2 receives it? ... If the API response is signed somehow, Person 2 could go retrieve Service A's public key (directly from Service A) and independently validate that the API response was actually received The problem here is that Person 1 cannot be trusted, so they can't be the one providing the signature. Even if Person 1 signs, hashes, or encrypts the message when sending to Person 2, all it can prove is that it came from Person 1, not that it came from Service A. If Person 2 wants to be sure that the message it got from Person 1 actually came from Service A, it will need the signature provided by Service A, not Person 1. To get the valid signature, it will need to contact Service A. This is a long-winded way to say that if you want to trust what you got, you've got to go to the original source. HTTPS provides tools to do exactly this, and it's special because every time you buy a computer or server, trusted certificates are pre-installed on the machine. Without that initial level of trust, you can't trust anything you receive from anywhere.

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.

speedplane 7y ago
> 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 If you are not using HTTPS, you cannot just build your own "higher level" version of secure and authenticated communication. HTTPS works because trusted certificates are pre-installed on each of the machines before they start communicating. Without those pre-existing trusted certificates, no amount of encryption, signing, or hashing can guarantee secure and authenticated communication.
- deleted 7y ago
  [deleted]
- notduncansmith 7y ago
  I agree that from a practical perspective, the best way to secure one’s communications with a web server is to enable it with HTTPS. I also think though that it’s possible, for any number of reasons, that one might want signed API responses independently of that (e.g. OTA software updates). Once you get into cryptographic identity though, you’re back to CA/PKI all over again...
  - speedplane 7y ago
    > it's s possible, for any number of reasons, that one might want signed API responses independently At it's core, HTTPS works because there is a distributed system of trust. The principle is that you don't need to directly trust the server that you're communicating with, but you trust another computer that has vouched for the one you are communicating with. If you roll your own security in any way, at some point you need to send an encryption or decryption key. Even "unhackable" encryption algorithms are worthless if your adversary knows the key. Thus, you need a way to communicate that initial key information securely. Currently, the only way to do that is by (1) manually entering the key on each server, (2) using near sci-fi technology like quantum communication, or (3) by having the keys pre-installed on every machine by the hardware manufacturer or OS provider. The option that has worked, HTTPS, uses option 3. Maybe you can roll your own encrypted communication system, but you'll either have to rely on manually entering the keys (which in turn rely on other insecure methods like email and phone), or trust the computer's manufacturer to pre-install the keys on the system your using. There really is no way to "roll your own" system securely without these steps.

codegladiator 7y ago

OP is talking about system 1 getting a response generated by system 3 VIA system 2 (potentially trusted man in the middle). And they are already assuming that system 1 and 2 talk using https and system 2 and 3 talk using https.

speedplane 7y ago
> OP is talking about system 1 getting a response generated by system 3 VIA system 2 (potentially trusted man in the middle). So they are effectively saying that they do not trust system 2. If that's the case, a signature from system 2 would not help because the signature itself could not be trusted. They would need the signature from the original source, system 3.
- codegladiator 7y ago
  > a signature from system 2 That's why they are talking about signature from system 3 along with the payload. So even if they trust system 2, they can be sure system 2 has not tampered with the message generated by system 3.
  - speedplane 7y ago
    > That's why they are talking about signature from system 3 along with the payload. So even if they trust system 2, they can be sure system 2 has not tampered with the message generated by system 3. No that wouldn't work by itself. System 2 could tamper the data, create their own signature, and send it to system 1. The only way it could work is if System 1 got the signature directly from System 3, or at least got System 3's public signing certificate. Either way, System 1 needs to communicate directly with System 3 to ensure the data it's getting from System 2 is authentic.
    - codegladiator 7y ago
      I think you are right. At some point system 1 will need to talk to system 3 to validate the message (unless system 1 and 3 have an already shared secret or public key)

kelnos 7y ago

I'm not really sure how to explain this any better, but let's try: Our cast of characters: Service A, Person 1, and Person 2. Person 1 makes an API request to Service A. It's done over HTTPS, and Person 1 trusts that the response received is genuine, because it came over HTTPS, and certs were verified and so forth. Person 1 sends the text of the API response to Person 2. Let's say Person 2 is a journalist, and Person 1 is a potential source. Person 2 doesn't know Person 1, and so logically doesn't blindly trust them. But Person 2 wants to report on some factual thing about the API response. How can Person 2 be sure that Person 1 hasn't modified the API response before Person 2 receives it? If the API response is signed somehow, Person 2 could go retrieve Service A's public key (directly from Service A) and independently validate that the API response was actually received from Service A, and that it hasn't been tampered with. I'm not sure I agree with the original author that this is a critical problem that needs to be solved, but that's the gist of it.

speedplane 7y ago
> How can Person 2 be sure that Person 1 hasn't modified the API response before Person 2 receives it? ... If the API response is signed somehow, Person 2 could go retrieve Service A's public key (directly from Service A) and independently validate that the API response was actually received The problem here is that Person 1 cannot be trusted, so they can't be the one providing the signature. Even if Person 1 signs, hashes, or encrypts the message when sending to Person 2, all it can prove is that it came from Person 1, not that it came from Service A. If Person 2 wants to be sure that the message it got from Person 1 actually came from Service A, it will need the signature provided by Service A, not Person 1. To get the valid signature, it will need to contact Service A. This is a long-winded way to say that if you want to trust what you got, you've got to go to the original source. HTTPS provides tools to do exactly this, and it's special because every time you buy a computer or server, trusted certificates are pre-installed on the machine. Without that initial level of trust, you can't trust anything you receive from anywhere.