Live data from Hacker News

Nginx doesn't suck at SSL after all

matt.io

21–30 of 112 posts

Re: Nginx doesn't suck at SSL after all

#21
post #10

Earlier quoted context omitted.

It's not the "best/most secure". All the other servers can trivially enable EDH as well; it's OpenSSL that implements it, not nginx. Reasonable people can disagree on what the right default is, but plenty of financial institutions have made the studied choice not to enable it.

> All the other servers can trivially enable EDH as well Unless I'm reading OP wrong, that's not the case for the servers he uses for his tests: Stud can't enable it at all: > stud doesn't have at all. and in stunnel you have to compile it in for support, it's not just "not enabled by default", it's not compiled in: > stunnel has it as a compile time/certificate configurable option.

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

Re: Nginx doesn't suck at SSL after all

#22
post #15
post #12

Earlier quoted context omitted.

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.

Are you sure the problem is entropy generation and not just extra bignum math? Also: there are plenty of major financial apps that are not allowed to use DHE, because DHE makes it impossible for the provider to monitor its own connections ("conventional" SSL/TLS allows for middleboxes that monitor and archive sessions by holding a copy of the server's RSA key).

What is best for security in regulated fields and what is mandated or forbidden for security in regulated fields are often almost disjoint sets.

Anyway, whether your phone has trouble coming up with the entropy, or preforming the math, you should probably be using something more substantial.

Re: Nginx doesn't suck at SSL after all

#23
post #15

Earlier quoted context omitted.

Are you sure the problem is entropy generation and not just extra bignum math? Also: there are plenty of major financial apps that are not allowed to use DHE, because DHE makes it impossible for the provider to monitor its own connections ("conventional" SSL/TLS allows for middleboxes that monitor and archive sessions by holding a copy of the server's RSA key).

What is best for security in regulated fields and what is mandated or forbidden for security in regulated fields are often almost disjoint sets. Anyway, whether your phone has trouble coming up with the entropy, or preforming the math, you should probably be using something more substantial.

You're suggesting that people should pick a different phone so they can get PFS with the small fraction of SSL servers that support it?

Re: Nginx doesn't suck at SSL after all

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

Of course, in a perfect world, developers would be paid to think about security.

Re: Nginx doesn't suck at SSL after all

#26
post #21

Earlier quoted context omitted.

> All the other servers can trivially enable EDH as well Unless I'm reading OP wrong, that's not the case for the servers he uses for his tests: Stud can't enable it at all: > stud doesn't have at all. and in stunnel you have to compile it in for support, it's not just "not enabled by default", it's not compiled in: > stunnel has it as a compile time/certificate configurable option.

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 :)

Re: Nginx doesn't suck at SSL after all

#27
Ah, if only we had an occasional second upvote! This is far more useful than the original post, which was already well above average. If you are deploying nginx with SSL, you need to know about the configuration details in the article.

Re: Nginx doesn't suck at SSL after all

#28
post #23

Earlier quoted context omitted.

What is best for security in regulated fields and what is mandated or forbidden for security in regulated fields are often almost disjoint sets. Anyway, whether your phone has trouble coming up with the entropy, or preforming the math, you should probably be using something more substantial.

You're suggesting that people should pick a different phone so they can get PFS with the small fraction of SSL servers that support it?

I'm suggesting that if for some reason a site thinks that that sort of security is necessary, they shouldn't change their mind for the sake of people using their telephones.

Particularly since at the current rate of development, the average phone will be able to do it just fine in a few months.

Re: Nginx doesn't suck at SSL after all

#29
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 :)

Fair warning: this comment is apparently all kinds of wrong, but I leave it here for posterity.

Put:

  if(getenv("SSL_CIPHER_SUITES"))
    SSL_CTX_set_cipher_list(ctx, getenv("SSL_CIPHER_SUITES"));
anywhere after SSL_CTX_new().

But don't bother doing it with stud, because (as I sort of predicted) stud already does this: stud -c .

I don't understand what Matt is saying by "stud doesn't enable DH at all". Does stud build its own OpenSSL? The system OpenSSL will already support DHE.

Post reply on HN