2

I understand that SSL connections already has its layer of encryption to protect data transmitted between a client and server.

Assuming that my connection has SSL, does it still make sense for me to encrypt data that is transferred between a client and server using keys?

For instance, I might be sending and calling a REST API with sensitive information. Can I just send them in clear text over HTTPS? I believe this should already be safe with SSL right?

Or should I still encrypt sensitive data before sending? But does it even still make sense to double encrypt the data since I'm already on a HTTPS connection?

xenon
  • 355
  • 3
  • 7
  • @Arminius I'm not asking about multiple encryption. I'm more concerned about whether it makes sense to do encryption on a SSL connection. – xenon May 10 '17 at 13:58
  • Well, this way you're certainly layering encryption. Which attack scenarios are you concerned about? – Arminius May 10 '17 at 14:01
  • if you want the server to be able to read the data, it makes no sense, for e2e it makes total sense. – dandavis May 11 '17 at 17:06

2 Answers2

4

It mainly depends on the risks you want to mitigate. If you can (reasonably) trust all the infra around the server, and if you do not need to protect this data from a corporate deep inspection proxy, you can trust the SSL/TLS encryption layer.

You should normally only add another encryption level in the following use cases:

  • you are at work behind a corporate proxy with deep packet inspection and the data is sensitive enough to require being hidden to the local network support team
  • the data should never be on decrypted form on the server. This can be used if you cannot trust the server admin team

An example of the latter use case is the exchange of S/MIME encrypted mails. You still use TLS to protect the communication (mainly the credentials) but only the final recipient will be able to read the message: the mail server admin only finds a crypted payload.

Serge Ballesta
  • 25,636
  • 4
  • 42
  • 84
1

If the client and server can be authenticated and the client is authorized to access the data, encrypting the data does not provide any additional security.

However, if the communication channel could be compromised (for example through a proxy server that acts as a man in the middle) your data may be at risk. Correctly authenticating the server on the client side (e.g. certificate pinning) can prevent this.

Jonas Köritz
  • 320
  • 1
  • 10
  • By "the client and server can be authenticated", do you mean something like a user account login page sort of authentication? – xenon May 10 '17 at 13:51
  • The client has to be authenticated (for example though a login or client certificate) and the server has to be authenticated through strict certificate checks to make sure that your client is talking to the correct server. Some proxy server applications will allow you to eavesdrop on HTTPS connections by issuing certificates signed with their own CA-Certificate, this can be detected on the client side. – Jonas Köritz May 10 '17 at 13:53
  • Oh I see... I'm not sure if I understood what "proxy server applications" are. Do you have any examples of such applications? – xenon May 10 '17 at 13:59
  • Examples of "SSL Decrypting Proxies": [Palo Alto SSL Forward Proxy](https://www.paloaltonetworks.com/documentation/61/pan-os/pan-os/decryption/configure-ssl-forward-proxy), [Trend Micro HTTPS Decryption](https://docs.trendmicro.com/all/ent/iwsva/v5.5/en-us/iwsva_5.5_olh/about_https_decryption.htm), [Checkpoint HTTPS Inspection](https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk108202) – Jonas Köritz May 10 '17 at 14:02
  • 1. An employer might deploy the CA-Certificate used by the proxy server to re-encrypt the traffic after inspection. 2. All clients will accept the forged certificates created by the proxy. 3. The proxy is able to man-in-the-middle all TLS sessions. – Jonas Köritz May 10 '17 at 14:03