5 ms·

So Nginx got unwarranted hate for having the most secure defaults. That sucks. I hope the user nginxorg -- whom I assume is Igor Sysoev -- who dropped by the pr

So Nginx got unwarranted hate for having the most secure defaults. That sucks. I hope the user nginxorg -- whom I assume is Igor Sysoev -- who dropped by the previous thread (http://news.ycombinator.com/item?id=2752136 http://news.ycombinator.com/item?id=2752136), sees this post too. Either way -- based on his attitude in the first post, I'm really surprised by how Matt owned up and did his homework for this one. (He should have done it from the beginning, of course, but none of the people bashing him in the previous thread actually provided anything to support what they were saying.)

tptacek 15y ago
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.
- thirsteh 15y ago
  Fair point. Clarifying...
- schleyfox 15y ago
  Plenty of financial institutions have also made the studied choice to limit the length and types of characters I can use in my password.
  - tptacek 15y ago
    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.
    - mapgrep 15y ago
      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 that "plenty of financial institutions" do SSL a certain way, and the respondent correctly pointed out that this fact adds no information to the discussion about SSL techniques, because plenty of financial institutions do dumb things. It's "apples and oranges" only insofar as he's saying the orchard manager is a poison spreading dummy so you can't trust the apples or the oranges. Maybe you can elaborate on the "studied" part of your comment with specifics. That part was interesting.
      - tptacek 15y ago
        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.
        mapgrep 15y ago
        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.
        tptacek 15y ago
        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.
        15y ago
- masklinn 15y ago
  > 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.
  - tptacek 15y ago
    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).
    - burgerbrain 15y ago
      Do you happen to have a patch? I might be interested in that :)
      - tptacek 15y ago
        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 <ciphersuites>. 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.
      - seiji 15y ago
        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

tptacek 15y ago

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.

thirsteh 15y ago
Fair point. Clarifying...
schleyfox 15y ago
Plenty of financial institutions have also made the studied choice to limit the length and types of characters I can use in my password.
- tptacek 15y ago
  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.
  - mapgrep 15y ago
    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 that "plenty of financial institutions" do SSL a certain way, and the respondent correctly pointed out that this fact adds no information to the discussion about SSL techniques, because plenty of financial institutions do dumb things. It's "apples and oranges" only insofar as he's saying the orchard manager is a poison spreading dummy so you can't trust the apples or the oranges. Maybe you can elaborate on the "studied" part of your comment with specifics. That part was interesting.
    - tptacek 15y ago
      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.
      - mapgrep 15y ago
        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.
        tptacek 15y ago
        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.
        15y ago
masklinn 15y ago
> 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.
- tptacek 15y ago
  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).
  - burgerbrain 15y ago
    Do you happen to have a patch? I might be interested in that :)
    - tptacek 15y ago
      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 <ciphersuites>. 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.
    - seiji 15y ago
      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