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?

5
  • 2
    yes, both, no, not without elaboration on your high-profile risk.
    – dandavis
    Commented Nov 27, 2017 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
    Commented Nov 27, 2017 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. Commented Nov 27, 2017 at 19:52
  • @dandavis, if you create an answer from your comment, perhaps with a little more detail, I will accept it. Commented Nov 27, 2017 at 20:06
  • @dandavis, I did accept the suggested answer and it is the type of answer I was looking for. The answer was not present when I made my comment. Thanks for your help. Commented Nov 28, 2017 at 10:02

1 Answer 1

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. Some block modes, like GCM, can only encrypt a certain amount of data with one key/nonce combo securely, but the nonce is changed for each 16 KiB TLS record. 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.

6
  • "No modern cipher is going to weaken just because you are encrypting a large amount of data." Technically this isn't entirely true; the widely-used Galois/Counter Mode of operation for block ciphers, used in (among other places) AES-GCM which is a popular cipher for TLS, has a practical limit of just under 64GB of data with a given key + IV/nonce and loses security beyond that. However, TLS rotates the nonce constantly in much smaller chunks so this isn't a problem for HTTPS. Other ciphers also suffer if IVs are reused too often, as in WEP.
    – CBHacking
    Commented Apr 24, 2022 at 6:48
  • @CBHacking Good point. I edited my answer. Regarding WEP though, I don't think I'd consider RC4 to be a good, modern cipher!
    – forest
    Commented Apr 25, 2022 at 20:42
  • That's fair, but the weakness wasn't due to RC4 as I understand it? Any cipher, certainly any stream-like cipher including things like AES-CTR, would have been vulnerable under those conditions.
    – CBHacking
    Commented Apr 26, 2022 at 23:10
  • @CBHacking There were several weaknesses in WEP. One of them was due to how small the IV was (24 bits), causing multiple frames to be encrypted with the same keystream (so the XOR of the ciphertexts will result in the XOR of the plaintexts), but the most serious vulnerabilities were in RC4 itself in the form of related key attacks since the state array was generated from the key concatenated with the IV. If you generate multiple keystreams with multiple RC4 instances each with a key differing only slightly, you can reconstruct the state array.
    – forest
    Commented Apr 26, 2022 at 23:17
  • 1
    @CBHacking If RC4 has to be used, the proper way to feed it an IV is to pass the key and IV through a hash function and then use the digest as a key. But then you'd still need to make sure the IV is large enough and take into account RC4's other serious weaknesses (the bias towards 0 in the first 257 keystream octets, the ABCAB digraph biases, etc). WEP was just so bad that it was broken in both generic ways that would have equally impacted ChaCha20, as well as broken because of its use of a really, really bad stream cipher.
    – forest
    Commented Apr 26, 2022 at 23:31

You must log in to answer this question.

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