Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Nginx doesn't suck at SSL after all

matt.io

Post reply on HN
Print view View original

51–60 of 112 posts

Re: Nginx doesn't suck at SSL after all

#51

Post by m0nastic »

khafra wrote: post #48
tptacek wrote: post #40

Earlier quoted context omitted.

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 bad…

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.

Re: Nginx doesn't suck at SSL after all

#52

Post by nuclear_eclipse »

seiji wrote: post #33
burgerbrain wrote: post #26

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…

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?

Re: Nginx doesn't suck at SSL after all

#53

Post by tptacek »

mapgrep wrote: post #49
tptacek wrote: 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.

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.

Re: Nginx doesn't suck at SSL after all

#54

Post by tptacek »

burgerbrain wrote: post #41
beachaccount wrote: post #36

Earlier quoted context omitted.

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.

Their patchy security doesn't render his argument invalid. Edit: beachaccount: Financial institutions not using DHE is not a logically sound counter to "There's nothing wrong with using DHE algorithms, particularly if you're going to be transferring financial secrets around." While those institutions may chose not to, there is nothing wrong with others choosing otherwise . Additionally, patchy security on the part of…

"Patchy security"? What are you on about?

Re: Nginx doesn't suck at SSL after all

#56

Post by jamwt »

masklinn wrote: post #19
tptacek wrote: 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.

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!

Re: Nginx doesn't suck at SSL after all

#57

Post by tptacek »

benblack wrote: post #43

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.

Re: Nginx doesn't suck at SSL after all

#58

Post by tptacek »

jamwt wrote: post #56
masklinn wrote: post #19

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.

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.

Re: Nginx doesn't suck at SSL after all

#59

Post by seiji »

nuclear_eclipse wrote: post #52
seiji wrote: post #33

Earlier quoted context omitted.

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…

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

Re: Nginx doesn't suck at SSL after all

#60

Post by benblack »

tptacek wrote: post #57
benblack wrote: post #43

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.

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

Matt - "Unfortunately, it also includes a very computationally intensive cipher using an ephemeral Diffie-Hellman exchange for PFS. Sounds scary already, doesn't it? ... The problem cipher is DHE-RSA-AES256-SHA [b]."

The first is factual and straightforward. The second is muddled and clearly skewed towards blindly disabling DHE. I believe we are in agreement that it is irrelevant to almost everyone building on nginx: their connection rates are so low they will not notice the overhead introduced by DHE.

I am sniping at enthusiastic ignorance and encouraging others to behave similarly. I hope that is all quite clear now.

Hugs and kisses, Lil' B

Post reply on HN