It hasn't seen much action in a while, but maybe thats cos it works?

And yes, I think the ergonomics are bad. Having varnish lose visibility into the transport means ACLs are gone, JA3 and similar are gone and the opportunity to defend from DoS are much more limited.

Crypto used to be expensive in 2010. It is no longer that expensive. All the serialization, on the other hand, that is expensive and latency is adding up.

Every single HTTP server in use out there has TLS support. The users expectation is that the HTTP server can deal with TLS.

Now that Varnish has been renamed, Varnish Software will keep what has been referred to as a downstream version or a fork, which has TLS built in, basically taking the TLS support from Varnish Enterprise.

This makes Hitch a moot point. So, I assume it'll receive security updates, but not much more.

Wrt. separation of concerns. Varnish with in-core TLS can push terabits per second (synthetic load, but still). Sure, for my blog, that isn't gonna matter, but having a single component to run/update is still valuable.

In particular using hitch/haproxy/nginx for backend is cumbersome.

TLS is a primary concern on the internet today.

I already commented on the separation of concerns in the tutorial, and the unpublished project which one person from uplex is working on full time will have the key store in a separate process. You might want to read the intro of the tutorial if you have not done so.

But the main reason for why the new project will be integrating TLS more deeply has not been mentioned: It is HTTP/3, or rather QUIC. More on that later this year.