0

If I exchange https packets between a server and an Android client, is it easy for the user of the client to get whatever is in the encrypted traffic? Should I consider all such traffic unsafe if the safety is dependent on the user not being able to somehow read what's in the https packets?

3 Answers 3

7

I don't quite understand what is your usage model where the security depends on the user of the app itself not able to know the HTTPS traffic.

But I believe if your app has no certificate pinning built in, and your client do not properly check the TLS connection (similar to how an end user click "Add Exception..." when the browser complains "This Connection is Untrusted"), the user can simply install a proxy (such as Burp) in the middle to intercept the traffic.

1

I would not say it would be easy for the user to get this information but it is possible. I would consider this traffic unsafe on the client end. If you are encrypting this traffic it will be harder for people other than the client to access. The client needs to be able to decrypt the information to access it so yes they can access it and it is unsafe.

4
  • So the user can somehow intefere in the whole TLS process (excuse me if I sound noobish) and gain whatever information is needed to decrypt the packets, more so than an outsider could? Do developers generally consider everything they send to the clients as unsafe with respect to the user itself? Or can I take more measures to hide the information from the user, instead of changing what I exchange between client and server?
    – utopikern
    Dec 8, 2015 at 1:04
  • For the user to decrypt the encrypted information it needs a key the key needs to be in the app or else the user can't see the message. If the user has the key in the app what's stopping them from getting it? You could generate a key for each individual connection based on connection properties like usernames or IP address so no two keys are a like.
    – ProWolf
    Dec 8, 2015 at 1:05
  • @utopikern The user can decompile your app, add a println call every time your app sends or receives something, recompile it, and then run that version of the app instead of the one they downloaded from the Play Store. (I say "just", but really that's fairly time-consuming, not least because decompilers suck. But still, users can do that)
    – user253751
    Dec 8, 2015 at 4:19
  • It is trivial to set up a debugging proxy that will let you view even encrypted communication. Dec 8, 2015 at 5:16
0

HTTPS is end-to-end encryption. That means on both ends of the connection the traffic is not encrypted, only in-between. As long as the user has full access to the device it will be possible to modify the application to intercept data before encryption or it may be possible to add a new CA and do a man-in-the-middle attack (depending on the application - if pinning is involved this might not be possible).

Thus if you security depends on the idea that the user is not able to see or even modify the traffic than your security model is probably wrong. The only thing you can do is to make it harder to analyze traffic by obfuscating code and traffic.

You must log in to answer this question.

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