It's a good product for what it does -- I've rescued more than one site using it -- but the politics behind it have always been a little weird. Some of it is subtleties of Danish culture and humor not coming through. But if you're actually running Varnish the way he'd like you to, chances are something isn't quite right with your architecture. Poul-Henning has strong opinions on everything from virtual memory to life…
SSL revisited
31–40 of 69 posts
Re: SSL revisited
#32It's a good product for what it does -- I've rescued more than one site using it -- but the politics behind it have always been a little weird. Some of it is subtleties of Danish culture and humor not coming through. But if you're actually running Varnish the way he'd like you to, chances are something isn't quite right with your architecture. Poul-Henning has strong opinions on everything from virtual memory to life…
Re: SSL revisited
#33Relatively recently I wrote a purpose-built web server that supports HTTPS and links with libssl. The experience was both good and "interesting". The good is that it's actually pretty easy to use libssl, even though the API is pretty terrible. Other than the configuration you already see in products like apache2/nginx/etc. there aren't many knobs and levers to worry about. You simply hand a socket over to libssl and…
If your site runs fine, in all situations you care about, without FOO, you would be pretty lame if you increased its complexity with FOO nonetheless, for any value of FOO.
That is more or less exactly the central argument of the piece I wrote.
The KISS principle dictate that I do not add SSL/TLS to Varnish, because it would just increase complexity without any comparable net increase in benefits.
Yes, it's probably (slightly) more work to configure a SSL-terminating proxy and varnish, but that is the maximal benefit you can hope to obtain if I implement SSL/TLS.
On the other hand, having SSL termination in a clearly defined separate layer gives you at least the following benefits:
You can change implementation in one layer without affecting the other.
You can scale one layer separate from the other.
You can have different administrator access in one layer than the other.
You can scale the SSL layer for CPU and the Varnish layer for RAM.
You can have multiple independent implementations of your SSL termination, thereby vastly increasing the chances that you don't have to shut down next time some SSL library breaks.
&c &c &c
Re: SSL revisited
#34It's a good product for what it does -- I've rescued more than one site using it -- but the politics behind it have always been a little weird. Some of it is subtleties of Danish culture and humor not coming through. But if you're actually running Varnish the way he'd like you to, chances are something isn't quite right with your architecture. Poul-Henning has strong opinions on everything from virtual memory to life…
Re: SSL revisited
#35I hope to update it soon to support ECDSA keys in addition to RSA. (This wasn't previously possible, but I think it's now possible with OpenSSL 1.0.2.)
Re: SSL revisited
#36Earlier quoted context omitted.
> SSL Everywhere will force institutions to either block any internet connectivity or impose Man-in-The-Middle proxies MITM proxies are already how many organizations handle web filtering. (aka "transparent proxies") TLS just necessitates that the organization have some control over the device being MITM'd to do so. (to install their cert)
... And now they also need to circumvent Googles cert-pinning and other attempts to twart even legally mandated MiTM proxies... Either all MiTM needs to be outlawed (with actual laws) or protocols need to recognize that laws mandate MiTM some places, and accommodate that with minimal loss of security and privacy. The current weapons race just makes things more and more broken.
Re: SSL revisited
#37It's a good product for what it does -- I've rescued more than one site using it -- but the politics behind it have always been a little weird. Some of it is subtleties of Danish culture and humor not coming through. But if you're actually running Varnish the way he'd like you to, chances are something isn't quite right with your architecture. Poul-Henning has strong opinions on everything from virtual memory to life…
Refusing to use a piece of software because the author has "strong opinions" seems very strange to me. Most of the best software I use is "opinionated" in some way. The trick is to pick software whose opinions best match your own.
Getting a read on where the product is headed -- by being aware of corporate motives or by reading developer's ranty blog posts -- can be part of the strategy. Percival, Torvalds, Fried -- I kinda know what to expect from them moving forward.
This guy is playing a similar game but not doing it right.
Re: SSL revisited
#38Earlier quoted context omitted.
... And now they also need to circumvent Googles cert-pinning and other attempts to twart even legally mandated MiTM proxies... Either all MiTM needs to be outlawed (with actual laws) or protocols need to recognize that laws mandate MiTM some places, and accommodate that with minimal loss of security and privacy. The current weapons race just makes things more and more broken.
Local CAs are allowed to override even cert-pinning for this reason.
If you're an employee you have to put the company CERT on your smartphone ?
How does that improve your security ?
Re: SSL revisited
#39I can sympathize with the author's feeling. TLS is incredibly complex. It seems that TLS libraries are all bad, setting them up is incredibly difficult, and hell, all the complaints about OpenSSL are not enough to do justice to its quality. But no, Varnish is the optimal point for doing encryption, and placing anything on its front is contrary to any reason somebody would have to use it.
Re: SSL revisited
#40Earlier quoted context omitted.
Refusing to use a piece of software because the author has "strong opinions" seems very strange to me. Most of the best software I use is "opinionated" in some way. The trick is to pick software whose opinions best match your own.
Actually the trick is to pick software that meets the needs of the technical problem at hand. Getting a read on where the product is headed -- by being aware of corporate motives or by reading developer's ranty blog posts -- can be part of the strategy. Percival, Torvalds, Fried -- I kinda know what to expect from them moving forward. This guy is playing a similar game but not doing it right.
I 100% agree with the view that caching and tls termination/load balancing are two different tasks, suited to two different tools.
The stated reason for this approach is keeping the existing excellent solution, from becoming worse without any real gain.
Yes the author has stated views about the use of tls "everywhere" - specifically because varnish doesn't handle tls, those opinions don't affect the tool at all.
Edit: s/told/tls/ damn you autocorrect!