Live data from Hacker News

SSL revisited

varnish-cache.org

41–50 of 69 posts

Re: SSL revisited

#41
post #33

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…

I'm kind of surprised about this repeated "I just use nginx" argument, it doesn't make sense to me at all. 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, beca…

I for one appreciate the approach taken - the constant drive for all-consuming "one size fits all" tools is ridiculous.

Any eta on v4.1 with PROXY support? I didn't find much when looking quickly (and from a phone)

Re: SSL revisited

#43
post #38
post #36

Earlier quoted context omitted.

Local CAs are allowed to override even cert-pinning for this reason.

Right, so when you're guest at a company you have to install their CERT on your device to use their guest-wlan ? If you're an employee you have to put the company CERT on your smartphone ? How does that improve your security ?

Guests shouldn't be on the corporate network anyway. Either companies will provide a guest WiFi signal that is physically separate from the corporate network (that's what my employer does), or they will ask guests to provide their own connectivity via LTE.

Re: SSL revisited

#44
post #37

Earlier quoted context omitted.

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 agree with what you said about picking the right tool for the job, but I don't see how he's "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 tl…

I'm all for reducing complexity but ignoring the bigger problem so you can focus on a smaller one isn't necessarily the path.

Customers are trying to solve a pretty basic, common problem here. I don't see how a ranty, opinionated position paper moves anyone closer to the finish line.

All it did was further influence my opinion of where Varnish would likely be in five years. While I appreciate the candor I'm not sure he did himself any favors.

Re: SSL revisited

#45
post #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…

How is TLS Termination/load balancing > caching proxy > Apache/nginx/whatever "something wrong with your architecture"?

Obviously depends on the "apache/nginx/whatever" side, especially if "nginx" can do everything varnish does in your scenario and moreso when "whatever" includes in-app caching and load balancing strategies.

Varnish grew legs as part of saving the clusterfuck that is WordPress. Custom cache rules up a layer from a broken old code base is AWESOME. Maybe also a red flag.

Re: SSL revisited

#46
This article is written as if "Should we use HTTPS?" was still an open question. That boat has sailed.

If you can't allow SSL on your network, you can't allow use of Google and about 2000 sites which browsers will not even try opening via HTTP:

https://code.google.com/p/chromium/codesearch#chromium/src/n...

Jail libraries and magic-cookie-hunting hackers have an option of installing their own CA certificate. This is supported by all browsers. It's not hard, even Lenovo malware can do it.

Re: SSL revisited

#47
post #44

Earlier quoted context omitted.

I agree with what you said about picking the right tool for the job, but I don't see how he's "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 tl…

I'm all for reducing complexity but ignoring the bigger problem so you can focus on a smaller one isn't necessarily the path. Customers are trying to solve a pretty basic, common problem here. I don't see how a ranty, opinionated position paper moves anyone closer to the finish line. All it did was further influence my opinion of where Varnish would likely be in five years. While I appreciate the candor I'm not sure…

I have a really hard time following your argumentation, because it seems to have very little to do with both reality and what I wrote.

What I did WRT moving people closer to the finish line was to implement the PROXY protocol, so that using a(ny) preexisting and well-tested SSL-termination solution works seamlessly with Varnish.

IMO, that is a far superior solution to adding a lot of security critical code to Varnish which, at the end of that huge effort, doesn't work any better.

As I wrote in my piece: "the world really don't need another piece of code that does an half-assed job at cryptography"

And doing a full-assed job only makes sense if you have the resources, competence (important with crypto!) and the result makes a positive contribution, one way or another, which offsets the cost of its production.

Nobody has yet been able to point out what the positive contribution would be, compared to a solution where SSL termination is its own layer.

Do you know something about that which I don't ?

If so, please share...

Re: SSL revisited

#48
post #46

This article is written as if "Should we use HTTPS?" was still an open question. That boat has sailed. If you can't allow SSL on your network, you can't allow use of Google and about 2000 sites which browsers will not even try opening via HTTP: https://code.google.com/p/chromium/codesearch#chromium/src/n... Jail libraries and magic-cookie-hunting hackers have an option of installing their own CA certificate. This is…

"Should we use HTTPS" is very much a closed question, and for a lot of sites the answer is a resounding "NO".

The fact that you might not use those sites doesn't mean that we who deliver tools for them can just ignore them, or even worse, impose our political agenda on them.

You can do HTTPS with Varnish if you want to, but you'll have to do it with the architecturally and security-wise most sensible configuration: With a SSL terminating proxy in front of Varnish.

And again: Talk to your legislators about peoples right to privacy, I'm just pointing out that such laws exist, I'm not writing them (or for that matter agreeing with them.)

Re: SSL revisited

#49

The case against the trendy push for "HTTPS always, no exceptions" is largely a set of corner cases everyone else is comfortable to ignore, so I'm glad someone is making it.

I have yet to see an opponent of https everywhere address the fact that https provides important authentication. Isn't it important that when you go to your governments emergency status page you see what they published rather than the emergency rick roll that my arp spoofing laptop served you? Are you okay with Comcast injecting ads and verizon adding supercookies to your sessions?

The none cypher provided this without encryption, but it's long been deprecated.

Re: SSL revisited

#50
post #48
post #46

This article is written as if "Should we use HTTPS?" was still an open question. That boat has sailed. If you can't allow SSL on your network, you can't allow use of Google and about 2000 sites which browsers will not even try opening via HTTP: https://code.google.com/p/chromium/codesearch#chromium/src/n... Jail libraries and magic-cookie-hunting hackers have an option of installing their own CA certificate. This is…

"Should we use HTTPS" is very much a closed question, and for a lot of sites the answer is a resounding "NO". The fact that you might not use those sites doesn't mean that we who deliver tools for them can just ignore them, or even worse, impose our political agenda on them. You can do HTTPS with Varnish if you want to, but you'll have to do it with the architecturally and security-wise most sensible configuration: W…

In places like jails, schools, and libraries (where the owner can add a compromised CA cert and users don't have permissions to remove it) it's entirely possible to MITM and decrypt all TLS traffic, so I don't get why you're still arguing as if that wasn't the case.

While the long tail of sites isn't on HTTPS yet, the most popular ones are HTTPS-only already, and the result is that in Chrome HTTPS sites are browsed more often than HTTP sites:

https://plus.google.com/+IlyaGrigorik/posts/7VSuQ66qA3C

Post reply on HN