Last updated on August 17, 2018
I’ve been working slowly towards moving to HTTP/2 over the past couple of months. Why? Mostly because its the new shiny and it’s supported by Nginx. Partly because H2 has benefits in reducing network connections by built in multiplexing which improves the efficency of my server and potentially the experience of visitors when loading multiple resources.
Part of HTTP/2, at least by defacto requirement is TLS encryption. The standard for HTTP/2 allows for unencrypted transfers, but none of the browsers that implement it support the unencrypted mode, and therefore there is functionally no unencrypted mode. Given that, phase one of moving to HTTP/2 was getting TLS certificates and getting that up and running.
One of the major counter arguments against TLS everywhere was that it adds compute overhead. Of course, pretty much every discussion I saw on the topic had the proponents shouting down the opponents claiming that it was only a tiny percent; hardly anything to worry about.
The reality is that the overhead of TLS can be a tiny percent, or it can be not so tiny. What it is all depends on your configuration.
Phase 2 of my plan to roll of HTTP/2 for my sites was to slowly move lower traffic stuff to HTTP/2, and see how it affected my server loads, and then move the heavier traffic sites over when I know what kind of CPU loads I could expect.
Switched the last major portion of my site over to HTTP/2 Tuesday night, and Wednesday afternoon I jumped in to the AWS control panel to see how my CPU load was doing.
What I saw was a rather continuous downward slump in CPU credits and a noticeably higher CPU load.
3-4% baseline CPU load on a t2.micro AWS instance isn’t a total deal breaker. Eventually the CPU credit pool would level out with 80-100 in reserve, and I wouldn’t be in much danger of running out unless I got seriously overwhelmed with traffic. But I’d rather not be half way in the hole if I can avoid it. Especially if there is something relatively easy to optimize to improve things — like maybe turning down the encryption strength.
There’s principal about encryption that many, including myself, seem to forget; encryption isn’t about creating a impenetrable barrier, it’s about delaying the adversary until the information is no longer useful or the amount of work necessary is greater than the value of the information that can be gained.
A corollary to that is the more valuable the target, the more resources the attacker will be willing to devote to attacking it.
So back to TLS on my VPS.
When I initially setup my TLS configuration I followed a couple of guides for strong TLS. The first cipher suites I used were from this one. I also tried The Mozilla foundation’s SSL config generator’s modern recommendation.
Both of these guides produce cipher suites that are strongly favor AES256 for the bulk cipher.
The easy assumption — the naive assumption — is that if there’s an AES256, you should use that it will be the best option. Big numbers == more secure!
The thing is, when AES128 was designed, it was designed to be really resistant to being broken. In fact, as far as I’m aware, there is no practical attack on any form of AES of merit. At best, there have been some attacks that can reduce the complexity for AES128 from 2128 to ~2126. However, 2126 complexity is still unimaginably hard to break with current technology.
But again, the question still stands, how valuable is what’s being protected?
And more to the point, having a constant 5% CPU load after enabling HTTP/2 with the bulk of the ciphers being AES256 based, is that necessary for my (or your) needs?
And this was ultimately my argument against TLS everywhere; some things just aren’t sensitive enough to require much if any security or authorization. When that’s the case, even a trivial increase in overhead becomes a much bigger concern to balance. Going from 0.05% to 3-4% CPU load, dramatically reduces the potential number of hits per second you can support.
Dropping my TLS config back to only using AES128 cipher suites, put my CPU load right back where it was before I switched everything over to HTTP/2. Given that performance, is relevant to me and none of the content here is really sensitive, I don’t see a real compelling reason to run a stronger cipher suite right now or for the foreseeable future.
And it’s not like I’m in poor company using AES128 either. Google use AES128, the Mozilla Foundation uses AES128, IRS.gov uses AES128, lots of banks use AES128, Apple uses AES128. I don’t think it’s unreasonable to consider AES128 to be secure enough for a tech blog or a photography blog.
My point here, in a rather convoluted way is simply this. If you’re moving to HTTPs or HTTP/2, and you’re in a position where CPU load is relevant. Don’t go overboard on your TLS settings unless your site or API really warrants it.