JSON RPC over TLS是否足够安全？

Question

I intend to have a PHP web service accepting JSON-RPC over TLS (HTTPS). Every client will have an API key that I will use for identification purposes. Is that enough security, is there a JSON-RPC security specific standard?

Answer 1

That's a fine way of doing things. Here's an overview of the requirements and components play in your security scheme:

Checklist

Here's the checklist of what security is needed, and how you would address it:

• A third party can't eavesdrop on your communications. HTTPS provides this.
• A third party can't tamper with your communications. HTTPS provides this too.
• The client can authenticate the server. HTTPS provides this (*).
• The server can authenticate the client.

Client authentication

There are lots of way to authenticate the client. Here are a few exaples:

• Use the API key to calculate an HMAC of the request and include the HMAC as a header in the request . (**) The most secure, but more complicated to set-up. The key advantage is that should your server be compromised, API keys won't be exposed.
• Include the API key itself in the request . Easier to set-up, may be sufficient security depending on your requirements.
• ...

---

(*): So long as the client library does. HTTPS requires that you use a certificate that validates your site corresponds to the domain name. Unfortunately, many HTTPS libraries do not validate this by default.
(**): You should also use a nonce to prevent against replay attacks.

Answer 2

You could be signing a request using a secret salt (+hashing algo of choise, MD5 will do fine) because this way an eavesdropper cannot obtain the "API key" and forge his own requests. Use a very long salt.

The salt also acts to protect against intentional altering of a message by a successfull eavesdropper.

How can there be a man in a middle? TLS(SSL) is not much security against man in the middle attacks, unless you issue whitelisted certificates per client. For example, the server in the middle (attacker) obtains valid certificates, or the client application is not checking for various certificate validity settings (expiration dates, etc.). If not under your control, it is likely that clients of your RPC server will connect without doing any sort of security checks. This is a widespread problem. Eavesdropping usually implies access to your (or your client's) network so this could mean poisoned DNS traffic redirects to the rogue server .

Wether your or your client's network connection is secure enough to exclude the possibility of DNS poisoning, or your client is checking the certificates for validity, or you force the client to use whitelisted SSL certificates, are things only you can influence or decide upon.

You might also want to prevent replay attacks by assigning a unique number for each request (possibly overkill if these API calls are just for reading) for denying duplicate requests.

The API keys you mentioned, are generally used when browser side JavaScript clients are involved to track usage. API keys are reissued, when stolen, to identify and disable unauthorized apps (and maybe automatically make a list of the fraudulent domain names for further [lawsuit] action).