6

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.

Rickky13
  • 163
  • 1
  • 7
  • 1
    with encrypting you mean using https? – layton May 22 '20 at 06:02
  • ah, no encrypting using chipers ( i.e. AES / RSA combo ) – Rickky13 May 22 '20 at 06:09
  • 5
    Can you provide more details? Why is TLS not sufficient for your needs? – Marc May 22 '20 at 06: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 '20 at 07:31
  • apparently they had concerns for replay attacks. IMO, TLS should resolve that I am just puzzled by the approach to resolve the issue and wondering if there is a general practice for this. – Rickky13 May 22 '20 at 08:22
  • Uh, not a good idea to be using a revealing key like "encrypedData", is it? – auspicious99 May 22 '20 at 11:37
  • 3
    Yes, TLS does already provide replay protection. – auspicious99 May 22 '20 at 11:44
  • No, don't do that, you don't need additional encryption. You will make things harder for yourself, not for a hacker. Just use certificate pinning for your TLS connection if you want to make additional hardening. – Alexander Fadeev May 22 '20 at 11:45
  • we can replay the full packet with TLS 1.2, ( not quite sure with 1.3 but most mobile doesnt support it) i got it from here: https://stackoverflow.com/questions/42288778/does-tls-prevents-replay-attacks-if-the-originator-is-compromised-intentionall – Rickky13 May 22 '20 at 11:46
  • @Rickky13 that link doesn't actually say replay attacks are possible with TLS, nor should they be possible. If you are concerned about the client replaying data, that's something different. – multithr3at3d May 22 '20 at 13:11
  • main concerns would be session hijacking and replaying certain transactions. similar to @auspicious99 as a suggestion it was recommended to encrypt the data in such way (above) where i don't see the benefit in doing so. 1) whats the point of all the users of having the same key 2) whats the point of using the same key to encrypt everything. Hence the Question^ – Rickky13 May 22 '20 at 14:52
  • Setting aside the question of whether it would be good to use additional encryption or not, now, if you were to do it, you definitely wouldn't want to have all users using the same key. It should be more of, keys derived from shared secrets between the server and each mobile device. For example, in a previous project where we were made to encrypt sensitive data over and beyond what TLS provided, we derived shared secrets partly from the push notification tokens, that were unique for each mobile and known by mobile and server. – auspicious99 May 22 '20 at 15:52
  • @auspicious99 Not calling encrypted data `encryptedData` would just be security through obscurity. Besides, everyone can guess that it's encrypted data when it's just a seemingly random bit pattern. – Philipp May 22 '20 at 16:46

3 Answers3

13

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?]?

Pedro
  • 3,911
  • 11
  • 25
  • 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 '20 at 06:40
  • 3
    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 '20 at 12:14
3

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.

Prime
  • 472
  • 6
  • 14
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.

auspicious99
  • 493
  • 3
  • 17
  • 4
    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 '20 at 08: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 '20 at 11:35
  • 5
    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 '20 at 17:11
  • Some questions: https://security.stackexchange.com/questions/178315/do-i-need-additional-encryption-on-top-of-https-for-a-rest-api https://stackoverflow.com/questions/7856604/encrypting-data-on-application-layer-on-top-of-ssl https://security.stackexchange.com/questions/153677/layering-encryption-on-top-of-https https://security.stackexchange.com/questions/100321/mitigating-ssl-bypassing-on-ios – Conor Mancone May 22 '20 at 17:15
  • @ConorMancone is correct. I personally would almost never recommend encryption on top of HTTPS. I have only seen it with pentesting C2 frameworks that try to hide data after encryption is broken – pm1391 May 22 '20 at 17:20
  • 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 '20 at 17:31
  • The main thing is that if https is broken then man in the middle attacks modifying the client code are nearly certainly possible. Obviously passive attacks are a theoretical risk one could model for, but the combination of 'https is broken' and passive attacks being possible whilst active attacks are not sounds like a very rare threat level. – David Mulder May 22 '20 at 17:41
  • @DavidMulder This is not a web interface but REST API for mobile apps. So client code is not transported over the network but resides in the mobile app. Good point about MITM, though. Couldn't that be fixed with authenticated encryption? So there could be value too even in the event of 'https is broken'. – auspicious99 May 22 '20 at 17:56
  • @ConorMancone Thanks for the links. I looked at them and have added some thoughts to my answer above. – auspicious99 May 22 '20 at 18:17
  • @auspicious99 It's the same for mobile apps - to an extend - as if https is broken then the update mechanism from the app stores will be - most likely - broken as well. Just like with a web app a native app still loads new code over the network. Talking about https being broken is such a conceptual hypothetical that's it feels odd to discuss. To be fair the one thing mobile apps have going for them that it's a different (set of) certificates than the ones on the REST service which could be relevant, but then again REST services and 'the main web app' tend to also be different servers. – David Mulder May 22 '20 at 19:08
  • @DavidMulder I think we may be talking about different things. You're talking about an extreme case, which you described as "https is broken", whereas I'm also including things like tls misconfigurations (including cases where the allowed cipher suites include cipher suites that are vulnerable to various attacks). In such cases it is totally plausible that the mobile app updates coming from the AppStore or Google Play, are coming over a different TLS channel than the client/server comms that we are discussing here. There may be no breach for those updates. – auspicious99 May 23 '20 at 02:12
  • 2
    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 '20 at 15:17
  • Thanks @Rickky13 . Regarding mobile and web apps not sharing the API, in projects that I've worked on, the web and mobile APIs have often been separate anyway. So in that project I mentioned where we were made to encrypt some sensitive data in mobile REST APIs, the pen testers only suggested that for the mobile APIs, not for the web APIs. I think TLS should be sufficient to protect against replay attacks, if properly configured. Against TLS session hijacking, cert pinning on top of TLS should be sufficient. – auspicious99 May 24 '20 at 05:37
  • But if you also have higher layer concepts of sessions, e.g., application layer sessions, then it depends on the higher layer protocol. Regarding the pentesters having the upper hand due to the need to close the project, yes, especially if your client agrees with them and cannot be persuaded to over-ride some of the findings/suggestions. – auspicious99 May 24 '20 at 05:41