2

We are using object storage from the vendor of our cloud server to store image templates (vhd) of our cloud server in the event that we need to re-provision our server install quickly. We would like to transfer this via an API to another vendor to provide an additional layer of security should something happen to our primary vendor.

Both vendors provide encryption for the vhd in object storage at rest, but there is a concern that the data should also be encrypted during transit. The API will be using the HTTPS protocol, but management thinks that is not sufficient and that we need to encrypt the data itself before it is sent. The vhd file is about 12G, so it will take some time to transfer. So assuming that both ends of the transaction provide encryption at rest:

Is SSL/TLS sufficient for safe transit of the file?

Does HTTPS/SSL protect binary data or just plain text?

Does the length of time that it will take to transfer a file of that size pose additional security risks over plain text?

Is the concern with the additional layer of encryption justified?

  • 1
    yes, both, no, not without elaboration on your high-profile risk. – dandavis Nov 27 '17 at 19:47
  • "but management thinks that is not sufficient" - how would we know what your management consider adequate? You should be asking them, not us. – symcbean Nov 27 '17 at 19:48
  • @symcbean, I should not have phrased it that way. They simply wondered if SSL was adequate given that we have used PGP and AES for a few other projects, though in those cases data was not protected at rest. – Louise Eggleton Nov 27 '17 at 19:52
  • @dandavis, if you create an answer from your comment, perhaps with a little more detail, I will accept it. – Louise Eggleton Nov 27 '17 at 20:06
  • you should accept the answer given, it's a pretty good elaboration. – dandavis Nov 28 '17 at 0:53
4

This question can be rephrased as: Is there a situation in which the attacker can compromise TLS, but not additional encryption? The answer lies in the implementation of either system.

The API will be using the HTTPS protocol, but management thinks that is not sufficient and that we need to encrypt the data itself before it is sent.

Management always seems to think that more is better, but you have to think about where the keys are in order to develop a threat model. Are the servers which have the data the same servers that are establishing the TLS connection? If so, then encrypting it before being sent would provide no benefit, since a compromise of those servers would simultaneously provide both encryption keys.

Is SSL/TLS sufficient for safe transit of the file?

Assuming it is properly configured, it is safe and sufficient. You want to select a secure cipher suite. There are online guides for selecting a good TLS suite. For an internal API, not all of this is needed, as you can act as your own CA safely.

Does HTTPS/SSL protect binary data or just plain text?

In the HTTP protocol, the only thing that hints at the type of data is the Content-Type header. This header tells the end application how to interpret what it receives. TLS operates on a layer above that, and as such the encoding is irrelevant. It blindly encrypts all data, including headers.

Does the length of time that it will take to transfer a file of that size pose additional security risks over plain text?

The amount of time it takes to transfer data over TLS does not impact its security. No modern cipher is going to weaken just because you are encrypting a large amount of data. TLS is fast enough that, on all but the oldest hardware, it will perform equally well as a plain connection.

Is the concern with the additional layer of encryption justified?

Assuming your network topography is such that TLS will provide end-to-end encryption, then no, there is no justification for additional crypto. The added complexity may introduce bugs. If you control both servers, you can use a self-signed certificate and verify the fingerprint, so you do not need to rely on a CA for authentication.

In other words, the only time that it would not be sufficient is if any of the following is true:

  • There is a weakness in the design or implementation of TLS.
  • A feature you require is not present in TLS.
  • There is a situation where an attacker can obtain the TLS key without obtaining the other key.

If none of these are true, then TLS will provide three primary guarantees:

  • Authentication - You can be sure that the connection on the other end is who they say they are.
  • Integrity - In-transit data cannot be modified without the other end being aware of it.
  • Confidentiality - All traffic will only be readable to intended parties.

Extra encryption using GnuPG for example will provide no additional guarantees.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.