Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

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.

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?

Interesting. If financial institutions routinely succeed at operational security but catastrophically fail at having a secure development life-cycle, is that a startup opportunity?

I don't know about "startup opportunity" specifically, but it's pretty much the raison d'être for most application security consultancies.

Usually when first engaged, you deal with operational issues (making sure all the applications they know about are assessed), but as you build on that, you try and instill secure development practices (so that every new application they build doesn't have the same issues as the ones you've just spent months uncovering).

The number of large clients I work with who don't have any SDLC process is staggering (I'd say it's the overwhelming majority of them). For the most part, the small group of security people are tasked with trying to secure the multitudes of applications which in many cases are 20-30 year old codebases. Their developer groups may be completely separate (usually from the result of all the mergers of financial institutions) and it's basically all fiefdoms.

As you start to work up the pyramid of enterprise security "hierarcy of needs" you get to things like a secure development life-cycle, but not all organizations are "ready" yet for that type of work. Some are just trying to figuratively stop the percieved bleeding.

Anecdote in support of your point: I was a developer who sinned in the creation of a terrible password storage system on an internal web-app that had about 50 users (why didn't I just use LDAP???). It was at a Fortune 500 financial. I was fresh out of college. The company had a large security organization in-house and very clearly documented software best-practices but I was cowboy coding on an Infrastructure team. I was the stereotypically bad programmer at a large company who makes grievous security errors. I'm not even very comfortable making this confession but I believe I've learned a lot since then.

The teams (or more likely outside vendors) that set up the bank's external-facing servers and load balancers are not going to poke around the application code.

A bank will have architecture and security teams that evaluate the applications, but their main job is to run each application through a "best practices" checklist or audit to identify potential trouble spots. An application will need to meet some kind of sane minimum requirement for password security, but many of these apps are legacy or mainframe, and not easy to change. Big banks move very slowly.

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.

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.

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.

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

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.

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

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

Just a bit of history: I was the one that prodded Igor to add this.

I had been checking things out in nginx and noticed that DH was not implemented. One quick email to Igor and he got it done the same day along with getting this into the next version of nginx. Dude is bad ass.

Now if only someone can convince him or provide a patch to add SPDY support to nginx...

So what would you do with the generated DH parameters? Literally just `cat` them to the bottom of the SSL cert? Is there anything else that needs to be done? What happens when DHE-RSA-AES256-SHA is used without having those DH parameters in play?

Yup. Just add it to the end of your private key/certificate file (NB: only applies to stunnel when configured for DH or other programs reading DHparams from a key/cert file).

If you try to use only DHE-RSA-AES256-SHA without DH being setup, nothing will connect. If you have DHE-RSA-AES256-SHA as an option with others, it will negotiate a non-DH cipher. (e.g. "DHE-RSA-AES256-SHA:!ADH:SHA" -- you can verify the ordering with `openssl ciphers -v DHE-RSA-AES256-SHA:!ADH:SHA`)

Ask and ye shall receive: https://github.com/bumptech/stud/pull/6

stunnel DH code inserted into stud.

From stud -h:

    Encryption Methods:
       --tls                    (TLSv1, default)
       --ssl                    (SSLv3)
       -c CIPHER_SUITE          (set allowed ciphers)

Edit: Though, you'd need to set DHE params, as another commenter said below. Stud doesn't do this atm, but I'm open to a patch!

I think 'seiji's right, and OpenSSL won't actually do DHE handshakes unless you give it parameters, which is another 2 lines of code that aren't actually in stud.

Fair point. Clarifying...

Reply on news.ycombinator.com