| > It used to be very simple to add a full-page caching layer in front of your unencrypted application. TLS completely destroys this. You can no longer simply plop a proxy cache in front of your application. I wouldn't say it's no longer possible. You have to do your caching before the TLS termination, and you'll have to pay the encryption overhead for every resource. > This push to encrypt everything means we're at the end of the era where such caches are useful. You can still do this kind of caching if you install your own CA certificate on all your devices. Almost all enterprise deployments will do this anyway so that their security appliances can scan TLS traffic. Squid supports this. > Does BuzzFeed really need to be encrypted? Yep! Otherwise, that free WiFi at your favourite cafe, or your ISP, might inject malicious code or ads. > You hear all the time how TLS adds almost zero overhead anymore. This is simply false for most of us. Not everyone is Google who has their own custom low-level encryption implementation. Those of us using off-the-shelf software continue to pay the price of CPU overhead. Obligatory reference to https://istlsfastyet.com/ There are two aspects here: Handshakes and encryption performance. Handshakes are expensive, you can probably do about 500-1k handshakes per core per second with a 2048 bit RSA key. This is usually no big deal in production because you can use session resumption, meaning once you've completed a handshake with a user, you can skip that part until the cache expires (people tend to use one day as their lifetime). The second aspect, raw encryption performance with a symmetric cipher, is something you don't get to complain about unless you're Netflix. Any server CPU with AES-NI can push at least 500MB/s per core per second, probably more. You'll run into some other bottleneck way before TLS performance becomes an issue. Unless you're Netflix, of course[1]. [1]: https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf |