Live data from Hacker News

Nginx doesn't suck at SSL after all

matt.io

61–70 of 112 posts

Re: Nginx doesn't suck at SSL after all

#61
post #57

An article about configuring SSL that doesn't 1) discuss trade-offs of security vs. resource consumption, 2) how to figure out your performance requirements, and 3) indicate the author really understands implications of decisions about crypto is an article you should probably disregard. Modern CPUs are so ridiculously good at crypto, and most sites have such ridiculously low connection rates, that optimizing for maxi…

Does any of this have anything to do with Matt's post? Adam's first post says the same thing Matt's does: DHE is expensive. The "tradeoff" in security vs. performance you're referring to irrelevant to almost everyone building on nginx. If you've lost your RSA key, you are well and truly fucked. DHE is interesting, but sniping at people for not using it (in your case, implicitly) is unfair.

On a related topic, these are both your comments on this post:

"The win here is that losing the RSA key now only allows you to MITM future SSL/TLS connections. This is still a disaster, but it does not allow you to retroactively unwind previous DH exchanges and decrypt earlier captured sessions."

"If you've lost your RSA key, you are well and truly fucked."

Thanks for clearing that up!

Make love not war,

Lil' B

Re: Nginx doesn't suck at SSL after all

#62
post #57

Earlier quoted context omitted.

Does any of this have anything to do with Matt's post? Adam's first post says the same thing Matt's does: DHE is expensive. The "tradeoff" in security vs. performance you're referring to irrelevant to almost everyone building on nginx. If you've lost your RSA key, you are well and truly fucked. DHE is interesting, but sniping at people for not using it (in your case, implicitly) is unfair.

Adam's post is rather more thorough and nuanced, which makes sense since he actually understands SSL and benchmarking. While you might summarize them both as "DHE is expensive", I don't know why you would. Here is each post on DHE: Adam - "However, with a pure RSA ciphersuite, an attacker can record traffic, crack (or steal) your private key at will and decrypt the traffic retrospectively, so consider your needs." Ma…

Are you a little worried that you come off sounding like "Adam is one of the cool kids and Matt isn't"? Matt's conclusion is ultimately correct.

And we apparently disagree completely about DHE, because you appear to be saying you'd recommend it to web startups, despite the fact that the bank that clears those startups transactions isn't even using it.

Especially weird given that Boundary, your startup, doesn't do DHE.

Re: Nginx doesn't suck at SSL after all

#63
post #57

Earlier quoted context omitted.

Does any of this have anything to do with Matt's post? Adam's first post says the same thing Matt's does: DHE is expensive. The "tradeoff" in security vs. performance you're referring to irrelevant to almost everyone building on nginx. If you've lost your RSA key, you are well and truly fucked. DHE is interesting, but sniping at people for not using it (in your case, implicitly) is unfair.

On a related topic, these are both your comments on this post: "The win here is that losing the RSA key now only allows you to MITM future SSL/TLS connections. This is still a disaster, but it does not allow you to retroactively unwind previous DH exchanges and decrypt earlier captured sessions." "If you've lost your RSA key, you are well and truly fucked." Thanks for clearing that up! Make love not war, Lil' B

Oh. You're forum trolling. You know what though, it's always great to see you Ben. Thanks for taking the time.

Re: Nginx doesn't suck at SSL after all

#64
post #53
post #49

Earlier quoted context omitted.

If the institution chooses an insecure password policy, it heightens the likelihood it will fail to ensure good SSL settings. This tendency is independent of the fact that these functionalities are implemented by different teams, and that one team might happen to be competent enough to do the right thing despite the lack of institutional imperative. So the consumer might get lucky. So what? Your initial comment was t…

You use this word "the institution" as if companies were hive minds. Read the other comments on this thread. Again: the people who make decisions about password complexity are almost never the security people.

Exactly. You shouldn't trust a particular technique just because a financial institution uses it. They have very little institutional culture around security, as you yourself point out. So I'm not sure why you brought up the fact that financial institutions use a particular SSL technique - that tells us nothing.

Re: Nginx doesn't suck at SSL after all

#65
post #64
post #53

Earlier quoted context omitted.

