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

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.

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

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.

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.

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.

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.

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

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.

Speaking of fairness, how do you conclude that Ben is sniping at people for not using DHE? I've re-read his comment multiple times, and I don't see that in there at all -- explicitly or implicitly.

The words "indicate the author really understands implications of decisions about crypto is an article" were what set me off. I think I'm right; Ben doesn't really believe you need to use DHE, but for some reason doesn't think Matt rates highly enough to write a blog post about configuring SSL.

On a related topic, these are both your comments on this post:

"The win here is that losing the RSA key now only allows you to MITM future SSL/TLS connections. This is still a disaster, but it does not allow you to retroactively unwind previous DH exchanges and decrypt earlier captured sessions."

"If you've lost your RSA key, you are well and truly fucked."

Thanks for clearing that up!

Make love not war,

Lil' B

Oh. You're forum trolling. You know what though, it's always great to see you Ben. Thanks for taking the time.

Correct, disagreeing with you implies trolling. You are one astute dude, Tom. Keep up the good work!

I think that grasping at straws imply you're trolling, not disagreeing with someone else, although more than disagreeing with Tom it just seems like you're complaining...

I agree that both articles have different degrees of technical completeness, but really getting snarky because you believe that someone doesn't have the 'stripes' to write an article that ultimately agrees with the former article you're comparing it to seems to me like a waste of time. Specially since both articles basically come to the same conclusion. It gets worse when you pull two quotes from tptacek that ultimately don't change neither what he said in the beginning nor the reason he's responding to your posts.