Live data from Hacker News

Fighting Cargo Cult – An Incomplete SSL/TLS Bookmark Collection

daniel.molkentin.net

21–30 of 35 posts

Re: Fighting Cargo Cult – An Incomplete SSL/TLS Bookmark Collection

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

Re: Fighting Cargo Cult – An Incomplete SSL/TLS Bookmark Collection

#22
post #4

Earlier quoted context omitted.

Yes, that's the exact problem that made me write this. What's particularly amazing is the amount of magical cipher suite strings shared throughout the web, most of which do not take in account PFS, or still prioritize RC4. All of that was acceptable at some point in time. Other cipher lists just don't make any sense at all, e.g. first removing a cipher (-RC4), then killing it (!RC4), all in one string with no benefit…

Thanks for writing this post, I've bookmarked it for reading later as it has plenty of links and I can see I have a lot more reading to do. If you edit or update your post, I hope you will Mozilla's excellent "Security/Server Side TLS" page at https://wiki.mozilla.org/Security/Server_Side_TLS . This helped me get up to speed quickly and provided clear examples. As proof of how good the Mozilla docs are, I tested my p…

Author of the Mozilla's Server Side TLS here. Glad that you found it helpful. Anything else that you think we should add to it?

Re: Fighting Cargo Cult – An Incomplete SSL/TLS Bookmark Collection

#23
post #4
post #2

With the rise of the cloud, now everybody manages a server. I am curious about how many of the admins actually know what are they doing. If I have to speak for myself, I set up my first ssl by following a guide that seemed to written by reasonably well informed stranger. It was my first exposure to the topic so I could not tell what I am doing until I break things and start reading deeper materials so that I can debu…

Yes, that's the exact problem that made me write this. What's particularly amazing is the amount of magical cipher suite strings shared throughout the web, most of which do not take in account PFS, or still prioritize RC4. All of that was acceptable at some point in time. Other cipher lists just don't make any sense at all, e.g. first removing a cipher (-RC4), then killing it (!RC4), all in one string with no benefit…

Yet Another Test Script: https://github.com/jvehent/cipherscan It uses openssl to find out the cipher priorities, PFS keys and a few others things from a target site. I wrote it because, while I love SSLLabs and Ivan's work in general, I find it too slow to scan a setup I'm working on many times. And I like doing stuff in the terminal.

Re: Fighting Cargo Cult – An Incomplete SSL/TLS Bookmark Collection

#24

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

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.

Re: Fighting Cargo Cult – An Incomplete SSL/TLS Bookmark Collection

#25

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

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.

Re: Fighting Cargo Cult – An Incomplete SSL/TLS Bookmark Collection

#26

TLS 1.0 was created in 1999, and has approximately 97.7% website support worldwide. The only modern browser that doesn't support TLS 1.0 is IE6. Please, do the public a favor and remove the name "SSL" from your list. Also, I get that you probably just found out what a cargo cult is, but there's really no purpose in telling people about the phrase; it doesn't help them stay more secure, and it's basically just pop psy…

IE6 supports TLS 1.0

Re: Fighting Cargo Cult – An Incomplete SSL/TLS Bookmark Collection

#27
post #22

Earlier quoted context omitted.

Thanks for writing this post, I've bookmarked it for reading later as it has plenty of links and I can see I have a lot more reading to do. If you edit or update your post, I hope you will Mozilla's excellent "Security/Server Side TLS" page at https://wiki.mozilla.org/Security/Server_Side_TLS . This helped me get up to speed quickly and provided clear examples. As proof of how good the Mozilla docs are, I tested my p…

Author of the Mozilla's Server Side TLS here. Glad that you found it helpful. Anything else that you think we should add to it?

Second-to-best solutions with older Distributions (Ubuntu 12.04, Debian 7, RHEL 6).

Re: Fighting Cargo Cult – An Incomplete SSL/TLS Bookmark Collection

#28

TLS 1.0 was created in 1999, and has approximately 97.7% website support worldwide. The only modern browser that doesn't support TLS 1.0 is IE6. Please, do the public a favor and remove the name "SSL" from your list. Also, I get that you probably just found out what a cargo cult is, but there's really no purpose in telling people about the phrase; it doesn't help them stay more secure, and it's basically just pop psy…

IE6 supports TLS 1.0

TLS 1.0 is not enabled by default in IE6, so for practical purposes, IE6 does not support TLS 1.0.

Re: Fighting Cargo Cult – An Incomplete SSL/TLS Bookmark Collection

#29

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

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.

Re: Fighting Cargo Cult – An Incomplete SSL/TLS Bookmark Collection

#30

I don't think this article is really helpful at all. The author attacks blog posts that state the current best-practices, but then goes on to recommend several books that are even more out of date than the blog posts. (Some of the books are 'theory' books and so presumably remain 'current' for longer, but not all of them). Second, instead of allowing sysadmins to find and follow simple, well-researched best-practices…

Well, "don't roll your own crypto" advice has recently been compared to abstinence-only birth control. It sounds well in theory, but in practices is prone to not work at all.

This is because most defects in security come from application developers assembling poorly understood third party solutions in ways that the original authors never intended or even imagined to be possible. Best practices and secure defaults can only take you so far, so there is a genuine need for minimum competence standards, even if those are informal and not regulated.

Post reply on HN