You use this word "the institution" as if companies were hive minds. Read the other comments on this thread. Again: the people who make decisions about password complexity are almost never the security people.

Exactly. You shouldn't trust a particular technique just because a financial institution uses it. They have very little institutional culture around security, as you yourself point out. So I'm not sure why you brought up the fact that financial institutions use a particular SSL technique - that tells us nothing.

Your argument is exasperating, because I already addressed this notion that password complexity requirements in banking apps have anything to do with what financial security people think are best practices for SSL/TLS.

Re: Nginx doesn't suck at SSL after all

#66
So, are these the new numbers? I copied the numbers from the original and the new post:

  haproxy direct: 6,000 requests per second
  stunnel -> haproxy: 430 requests per second
  (OLD) nginx (ssl) -> haproxy: 90 requests per second
  nginx (AES256-SHA) -> haproxy: 1300 requests per second
  nginx (AES256-SHA with keepalive 5 5;) -> haproxy: 4300 requests per second
Did other things change or is nginx more than twice as fast as the next best solution?

Re: Nginx doesn't suck at SSL after all

#67
post #65
post #64

Earlier quoted context omitted.

Exactly. You shouldn't trust a particular technique just because a financial institution uses it. They have very little institutional culture around security, as you yourself point out. So I'm not sure why you brought up the fact that financial institutions use a particular SSL technique - that tells us nothing.

Your argument is exasperating, because I already addressed this notion that password complexity requirements in banking apps have anything to do with what financial security people think are best practices for SSL/TLS.

I still have no idea why you keep bringing up the finance industry - it brings no credibility to this discussion or your points, which seem reasonable enough. Even the "security people" taken collectively have no keen track record so why are we talking about them collectively, again? No big deal, I just don't get it. Shrug.

Re: Nginx doesn't suck at SSL after all

#68

From the article, to find out what your website is doing: openssl s_client -host HOSTNAME -port 443 I ran this for my own website and a few bigger websites openssl s_client -host www.gusta.com -port 443 (My site, hosted on Heroku) Cipher : DHE-RSA-AES256-SHA openssl s_client -host www.google.com -port 443 Cipher : RC4-SHA openssl s_client -host www.airbnb.com -port 443 Cipher : AES256-SHA openssl s_client -host www.f…

Presumably Amazon, Facebook and Google are using RC4 for speed reasons, though it's not really thought to be secure anymore.

Re: Nginx doesn't suck at SSL after all

#69
post #7
post #4

I can't tell if this is an apology or a non-apology. It seems to have elements of both. Clearly the moral of the story is: "Don't claim that X sucks unless you are are damn sure". Saying something sucks is fightin' words. Don't expect to people be nice if you are wrong.

Why would someone apologize for writing an informative blog post? I'm glad he wrote both, even if he had to walk the first one back a bit.

I found both posts informative, and yet I'm with cbetz on this one. The issue isn't whether Matt's first post was informative but is instead whether it was fair|wise|necessary to say "Nginx sucks at SSL" instead of, say, "My initial testing, which needs to be investigated further, is showing Nginx SSL performance lower than other alternatives." The first headline is more likely to grab folks' attention, which is probably why Matt chose that headline. It is probably that choice that cbetz finds objectionable, and if so, I agree with him.

Re: Nginx doesn't suck at SSL after all

#70
post #4

I can't tell if this is an apology or a non-apology. It seems to have elements of both. Clearly the moral of the story is: "Don't claim that X sucks unless you are are damn sure". Saying something sucks is fightin' words. Don't expect to people be nice if you are wrong.

  > Clearly the moral of the story is: "Don't claim that
  > X sucks unless you are are damn sure".
More like: "If you say something that upsets people, they will spend a lot of time and effort to display their ignorance in an effort to prove you wrong -- as if you had insulted their very being -- even though you just made and honest mistake." I read the original article, and I didn't see it as an attack on Nginx, or Nginx's SSL support. He ran some benchmarks and said, "Wow, those numbers suck."

  > Don't expect to people be nice if you are wrong.
I read the HN comments here and on the original post, and I don't remember anyone saying anything about cyphers. The people that were 'not nice' were also wrong. Would that excuse the author of the post, from turning around and being 'not nice' to those people because they are wrong?
Post reply on HN