[benblack]

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

[tptacek]

Are you a little worried that you come off sounding like "Adam is one of the cool kids and Matt isn't"? Matt's conclusion is ultimately correct.

And we apparently disagree completely about DHE, because you appear to be saying you'd recommend it to web startups, despite the fact that the bank that clears those startups transactions isn't even using it.

Especially weird given that Boundary, your startup, doesn't do DHE.

[kelnos]

I think benblack's argument is that Adam can recommend disabling DHE because he knows what it is and what it does and can make an informed decision about whether or not your average SSL-enabled site needs it.

Matt simply says "I messed with my settings and leaving this one out makes it faster", without knowing whether or not turning DHE off is safe (or if he does know, clearly he's making it seem like he doesn't). The fact that it is safe -- in this instance -- isn't particularly relevant. The point is that someone who doesn't understand the security implications of something is making a recommendation about security, just cloaked in a recommendation about performance.

Anyway, I don't know any of the people we're talking about here, just trying to help clear up what I believe benblack was trying to say :)

[tptacek]

Right is right. Wrong is wrong. Pants aren't shirts. It's clear Ben doesn't think Matt is qualified to write the post. But he should have holstered the impulse to gripe about it until Matt wrote something wrong.

[kelnos]

Well, Matt did write something wrong. The original post about nginx "sucking" at SSL was wrong. Maybe it sucks for SSL in its default configuration (is that even that case, or was Matt's config copy/pasted from elsewhere?), but saying it sucks in general is incorrect and link-bait'y. You can presumably configure other web servers to suck just as much at SSL by enabling DHE ciphers and providing DH params.

[tptacek]

We're commenting on this blog post. As was Ben, who didn't comment on the previous post, but did single this one out here and, as I recall, on Twitter.

[kelnos]

It sounds like you're implying that when someone posts something on the internet, when you're evaluating the usefulness of that information, you should ignore anything else they wrote previously. Frankly I don't care all that much about Ben's motivations behind calling out the author here, but I read both blog posts as they came out, and the lack of attention to detail in the first post definitely affected my opinion of the second post. I don't think a lack of participation in the first HN discussion means you're disqualified from participating in the second one using information from the first.

[benblack]

I am recommending that people who do not understand the trade-offs and do not have the traffic for it to matter should probably leave those safe defaults alone. What the banks choose to do is unfortunate, but should not dictate behavior. If all the banks chose to jump off a bridge, etc.

Recommending people unfamiliar with configuring SSL leave defaults alone is only incompatible with our having non-default config if you are implying I don't understand configuring SSL. I doubt that is what you mean, as I am ever the optimist.

Yay!,

Lil' B

[tptacek]

Turning off DHE is safe. I assume you agree with this, because your SSL server appears unable to do DHE. But whether you agree or not, ephemeral DH is not necessary for secure SSL. As Adam Langley pointed out himself: enabling DHE without knowing what you're doing can create more security problems, because your parameters can be insecure.

I'm having trouble parsing the rest of your comment. I don't have a religious belief about what defaults are reasonable to muck with and which aren't, but: this particular one is fine to change.