Live data from Hacker News

SSL revisited

varnish-cache.org

51–60 of 69 posts

Re: SSL revisited

#51
post #47
post #44

Earlier quoted context omitted.

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…

You did a little work, avoided doing a lot more work, and justified it with "more components = better." Fine. Not the only approach but certainly not a radical one either.

You could have stopped there. My feeling is that you should have.

But the rant part of your post? Evoking HeartBleed and "I told you so" and Snowden and digs on BSD and "big transnational, and therefore law-less, companies." Well, that makes you look a little wacky.

By doing this you attracted unnecessary attention to yourself (perhaps the point) but also generated no positive goodwill for the product. Worse, it made me question the motivations behind the technology decision.

It's not a good tech post and it's not a good marketing post.

As I stated, there are people who do this sort of thing well. Your post is an example of not doing it well.

Re: SSL revisited

#52
post #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 witho…

HTTPS doesn't provide authentication. It only communicates authentication, and that is from the untrustworthy and widely trojned CA-concept, which is as broken as it almost can be.

There are other, far better authentication methods for things like emergency services, and I'd rather have unauthenticated information, than no information at all anyway.

You also don't need authentication to stop ISP's being stupid, for that Integrity is all you need.

Re: SSL revisited

#53
post #51
post #47

Earlier quoted context omitted.

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…

You did a little work, avoided doing a lot more work, and justified it with "more components = better." Fine. Not the only approach but certainly not a radical one either. You could have stopped there. My feeling is that you should have. But the rant part of your post? Evoking HeartBleed and "I told you so" and Snowden and digs on BSD and "big transnational, and therefore law-less, companies." Well, that makes you lo…

So we have established that your factual knowledge of varnish is severely lacking (and/or skewed) and now you just demonstrated that you have no idea who you are lambasting either.

Let me know if you ever want to have a fact-based discussion, in the meantime, don't get cold up there, on your high horse.

I gave a talk called "NSA Operation Orchestra" some time ago, I recommend you watch it, it might give you something to think about.

Re: SSL revisited

#54
post #51
post #47

Earlier quoted context omitted.

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…

You did a little work, avoided doing a lot more work, and justified it with "more components = better." Fine. Not the only approach but certainly not a radical one either. You could have stopped there. My feeling is that you should have. But the rant part of your post? Evoking HeartBleed and "I told you so" and Snowden and digs on BSD and "big transnational, and therefore law-less, companies." Well, that makes you lo…

> You did a little work, avoided doing a lot more work, and justified it with "more components = better." Fine. Not the only approach but certainly not a radical one either.

Your interpretation of this is ridiculous.

You may as well dismiss Linux because the kernel doesn't include an ANSI SQL compliant database and runtime environment for perl, ruby, python and php.

There is immense value in having several small, specialised tools that can be used together to form a solution.

Re: SSL revisited

#55
post #53
post #51

Earlier quoted context omitted.

You did a little work, avoided doing a lot more work, and justified it with "more components = better." Fine. Not the only approach but certainly not a radical one either. You could have stopped there. My feeling is that you should have. But the rant part of your post? Evoking HeartBleed and "I told you so" and Snowden and digs on BSD and "big transnational, and therefore law-less, companies." Well, that makes you lo…

So we have established that your factual knowledge of varnish is severely lacking (and/or skewed) and now you just demonstrated that you have no idea who you are lambasting either. Let me know if you ever want to have a fact-based discussion, in the meantime, don't get cold up there, on your high horse. I gave a talk called "NSA Operation Orchestra" some time ago, I recommend you watch it, it might give you something…

See, that's just the thing. I tuned Varnish for 32 bit machines (a terrible idea), I sent in patches. I love everything about OpenBSD. I think the NSA are a bunch of cocksuckers. And I also think that when you combine all those things in a post talking about a feature decision it makes you look like a lunatic. Talk to Percival, he gets it. And thank you for the work on Varnish, it seriously saved several sites.

Re: SSL revisited

#56
post #52
post #49

Earlier quoted context omitted.

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 witho…

HTTPS doesn't provide authentication. It only communicates authentication, and that is from the untrustworthy and widely trojned CA-concept, which is as broken as it almost can be. There are other, far better authentication methods for things like emergency services, and I'd rather have unauthenticated information, than no information at all anyway. You also don't need authentication to stop ISP's being stupid, for t…

As bad as the CA system is, I have not seen evidence that it's 'widely trojaned' or broken. The fact that a falsely minted certificate is such big news is evidence to the fact that it is working pretty well despite it's flaws. And it is certainly better than no authentication at all.

Obviously it's not perfect, but being not perfect is no excuse for refusing to use what we've got right now. And it's not a choice of unauthenticated information or no information, it's a choice between authenticated information and possibly wrong information.

Trusting ISPs to have integrity is in my opinion much more absurd than trusting CA's. CA's have a financial motivation to keep their CA status which browsers can revoke. ISPs have nobody keeping them in line.

Re: SSL revisited

#57
post #51

Earlier quoted context omitted.

You did a little work, avoided doing a lot more work, and justified it with "more components = better." Fine. Not the only approach but certainly not a radical one either. You could have stopped there. My feeling is that you should have. But the rant part of your post? Evoking HeartBleed and "I told you so" and Snowden and digs on BSD and "big transnational, and therefore law-less, companies." Well, that makes you lo…

> You did a little work, avoided doing a lot more work, and justified it with "more components = better." Fine. Not the only approach but certainly not a radical one either. Your interpretation of this is ridiculous. You may as well dismiss Linux because the kernel doesn't include an ANSI SQL compliant database and runtime environment for perl, ruby, python and php. There is immense value in having several small, spe…

Likewise there is immense value in having a simpler solution with fewer parts -- when appropriate and when possible. This is part of what we decide as engineers.

It's also easier to sell someone on your component strategy when you don't trash every possible piece that could plug in to the hole you've left -- from operating systems and open source crypto packages to government agencies and transnational corporations. But that little observation seems to be getting lost in the noise here.

Re: SSL revisited

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

What does that mean then?

> But one of the biggest problem I have with SSL Everywhere is that it gives privacy to the actors I think deserve it the least.

Some deserve privacy more than others? How does that work?

Re: SSL revisited

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

On the other hand, I don't want China to bog down some contry's civil defence (or any other website) by DDOSing it, injecting JS into unencrypted baidu traffic. Which one is causing more problems right now?

Re: SSL revisited

#60
post #23

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.

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 th…

> Are you willing to pay increased taxes, so [...] that they can get emergency orders out for civil defence ?

Unquestionably, yes.

Post reply on HN