Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

SSL revisited

varnish-cache.org

Post reply on HN
Print view View original

11–20 of 69 posts

Re: SSL revisited

#11

Post by bryanlarsen »

Loic wrote: post #8
falcolas wrote: post #5

Earlier quoted context omitted.

If a federal site can survive being DDOSed, it can probably survive normal traffic. 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.

Some people do not have the rights to online privacy. For example, when accessing a website from the library of a jail. The authorities want and need to know what you do, this for some obvious and understandable reasons. I agree this is a particular case, but this is still a case for allowing a website (as long as this is anonymous usage of it) to be available without SSL.

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

Re: SSL revisited

#12

Post by falcolas »

eosrei wrote: post #9
falcolas wrote: 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.

It's straightforward to run Pound or HAProxy in front of Varnish to provide SSL-terminatation. I wouldn't consider it a wacky setup. The performance gains over Nginx for static/anonymous caching is significant.

It adds two more layers of software to configure, monitor and maintain, and my own tests disagree on the performance gains for a fairly typical Wordpress install.

The response times were virtually identical, and the load on the box was significantly lower with Nginx over varnish, so the simplicity was the deciding factor.

Re: SSL revisited

#13

Post by joshstrange »

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 in literally any form. More and more computers and what we store on them are an extension of our minds. By this logic you are more or less reading my thoughts by knowing what I doing online (I could write a whole paper on this).

That said kudos to the author of varnish for actually coming out and explaining why he feels this way. Too often there is no insight into why something was done a certain why (or why it wasn't done at all) and anything that sheds light on that is a good in my book. I understand and agree with where he is coming from in relation to it adding attack surface, complicating the code, and tying him up from working on other things. Those are all legit reasons coupled with the fact that this you can just use something like HAProxy or Pound in front of varnish.

For me nginx caching is good enough for my personal use and at work we are not to the point that using varnish would provide big enough gains to offset the time to implement it (we are SSL-only). That said I will continue to keep my eye on varnish because I have used it before and quite liked it.

Re: SSL revisited

#14

Post by johannes1234321 »

lunixbochs wrote: post #2

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…

Even for read-only encryption is important for privacy. An observer can conclude your interests from what you read and can manipulate the contents.

Re: SSL revisited

#15

Post by smutticus »

floatboth wrote: post #10
profmonocle wrote: post #7

> 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.

It really depends on what your bottleneck is. If your bottle neck is already CPU, then TLS is not that big of a deal. If, OTOH, your bottleneck is disk, then implementing TLS can create substantial overhead.

Re: SSL revisited

#16

Post by vbezhenar »

bryanlarsen wrote: post #11
Loic wrote: post #8

Earlier quoted context omitted.

Some people do not have the rights to online privacy. For example, when accessing a website from the library of a jail. The authorities want and need to know what you do, this for some obvious and understandable reasons. I agree this is a particular case, but this is still a case for allowing a website (as long as this is anonymous usage of it) to be available without SSL.

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

#17

Post by marcosdumay »

smutticus wrote: post #15
floatboth wrote: post #10

Earlier quoted context omitted.

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.

It really depends on what your bottleneck is. If your bottle neck is already CPU, then TLS is not that big of a deal. If, OTOH, your bottleneck is disk, then implementing TLS can create substantial overhead.

What?

How does TLS increase disk usage?

Re: SSL revisited

#18

Post by dijit »

smutticus wrote: post #15
floatboth wrote: post #10

Earlier quoted context omitted.

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.

It really depends on what your bottleneck is. If your bottle neck is already CPU, then TLS is not that big of a deal. If, OTOH, your bottleneck is disk, then implementing TLS can create substantial overhead.

there's more to it than that I guess.

TLS adds quite a bit of memory overhead, it increases the network bandwidth due to padding, and if your CPU is eqipped with AES extensions (modern ones) then you still do compression usually.

it can be difficult to cache certain things with TLS also- since you can't do transparent caching. (although this is more a problem for those running squid proxies at work on a stretched out line).

TLS is certainly an overhead and it's not required in cases where I'm checking a bulletin about earthquakes.

Re: SSL revisited

#19

Post by nine_k »

smutticus wrote: post #15
floatboth wrote: post #10

Earlier quoted context omitted.

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.

It really depends on what your bottleneck is. If your bottle neck is already CPU, then TLS is not that big of a deal. If, OTOH, your bottleneck is disk, then implementing TLS can create substantial overhead.

How so? If your bottleneck is disk, you probably have quite some CPU cycles to spare, because the CPU is waiting for I/O most of the time.

Re: SSL revisited

#20

Post by nine_k »

lunixbochs wrote: post #2

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…

Any security measure either works for everyone, or for no one. There's no way to give good privacy to "good" people and easily compromise it for "bad" people, for any definition of "good" and "bad".

If "bad" people outnumber "good" people in your world view, then yes, it's entirely reasonable to deny everyone privacy.

What are the institutions that are hell-bent on listening to everyone's traffic? China government? OK, serve them non-sensitive content via plain HTTP; they'll filter or alter it to their liking. Possibly you're fine with this. NSA? Well, maybe something can and should be done to it that we can't do to the China government?

(Not to self: when planning a deployment, consider other options before turning to Varnish cache.)

Post reply on HN