We're building a suite of mobile apps where the communications to/from the server's REST API need to be as secure as possible.

The intention is to use TLS (i.e. https) at the session layer.

However, I've become aware that, on a jailbroken/rooted device it's possible to sniff SSL traffic by inserting a trusted certificate onto the device itself.

Therefore, one idea was to add encryption at the application layer too. In the words, exchange keys with the server (server sends its public key to client, client sends its public key to server) then use these as an additional layer of security.

Would this confer any additional security benefit or is it a pointless duplication of effort?

  • 1
    "as secure as possible" is vague. What do you want to secure against? Securing against sniffing on a compromised client device is pretty extreme.
    – schroeder
    Mar 13, 2017 at 7:50
  • The session layer is apart of the application layer and https does encrypt. You need no further effort. OSI model has been condensed to the TCP/IP model in which session layer is apart of the application layer. So yes it would be pointless duplication effort.
    – nd510
    Mar 13, 2017 at 7:53
  • You don't need to jailbrake to read https traffic on smartphones. One can just add your own certificate to the phone and setup a proxy, e.g. Burp Suite, then you can read all traffic that goes between the phone and internet.
    – JoakimE
    Mar 13, 2017 at 8:12
  • The question is essentially asking how to protect data sent over TLS in case of a jail broken device. Double encryption is only a proposal on how to do it. Therefore I marked it as duplicate of Mitigating SSL bypassing on iOS (which is not specific to iOS even though the title might suggest it). Mar 13, 2017 at 9:07

4 Answers 4


You could use HTTPS with public key pinning. This way, only your certificate is valid for the communication. A man-in-the-middle attacker can no longer create a valid certificate to sniff the traffic.

Key pinning is quite common for mobile apps. You should check whether the HTTP framework you use supports it.


If your concern is a jailbroken device then adding encryption on top of TLS would add no benefit: an attacker could steal the keys from memory or use tools like frida to hijack control of the application and patch the "crypto" parts to reveal its content. If you're using PKI on top of TLS then it's just a waste of resources, and there are good chances you will implement it wrongly (think key pinning, maintaining certificate revocation lists, etc.)

In other words, if transport security is your only protection then you need to redesign your application. If you have any form of sensitive data stored client-side, perhaps hard-coded in your app which if exposed could compromise your entire network then you are doing it wrong.

There are guidelines for iOS and Android on how to store "secrets" on a phone, besides the usual OWASP REST security guide.

  • OK, so if I'm reading all this correctly then there's an intermediate 'easy' hack where the device is not jailbroken / rooted, but the user has installed some proxy like 'Burp Suite' to read all the outgoing traffic. And, in this case, it sounds like double encryption, i.e. exchanging keys at the application layer and encrypting the payload, might actually be a worthwhile thing to do to prevent this casual sniffing letting a user see the data being transmitted over the wire?
    – Carlos P
    Mar 13, 2017 at 11:24
  • @CarlosP yes, but it's just a stopgap. Don't rely on it. For example, if your app is for android and iOS then an attacker would go for Android to extract the secrets. Also, we're assuming your PKI implementation is flawless and can't be sniffed by inserting a system-wide CA. I don't think it's worth the effort.
    – lorenzog
    Mar 13, 2017 at 12:05
  • Thank you. As somebody who doesn't solely 'do' security for a living, can you please humour me for a moment and explain what you mean by inserting a system-wide Cert Authority and how this would be used to crack my proposed suggestion. I had imagined that, over TLS, the client app would get the server to send its public key, then it would transmit its own security info, encrypted using this key, back to the server. I'm now assuming this was naive? ;-)
    – Carlos P
    Mar 13, 2017 at 14:57
  • @CarlosP obviously YMMV, but what if: (i) I got my burp CA in the system, (2) your app establishes a TLS session, (3) I intercept that, (4) your app opens a TLS session on top of the previous one, (5) I intercept that too? In other words: how does your app know that it's talking to the right server if I can alter DNS queries and I can generate signed certificates with burp?
    – lorenzog
    Mar 13, 2017 at 15:35
  • Ah OK, I think I understand that more fully now. Thanks for taking the time. Ultimately, as many other posters have said too, best to just assume that all devices are compromised and consider how ones solution looks from that starting point.
    – Carlos P
    Mar 13, 2017 at 16:31

The problem with your proposal is that no amount of adding layers of encryption/PKI validation would make the compromised device safe, because the device is compromised.

I guess the question (asked by others) is what exactly you are trying to guard against: if your concern is someone 'spoofing' a user, then adding a second factor, and one hopefully involving some other device/token, would seem the more realistic approach.

It may be useful to check into how some of the available secure chat clients handle encryption and privacy: most end up assuming that a user's device can be trusted (see for example https://www.wickr.com/uploads/files/700869603163179165-wickr-whitepaper-final.pdf), and build from that fact.

Short of introducing assertion checking for user devices, there is not a lot you can do to guard against users with compromised devices. It isn't clear that you should necessarily be concerned about that - there needs to be some kind of demarcation, and assuming the device is secure is a very common one.


While there are various examples of services that do this sort of thing, none of them actually solve the problem of a compromised endpoint. As the phrase goes:

if the attacker compromises your device it is no longer your device

In effect, anything you do is pointless once the attacker has control of that device, as they can read or spoof any certificate, key or pass phrase you may use on it.

This is the area where trusted hardware modules can make a difference. If the device has a chip or module that cannot be broken into (and by cannot, I mean not in a realistic timeframe by your expected attacker) then any secret you need to use can be stored there. This still requires an architecture that prevents the attacker intercepting comms on the device, or subverting the key exchange process.

In your example, however, I'd suggest it is not realistic to add an extra layer of encryption, as it won't protect you against your stated threat model. Instead, can you disallow connection from rooted devices?

Not the answer you're looking for? Browse other questions tagged .