Live data from Hacker News

Nginx doesn't suck at SSL after all

matt.io

31–40 of 112 posts

Re: Nginx doesn't suck at SSL after all

#31
Unlike the above post, this fellow actually did some broad cipher testing (http://zombe.es/post/4078724716/openssl-cipher-selection), particularly around AESNI instructions in recent Intel chips.

With AESNI, use AES-128, AES-256, RC4-SHA, CAMELLIA-128. Without AESNI, use RC4-SHA, AES-128, AES-256, CAMELLIA-128.

In nginx, this looks like:

  # (wo/AESNI): ssl_ciphers RC4:AES128-SHA:AES:CAMELLIA128-SHA:!MD5:!ADH:!DH:!ECDH:!PSK:!SSLv2
  # (w/AESNI):  ssl_ciphers AES128-SHA:AES:RC4:CAMELLIA128-SHA:!MD5:!ADH:!DH:!ECDH:!PSK:!SSLv2
You eliminate weak ciphers. You retain RC4 for compatibility and speed. You order by performance. (Note that AES-128 is still ranked as secure through 2030 [at least]. You don't need to prefer AES-256.)

Re: Nginx doesn't suck at SSL after all

#32

"Final feeling: Twitter is better than HN in all social dimensions of engagement, kindness, and authenticity." Ouch.

Yeah, well, arrogantly complaining about people calling you out on unfounded speculation doesn't really work when you were originally quite arrogant in that speculation.

Re: Nginx doesn't suck at SSL after all

#33
post #21

Earlier quoted context omitted.

nginx is a web server, like Apache. stud is a few hundred lines of trivial proxy code. And would you like to take a bet on how many lines of C code it would take to add support for configurable cipher suite modes in stud? Fair warning: I already know the answer to this (and I don't even know that stud doesn't allow it).

Do you happen to have a patch? I might be interested in that :)

That's the trick -- you can enable your DHE cipher all day long, but if the code doesn't set up DHparams, it will never work.

Here's a quick (no error checking) way to set up DHparams if they are appended to a cert:

    BIO *bio = BIO_new_file(path_to_a_file_with_dhparams, "r");
    DH *dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL);
    BIO_free(bio);
    SSL_CTX_set_tmp_dh(ctx, dh);
    DH_free(dh);
Where do the DH parameters come from? You can generate it yourself (1024 bits here):

    openssl dhparam -rand - 1024
For a completely isolated implementation (requiring no user certificate changes), see function ngx_ssl_dhparam in nginx-1.0.4/src/event/ngx_event_openssl.c

Re: Nginx doesn't suck at SSL after all

#34
post #33

Earlier quoted context omitted.

Do you happen to have a patch? I might be interested in that :)

That's the trick -- you can enable your DHE cipher all day long, but if the code doesn't set up DHparams, it will never work. Here's a quick (no error checking) way to set up DHparams if they are appended to a cert: BIO *bio = BIO_new_file(path_to_a_file_with_dhparams, "r"); DH *dh = PEM_read_bio_DHparams(bio, NULL, NULL, NULL); BIO_free(bio); SSL_CTX_set_tmp_dh(ctx, dh); DH_free(dh); Where do the DH parameters come…

Doh! 'seiji wins. I was way too glib about DHE. Sorry.

Re: Nginx doesn't suck at SSL after all

#35
post #20

Earlier quoted context omitted.

Plenty of financial institutions have also made the studied choice to limit the length and types of characters I can use in my password.

No. I recognize this as snark, but it's inaccurate snark. Banks limit password lengths because the programmers who implement their apps are dumb. But programmers don't choose the SSL configurations for their app servers and load balancers; people who are paid to think about security do. Your attempt at snark here relies on an apples-oranges comparison.

I'm not calling you wrong (I readily admit my knowledge on this topic doesn't even compare to yours), but are you really saying that these banks hire security experts to set requirements for SSL configurations on their load balancers and then don't use these security experts to set requirements for password security? That seems borderline malicious on their part.

Re: Nginx doesn't suck at SSL after all

#36
post #12

I ran this against the slowest SSL website I know of. This site absolutely kills my phone web browser and I've been wondering about this problem for years. The site: manager.skype.com. The result? DHE-RSA-AES256-SHA. No wonder! Fix this guys! In regards to this post, if this is the default configuration of Nginx then I agree that Nginx sucks. This is not a good default configuration for the Internet.

There's nothing wrong with using DHE algorithms, particularly if you're going to be transferring financial secrets around. If your phone can't keep up, well, then it probably should have a better entropy generator.

It maxes has been maxing out my laptop CPU for an inordinate amount of time for years as well. These "financial secrets" are emailed in the clear after every transaction, so your point is moot.

Burgerbrain: PayPal.com, CitiCards.com, 2checkout.com, and many payment processors all use RC4-SHA or AES256-SHA. You are wrong.

Re: Nginx doesn't suck at SSL after all

#37

"Final feeling: Twitter is better than HN in all social dimensions of engagement, kindness, and authenticity." Ouch.

This is interesting to me. Maybe it's because twitter places much more emphasis on identity than HN comments? Twitter users are also more likely to be using that service to market their personal brand, rather than just to share whatever they're thinking, so are probably much more careful about what they say.

Re: Nginx doesn't suck at SSL after all

#40
post #35
post #20

Earlier quoted context omitted.

No. I recognize this as snark, but it's inaccurate snark. Banks limit password lengths because the programmers who implement their apps are dumb. But programmers don't choose the SSL configurations for their app servers and load balancers; people who are paid to think about security do. Your attempt at snark here relies on an apples-oranges comparison.

I'm not calling you wrong (I readily admit my knowledge on this topic doesn't even compare to yours), but are you really saying that these banks hire security experts to set requirements for SSL configurations on their load balancers and then don't use these security experts to set requirements for password security? That seems borderline malicious on their part.

The security team at a bank is lucky if they even have a list of all the applications in use across the enterprise. There are bound to be hundreds. When those apps have ridiculous password policies, it's not because a developer simply decided "this is the right kind of password policy for our app", so that a security person could just say "uh, no". No, the restrictions are set up that way because the app is build badly. Can you guess how much it costs to revise password storage and UX for tens or hundreds of applications?
Post reply on HN