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.
SSL revisited
21–30 of 69 posts
Re: SSL revisited
#22UPDATE/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…
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.
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
#24But 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
#25Without 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.
Re: SSL revisited
#26I'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)
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
#27UPDATE/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.
> 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
#28The "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
#29Earlier 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.
Re: SSL revisited
#30Without 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...
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.