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

41–50 of 112 posts

Re: Nginx doesn't suck at SSL after all

#41

Post by burgerbrain »

beachaccount wrote: post #36
bdonlan wrote: 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.

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 one operator certainly is not a logically sound argument against this.

Furthermore, in the future, actually reply to a post in order to reply to a post. Not doing so unnecessarily confuses the flow of conversations (posts are not scarce resources).

Re: Nginx doesn't suck at SSL after all

#42

Post by shrikant »

tptacek wrote: post #6

In case you're wondering what "Perfect Forward Secrecy" is: SSL/TLS, like most protocols, uses (expensive, dangerous) RSA to exchange (cheap, simple) AES or RC4 session keys; bulk data is encrypted with session key. In the normal protocol, if you lose the RSA key, an attacker can retroactively decrypt the session keys, which are protected only by that same RSA key. In ephemeral DH mode, instead of encrypting a sessio…

Diffie-Hellman and Boyer-Moore are two algos that completely blew me away with their simplicity when I first encountered some theory on them.

http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exch...

http://en.wikipedia.org/wiki/Boyer%E2%80%93Moore_string_sear...

Re: Nginx doesn't suck at SSL after all

#43

Post by benblack »

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 maximum performance at the expense of security is a fool's game in most cases. Instead, focus on measuring your real performance requirements first, and things like sane configuration of SSL, for example by explicitly listing ciphers instead of using the impenetrable +aNULL:-yourMom syntax.

Here's my vintage code for scanning SSL configs: https://github.com/b/tlscollect

Here are a couple of must read posts from someone who really knows his SSL business:

http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...

http://www.imperialviolet.org/2011/02/06/stillinexpensive.ht...

It's great to learn.

Lil' B

Re: Nginx doesn't suck at SSL after all

#45

Post by michaelbuckbee »

tlrobinson wrote: post #25

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

There is some selection bias and context that the OP had via Twitter (people following already kind of know him and his work, etc.) whereas HN evaluates his work solely on this one post.

Re: Nginx doesn't suck at SSL after all

#46

Post by bhousel »

chc wrote: post #35
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.

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

Re: Nginx doesn't suck at SSL after all

#48

Post by khafra »

tptacek wrote: post #40
chc wrote: post #35

Earlier quoted context omitted.

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 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?

Re: Nginx doesn't suck at SSL after all

#49

Post by mapgrep »

tptacek wrote: post #20
schleyfox wrote: post #18

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.

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.

Re: Nginx doesn't suck at SSL after all

#50

Post by AltIvan »

michaelbuckbee wrote: post #45
tlrobinson wrote: post #25

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

There is some selection bias and context that the OP had via Twitter (people following already kind of know him and his work, etc.) whereas HN evaluates his work solely on this one post.

Yeah, the correct stament should be something like:

Final feeling: My long time Twitter Followers & Friends are more engagement and kind than the anonymous programmers on HN.

Post reply on HN