[developer2]

The one thing a lot of people don't consider is that placing an entire site on https/ssl/tls ruins the traditional approach to caching. 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.

There are numerous approaches to make tls-for-all work, but they take more engineering effort. And some introduce security problems, like people who use CloudFlare which decrypts your traffic and then (optionally!!!) re-encrypts it between their servers and yours. Even taking the best encryption scheme with a CDN like CloudFlare still means that the CDN has full access to unencrypted payloads. That is an insane amount of trust to give away to a 3rd party company.

There is also an impact for large organizations that run everything through a local cache (like Squid). You can't share a cache between multiple clients when TLS is used. This push to encrypt everything means we're at the end of the era where such caches are useful. Does BuzzFeed really need to be encrypted?

One of the largest gaps in encryption in general is still performance. 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.

[pfg]

> 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

[technion]

    like Squid

I think the answer to that is that the days of local caches being useful are long gone. The top traffic count on many networks ends up being things like Youtube, and very few people are going to see the value in attempting to locally cache that sort of data.

Even if served over http, tonnes of traffic is uncachable anyway due the increased use of dynamic resourcing. Even this basic looking HN page will end up uncached by Squid because I'm logged in, regardless of https being in the picture.

As for performance, I've played around with benchmarks using Goad on a micro tier EC2 instance and never found an appreciable difference between http and https.

[nsgi]

> That is an insane amount of trust to give away to a 3rd party company.

Why is it insane to give that trust to a carefully selected business partner, but not the random 3rd parties with access to plain HTTP content? Also, your CDN has access to unencrypted payloads anyway, whether it's encrypted elsewhere or not.