12

We are serving static content over the internet, and have a business requirement that the data must be encrypted at rest. Currently it is stored in AWS S3, where it can be accessed by authorized clients over HTTP. We could proxy this through Cloudfront or Nginx to use TLS, but would only do so if it is necessary. The decryption key is retrieved by frontend client via a separate HTTPS request.

Do we gain anything by serving the static content over HTTPS, given that it is already encrypted? It brings added costs, infrastructure, and latency, and I cannot think of the benefit.

1
45

You should serve this data over HTTPS regardless. As Gh0stFish pointed out, you can simply use an S3 bucket policy to require this.

There are a couple reasons for this:

  • Using plain HTTP makes it very easy to perform traffic analysis. If I know that encrypted blob 123 is sensitive because I've already seen it or it comes from a site with sensitive information, I can see who else has downloaded this blob and associate the sensitive information with them.
  • Unlike static encryption, TLS is usually configured to provide perfect forward secrecy. That is, once the connection has been torn down, the data cannot be recovered.
  • HTTPS is now standard, and not using it, even for encrypted data, is often seen as irresponsible. If your customers inquire whether their data is served over HTTPS, you can simply say, "Yes," instead of having to explain why you don't and why it's still secure.
  • HTTP/2, which can provide significant performance improvements, is only available over HTTPS in web browsers. I don't believe S3 currently supports HTTP/2, but if it does in the future, you'll need to be using HTTPS.
  • HTTPS is fast. Most x86-64 systems will be able to handle encrypted data at speeds over 6 GiB/s on a single core, which is faster than a 10 Gb/s network card. Encryption is no longer the bottleneck that it once was, so there's little reason not to use it.
  • HTTPS provides protection against tampering with the request. For example, if I as the attacker just saw client A request file 123 and I now see client B request file 456, I could substitute the response given to client A if the key is not unique. If I know file 123 is for a publicly available sex education site and client B is a large corporation, I could substitute material which, while not pornographic, might not be appropriate for a workplace.
7
  • Thank you. Your traffic analysis comment is a good one. In our case, there will be material benefits to reducing latency (however marginally), so we'll need a legitimate reason to double-encrypt. Keys will also be unique so your last point is not applicable in our use-case.
    – pgriff
    Nov 14 '21 at 20:18
  • 4
    I'd also like to put doubt to the claim of "HTTPS is fast. When trying to reach <50ms response times from NGINX, HTTPS is definitely not fast. Often saw handshakes of 150ms. When not talking about latency but throughput, your point stands though. Nov 15 '21 at 9:32
  • 5
    +1 for mentioning traffic analysis. HTTPS encrypts a lot more than just the raw data being transmitted, and as such makes it more difficult for an attacker to figure out what's going on. If I see encrypted data being sent in a POST request over HTTP, I know that the client is sending some sensitive info to the server. I might be interested in spending some time trying to decrypt that. If I see a large HTTPS request with an encrypted request type and response code, I have no idea if this information is worth my time.
    – jaredad7
    Nov 15 '21 at 15:15
  • 1
    @DaniëlvandenBerg It's true that there is some latency in the initial TLS handshake, but subsequent connections will be much faster because the key can be cached in various ways (e.g. session tickets).
    – forest
    Nov 15 '21 at 23:46
  • 1
    Establishing host authenticity (especially in combination with HSTS) is another advantage of HTTPS.
    – idmean
    Nov 16 '21 at 10:39
9

Firstly, you don't need need to faff around with CloudFront or an Nginx proxy - you can just enforce TLS with an S3 Bucket Policy.

It's hard to know whether there are any specific benefits in your circumstances without knowing more about exactly what your use case is. It's worth remembering that TLS doesn't just provide confidentiality, it also provides integrity (i.e, assurance that the data hasn't been tampered with by a man-in-the-middle) - does your current encryption also provide that?

Depending on exactly what your static content is, you may also get browser warnings if you try and load it over HTTP, because browsers block mixed active content, which would include static things like JavaScript files or CSS.

3
  • 1
    Thank you for the bucket policy tip. To add more context, this will be a CDN-like bucket where 99% of the traffic (volume-wise) will be for serving A/V data for HLS streaming. The rest will be a mix of static images & text files. Re: your integrity assurance comment: what encryption strategy would not ensure integrity? Assuming the attacker does not have the decryption key, tampering would just render the content useless, no? Is the distinction between useless data & tampered data meaningful?
    – pgriff
    Nov 14 '21 at 19:59
  • 2
    @pgriff Any secure protocol must provide: secrecy, integrity, and authenticity. If any of these three break, then the whole protocol fails. See moxie.org/2011/04/11/ssl-and-the-future-of-authenticity.html (by one of the inventors of the Signal protocol) for some interesting reading of this subject. Also, see crypto.stackexchange.com/questions/85785/… for some interesting reading on things that the attacker can do by manipulating the ciphertext if integrity is not enforced.
    – mti2935
    Nov 14 '21 at 20:19
  • 8
    @pgriff Maybe they could return file2 when you make a request for file1. Or they could do a bit flipping attack allowing them to blindly modify or corrupt the files in transit. Or maybe swap blocks around if you're using something weak like ECB mode. Maybe the fact that you can't guarantee the integrity of the files completely undermines the confidence in your app. Without knowing more about your specific implementation, it's hard to tell. But what you're essentially trying to do is implement your own encryption protocol here - and that is a bad idea unless you really know what you're doing.
    – Gh0stFish
    Nov 14 '21 at 21:14

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.