Feature suggestion: Implement RFC 9421 in all API calls, to improve security

API Feedback
1

I am an ICP blockchain developer. ICP software sends 13 (or more, for extra security) duplicating HTTPS requests for each connection to the external Internet.

I developed GitHub - vporton/join-proxy: This will contain a proxy that intentionally delivers outdated data for it to respond to 13 requests sending just one request to the queried server like OpenAI. (That’s useful to reduce costs and throttling rate.)

But using Join Proxy nullifies blockchain-based security: One who have stolen the hosting password for my Join Proxy instance, can (partly) control the system, that is blockchain security is compromised.

To solve the problem, please implement RFC 9421 - HTTP Message Signatures for all API requests. Using this, I will be able to rewrite my API for calling Join Proxy from ICP to validate, that the request really came from OpenAI API, so if Join Proxy hosting is hacked, this will be only a DoS, not full-blown data substitution, because I will be able inside the smart contract to check whether data was substituted by the public key that you will in some way publish (preferably as a special API endpoint that will deliver your public key).

Note that you already use RFC 9421 in ChatGPT, what may simplify its integration into your API.

This is necessary not only for me, but for every ICP dev that needs to connect to OpenAI not compromising security. It may be useful not only for ICP blockchain users, but in every imaginable situation that one needs to check validity of data from OpenAI.

1 Like
2

Additionally need to ensure that a reply from OpenAI API is unique.

To do this please add (if you already don’t have something like this):

  • The client may send X-Unique-Id header.
  • If there are several request with the same X-Unique-Id value, all but the first one must fail.
  • Unless it fails, OpenAI must send X-Unique-Id header back with the same value as receive from the client.

This together with above mentioned RFC implementation makes impossible the following attack on the hacked proxy:

  • Receive the HTTPS request from the client.
  • Forward it to OpenAI several times and choose of several the best for the hacker (and probably bad for the client) response.
1 Like
3

Probably SXG is another solution, but it may be less secure (I didn’t check, I will if you hire me as your engineer,) not checking the income request data.