Live data from Hacker News

SSL revisited

varnish-cache.org

21–30 of 69 posts

Re: SSL revisited

#21
I 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

#22

UPDATE/CLARIFICATION: The author DID NOT say people don't deserve privacy, he said "there are people who do not have a right to privacy" I misread that when he really meant that LEGALLY they do not have a right, not that he personally believed this. I would like to apologize for misrepresenting the author's intent. I'll start by saying I don't agree that some people don't deserve privacy. I just can't get behind that…

Let me just make absolutely clear: It's not my opinion that certain people don't deserve privacy, it is the law of the land, duly enacted and ratified by legitimate governments.

If you want to change that, vote.

Re: SSL revisited

#23

> The most obvious example is that you don't want to bog down your countrys civil defence agency with SSL/TLS protocol negotiations, if their website is being deluged by people trying to survive a natural disaster. If TLS overhead is the last straw that brings down a web site, the site's infrastructure isn't suitable for delivering safety-critical information.

This. Google measured TLS overhead on their servers – it was very small. If you can do TLS on Google scale, you can do it anywhere.

Are you willing to pay increased taxes, so that FEMA (Or your countrys similar) can afford to run 100.000 servers, in order to "do TLS on Google scale", so that they can get emergency orders out for civil defence ?

Have your forgotten (or maybe never seen ?) CNN's traffic graph from 9/11 ?

Experience so far is that emergency services web-pages tend to die the instant they are most needed. Addint TLS will just make that happen even more.

Re: SSL revisited

#24
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 on Mars and I really don't need that stuff to be part of my web stack.

A little personal maturity to match the product maturity would help both advance.

Re: SSL revisited

#25
post #3

Without discussing any of the political points (which felt out of place), this simply means that we will continue to not use Varnish. Nginx' caching is good enough that it's not worth the pain of trying to implement some wacky setup just to use Varnish.

If you don't need varnish, it would be pretty stupid to start running it...

Re: SSL revisited

#26

I'm not sure how I feel about the Political PostScript section. It raises the following points against the concept of "SSL Everywhere": - "you don't want to bog down your countrys civil defence agency with SSL/TLS protocol negotiations if their website is being deluged by people trying to survive a natural disaster" - "there are people who do not have a right to privacy" - "SSL Everywhere will force institutions to e…

> 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

#27
post #22

UPDATE/CLARIFICATION: The author DID NOT say people don't deserve privacy, he said "there are people who do not have a right to privacy" I misread that when he really meant that LEGALLY they do not have a right, not that he personally believed this. I would like to apologize for misrepresenting the author's intent. I'll start by saying I don't agree that some people don't deserve privacy. I just can't get behind that…

Let me just make absolutely clear: It's not my opinion that certain people don't deserve privacy, it is the law of the land, duly enacted and ratified by legitimate governments. If you want to change that, vote.

Apologies, the line:

> The next big issue is that there are people who do not have a right to privacy. In many countries this includes children, prisoners, stock-traders, flight-controllers, first responders and so on.

and a comment in this thread

> And I fundamentally disagree with the premise that there are people who do not deserve privacy. I can not think of a single person I would wish complete exposure of their lives upon. (https://news.ycombinator.com/item?id=9454402)

caused me to misinterpret that. Do not have a right != Do not deserve. I am very sorry that I implied something that is not true. I am editing my original post to clarify this.

Re: SSL revisited

#28
Relatively 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 does the heavy lifting. Then you use the libssl functions to read/write data and you can even use select() and friends to check if the socket is ready.

The "interesting" part comes from the fact that a socket may read when you want it to write and vice versa: the underlying protocol is more complex than just pushing bytes. This means that the socket needs to be able to read and write when you want to do one of those operations. There is also fragmentation of your data. You say "send this 8 KB buffer", yet it gets sent in pieces (cipher blocks?), which can lead to some interesting issues (my server was for video streaming, and sending an incomplete frame resulted in artifacts). I solved some of this by enabling SSL_MODE_ENABLE_PARTIAL_WRITE (don't block until everything is sent, just tell me what succeeded).

What I'm trying to say is that not enabling SSL because its code is a mess is an example of "the enemy of good is perfect". While Varnish refuses to add SSL support, nginx has it. That's why I use nginx and not Varnish.

Re: SSL revisited

#29

Earlier quoted context omitted.

Jails can still use MITM monitoring proxies without disabling SSL: they just have to install certs on the machine.

Does it work with sites like Google from Google Chrome where browser knows about their public keys? I think that this will be wide practice in modern browsers. HSTS/HPKP headers could be stripped by proxy but preloaded public key list probably will require custom browser build.

Yes, it does. Google intentionally adds exceptions from error reporting in the case a root CA was added to the OS.

Re: SSL revisited

#30
post #25
post #3

Without discussing any of the political points (which felt out of place), this simply means that we will continue to not use Varnish. Nginx' caching is good enough that it's not worth the pain of trying to implement some wacky setup just to use Varnish.

If you don't need varnish, it would be pretty stupid to start running it...

Varnish has a few bonus features (like caching the gzipped version of responses), which could still make it a useful addition.

We've settled on Nginx for a few of our use cases (to good reception), but there are other use cases we're still evaluating.

Post reply on HN