3 ms·
I've used varnish in the past, but I have trouble understanding where it fits in the stack right now. It doesn't do TLS. Something else needs to be put in fron
by CrLf 10y ago
I've used varnish in the past, but I have trouble understanding where it fits in the stack right now.
It doesn't do TLS. Something else needs to be put in front of it to terminate HTTPS connections. HTTP/2 support is planned but (again) with no TLS, making it a dud as browsers don't implement non-TLS HTTP/2.
The mass storage engine isn't part of the opensource release and my experience with larger-than-memory scenarios in the standard varnish has been less than stellar. Again, needing something else to handle this bit or control what's fed to it.
My conclusion is that if I always have to put an nginx in there somewhere, I might as well not add varnish into the mix.
- bryanlarsen 10y agoYou're supposed to use Hitch[1] to decrypt the HTTPS. They very much espouse the philosophy of "do one thing, do it simply, do it well, do it composably" 1: https://hitch-tls.org/ https://hitch-tls.org/
- CrLf 10y agoDoing HTTP separately from TLS in 2016 isn't doing "one thing" well, it's doing "half a thing." If you're serving HTTPS to clients and your backends are also HTTPS, you quickly get into a mess of extra components opening unnecessary sockets around just to do TLS.
- olavgg 10y agoPHK has argued that the SSL/TLS libraries we have is a nightmare when it comes security design. He rather favor "jailing" these processes as a separate process. So if hell breaks lose, like with Heartbleed, your Varnish process should still be "safe".
- CrLf 10y agoI agree. But that doesn't require showing that separation to users. Varnish could internally separate TLS from the rest while still behaving as a single service.