5

I have a mobile application and the backend is hosted on a cloud provider. I would like to ask for feedback on encrypting all REST API calls that will be used to communicate with the server, if we should or we shouldn't do it.

Adding details:

< Certificate pinning is in place >

for example instead of having a proper rest object

{
   "name" : "username",
   "info" : "profile"
}

make it similar to this:

{
   "encryptedData" : "Mq6rTVdPP1YMlE9AxhnryIRX+JA9MfIXv"
}

and after decryption it becomes the model and the flow carries on, of course the response is also expected to be encrypted in a similar fashion.

  • 1
    with encrypting you mean using https? – layton May 22 at 6:02
  • ah, no encrypting using chipers ( i.e. AES / RSA combo ) – Rickky13 May 22 at 6:09
  • 4
    Can you provide more details? Why is TLS not sufficient for your needs? – Marc May 22 at 6:33
  • 1
    You still have not explained why TLS cannot work for you. Is it due to some data being more sensitive (eg: PII), or concerns about TLS itself, or restrictions in your environment? – Marc May 22 at 7:31
  • 3
    Yes, TLS does already provide replay protection. – auspicious99 May 22 at 11:44
10

Considering that TLS is in place with a solid configuration (i.e. certificate pinning), which I find no reason not to, you'd need to work out the business risk you're trying to mitigate by encrypting this information.

Ask yourself, what would you gain by doing this? What type of attack vectors are you mitigating?

How are you going to generate, distribute and manage keys, where is the code and keys that encrypt/decrypts the data? What happens when (not if) the keys are extracted [i.e. will you be using the same key for everything?]?

| improve this answer | |
  • Thanks for you insights, given the scenario it would be really tough to manage the keys for N number of client App to Server, and would be a potential massive overhead, however if it is done adequately it is an uncommon practice but still a reasonable to perform this type of 2nd level encryption. – Rickky13 May 23 at 6:40
  • 2
    Don't think it's uncommon or over the top. Given the right use case it is neither. Also I'm glad it led you to consider key distribution carefully. An issue I find frequently is people encrypting API data with a static key also shared by the API. – Pedro May 23 at 12:14
2

One of the points of TLS is to solve this problem - a secure way to transport data across untrusted networks, preferably using ephemeral keys for the actual encryption portion. Doing this yourself is possible but is coming dangerously close to "rolling your own" as you will have to solve problems like key storage, etc.

Depending on how your backend network is setup, you may want to look at whether you are enforcing fully end to end encryption or is your TLS terminating at a load balancer or router. That is a separate topic however.

| improve this answer | |
-1

The standard practice is to use https for the baseline protection of REST API calls.

Additionally (going beyond standard practice, but preferred by some), selected information that is sent to the server or received from the server, may be further encrypted with AES, etc. For example, if there are sensitive contents, you might choose to select those to encrypt so that even if the https is somehow broken or misconfigured, you have another layer of protection from your encryption. It's easily to think that theoretically, TLS is so rock solid, but there have been various serious vulnerabilities exposed over the years, such as beast, poodle, sweet32. These may only affect certain cipher suites, but if you're not careful with your configuration for allowed TLS cipher suites, you may be vulnerable to one or more of these. Not all server-client pairs support TLS 1.3; it is sometimes said that TLS 1.3 "makes it harder for admins to misconfigure" than earlier versions like TLS 1.2.

In a previous project, a pen tester had requested for encryption of such sensitive contents, even though we were already using https.

The question of key management has been raised by others. If you were to do this, you would definitely not be using one key for every mobile to share. Rather, each mobile and the server should use a unique key. A convenient way to do this is to derive shared secrets at least partly from the push notification tokens, that are unique for each mobile and known by mobile and server (assuming the push notification is sent to the server earlier, say, over TLS alone and unencrypted).

There are other questions on this site that appear to be addressing the same question, but are not exactly, on closer inspection.

1) For this question, even though it is also using https and with a REST API, it is for a web application, not a mobile application. Hence, the accepted answer could rightly say:

For a web app designed to run in the browser, the security value of application layer encryption is basically zero. Why? Because the very code that does the application layer crypto will have to first be transported to the client. If transport layer crypto is broken, that code can be tampered with to the attackers benefit.

An important difference with mobile apps is that application layer crypto code does not have to first be transported to the client. It resides in the mobile app.

2) For this question, no justification is given for asserting that SSL alone is sufficient.

3) This question is concerning protecting data sent over TLS in cases of jailbroken or rooted phones. I agree that in that case, you'd want to focus on anti-tampering mechanisms on the phone, to protect against use of tools like Frida to hook your functions.

4) This question is also addressing a different problem.

| improve this answer | |
  • 3
    Further encrypting data that is being sent through TLS is not a normal practice, even for sensitive data. The pentester in this case was wrong, which happens. – Conor Mancone May 22 at 8:53
  • Hi @ConorMancone , do you have market stats on that? By the principle of Defense in Depth, it would appear like a reasonable thing to do, depending on the requirements. Then again, we only did the additional encryption because we were forced to, after initial protests didn't yield much success and we wanted to close the project :-) – auspicious99 May 22 at 11:35
  • 3
    I don't have any market research, but as a general rule of thumb, encryption on top of HTTPS is generally considered pointless and a waste of resources. I'm sure there are lots of questions along those lines here, because (as with questions like this) it comes up occasionally. Note for instance the comments on this question itself which all boil down to "Why would you encrypt on top of TLS?". As a security professional myself, if I suggested that as a solution in almost any context I'd be laughed out of the room and/or fired - literally. – Conor Mancone May 22 at 17:11
  • 1
    My experience has shown otherwise, it's not exactly rare to find API data encrypted over TLS. There are good reasons to do this, but it is entirely dependent on the information being handled and what kind of risks are being mitigated. Often encryption is used as a means to securely cache information locally. (Spotted this last week actually, keys not stored locally although not too difficult to capture) – Pedro May 22 at 17:31
  • 1
    This answer deserves more upvotes, IMO i felt that the REST level encryption was really bad as it breaks Restful principle in a way that mobile & webApp doesn't share the API? and what if we move from REST->Graphql; also TLS should be sufficient to resolve [session hijacking] and [replay attacks]? However, it seems like pentesters usually has the upper hand due to the need to close the project. – Rickky13 May 23 at 15:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.