Should one encrypt traffic even when using HTTPS?

Question

I took a look at google and here and I coudn't find the answer to this question:

Let's say that I have a Webservice and an Android app. They communicate over HTTPS. Should I encrypt traffic or I can assume that the communications are relatively secure?

I'm not considering cert pinning here. In this case, cert pinning use would change the security measures that I should put in place?

Edit 1:

This scenario comes to my mind when considering that an attacker that controls the device running the app (that is fairly easy) can intercept the communication and see every bit of clear information being transmitted.

Scenario: I have a app that can make payments with credit card. Should I rely on TLS to secure the credit card information being sent?

Not sure, see if adding HSTS header in Webservice's HTTP response can help in case of MITM. — Krishna Pandey, Jul 21 '17 at 19:14
As for Edit 1: if an attacker controls the device he can not only intercept communication but also intercept data before the additional encryption. — Steffen Ullrich, Jul 21 '17 at 19:45

whoami · Answer 1 · 2017-07-21T18:59:01.300

If the communication is happening over HTTPS then it is already encrypted. HTTPS includes the SSL/TLS end-to-end encryption between client and web server.

So in short, no, you do not need to encrypt it any further provided that you implemented HTTPS correctly.

For more details, see this post: How does SSL/TLS work?

UPDATE in response to the update to the question:

If an attacker is in "control of" the user device running your app, security is compromised no matter what way you look at it. Your encryption/security procedures kick in before the sensitive information is being communicated over the network. However, while the user enters, say, his credit card number on his cellphone, it is still in plaintext and vulnerable to the attacker in control.

So yes, you can rely on TLS to secure the credit card information being sent. But there's not much you can do as an app developer against an attacker in control of the device.

Yes, I'm aware of that, but it is too easy to setup an MiTM attack if the attacker control the device running the app. This allows the interception of every bit of information. I think that I should have stated it on my answer. My bad. — luizfzs, Jul 21 '17 at 18:48

score 1 · Answer 2 · answered Jul 21 '17 at 19:12

Generally speaking, it depends on what your threat model is, and how you intend to encrypt the data.

For the specific scenario you describe, a web-based payment form that a user enters credit card data into, an additional layer of encryption makes little sense. You still need to be able to decrypt the data once it gets to you, and apart from TLS itself, you have no simple and secure mechanism by which to get a key to user to do an additional layer of encryption.

For other scenarios, like a password manager an additional layer of encryption may indeed make sense...When the crypto can be contained in a browser extension, for instance, and the key can been derived in memory from a password, and your service need only store the encrypted blob, and does not need access to the plaintext data.

So, use case is important, the threat model for the application and data are important, and the mechanisms that you have access to and can reasonable inflict on your users are important before you can decide whether this makes sense or not. It sounds like for your case, it doesn't, and TLS alone, well configured, should suffice.

Should one encrypt traffic even when using HTTPS?

2 Answers2