[jrochkind1]

Okay, I understand what he means about cargo culting, and that to really make your server secure you have to actually know what you're doing.

But okay, let's be realistic here. Let s look at the real thing that just happened to me.

I went and used the awesome tester at ssllabs.com that OP recommends.

It told me that my server doesn't support newer cipher protocols that it should support, and that it doesn't support forward secrecy.

So, okay, I start googling on how to fix this. It looks like supporting forward secrecy is also an issue of cipher protocols, if I support the proper cipher protocols I'll support forward secrecy.

Okay, how am I going to figure out which cipher protocols to configure as supported in apache? I'm to google and copy and paste someone elses apache configuration. That is, I'm going to cargo cult it.

What else is possibly realistic for me to do? How many hours would it take for me to actually understand myself which ciphers are secure, which are preferred, and why? Not just how many hours would it take now, but how many _continual_ hours to keep up with developments?

We all can't be experts at this level in this area -- that level of expertise in security is pretty much a role all by itself. And we can't all even have such experts on staff. We've _got_ to rely on external experts, anything else is unrealistic.

Call that 'cargo culting' all you want, but what I need is an expert to tell me what my apache config should be -- sure I'm going to read up to get enough background to basically understand what they're talking about, but there's no way I'm going to become enough of an expert to make this determination on my own.

No?

Many use apache httpd. Seems to me apache httpd should ship with proper SSL configuration, and apache httpd team should provide notification channels for people to change configuration on their already-installed apache when best practices change. Figuring this out can't be a task for each individual 'customer', for basic use cases and routine needs, it should be the task of the 'vendor', no?

[crpatino]

This is yet another manifestation of the dark side of open source movement: the expectation that the generosity of the few must always support the comfort of the many. More than once I have commented that the only missing feature of GPL is that all free software must be distributed in source code, and compiled/build from scratch in every system it is to be deployed. Binary distribution requires a parallel form of licensing with appropriate fees/royalties.

Your case would be easily be solved if you were willing to pay an expert provider for their know how in implementing this types of solution. This solves reasonably well the problem of reliability (customer is unable to tell a lemon from the real thing, but is at least able to demand a refund or sue in case of breach of contract from the part of the provider).

This does not have to be expensive either. For a couple USD$100's you could have access to standard configurations, designed to meet the common needs of most customers. Or you can pay premium (a.k.a. consulting) fees to have a tailor made solution made for your particular needs.

[jrochkind1]

Well, I don't need to pay $200, I can also Google around for standard configurations designed to meet the common needs of most customers -- plenty of people are more than happy to share all sorts of info on proper SSL configuration for free. As for instance, the OP.

But if I just find a configuration online and use it, am I 'cargo culting' as the OP warns me against? But then, am I doing the same thing if I pay someone for it instead of finding it online for free, am I still just 'cargo culting'? $200 or not, I'm still just taking what someone else gives me and plugging it in. I guess in either case it depends on who I get it from, and how I am deciding their reliability.

I don't think it's the 'dark side of open source' to suggest that apache would be doing a service to it's users by providing out-of-the-box config that's actually secure. I realize they don't 'owe' it to me, as they 'owe' me nothing at all, including continuing to provide httpd at all. But let's say httpd was completely unstable out of the box, crashing all the time, unless you used expert knowledge to configure it to be stable, possibly by paying an expert $200. Would it be the 'dark side of open source' to suggest that made it less high-quality software than it could be, that to be quality software it needs to be stable for most common use cases out of the box?

In 2014, I think expecting software that supports SSL to be actually secure out of the box for, as you say, 'common needs of most customers', is just the same as expecting it to be reasonably stable. Doesn't mean it will be, doesn't mean the open source developers 'owe' us anything, but users making their expectations and priorities clear is part of what influences developer priorities too.

But you know what, yeah, I'm going to go there, if in 2014 you are supplying software to users (whether open source or not, whether free-as-in-beer or not) that supports TLS/SSL, or any other crypo, then you _do_ have some responsibility to supply actually secure software, or you are doing a disservice to your users (whether or not they are paying you) and to the internet at large. I don't think this is actually a very controversial statement. Nobody has to supply crypto software, open source or proprietary, for free or for $. But if you are, then, yeah, you have some responsibilities to do it right. We can certainly disagree on what 'do it right' means, but few would disagree with the basic sentiment.

[danimo]

I've essentially answered this in https://news.ycombinator.com/item?id=7620756.

Basically, this cannot be the sole task of Apache, as they rely on OpenSSL via mod_ssl. Some parts are apache specific (OCSP stapling), but others, just like cipher suites, purely depend on OpenSSL. But I agree that Distributors (as the "Vendors") need to come up with a suitable solution.

[sp332]

I don't think that's true. Copy-and-pasting an apache config because it does what you want is different from copy-and-pasting an apache config and hoping that it does what you want.