I really don't understand what this article is trying to say. About 2/3 of it seems to be an explanation of an SSL Labs scan. It's good to get an SSL Labs checkup for your site, but that's like 0.5% of your overall security problem.

Off your head, what is your recommendation / checklist for people running servers? He covers fail2ban as well

An audit is only around $6k. If you can afford one, you should get one.

$6k covers about 3 days of effort by a single security auditor, which barely scratches the surface for a large application like NextCloud. Sorry, security is expensive :-/.

You can save yourself some headache by using best practices and clearing away all the low hanging fruit before contracting with an expert. For example, but deploying on HHVM, aggressively using static analysis tools and clearing up issues that lead to compiler warnings, and running external application vulnerability scans from things like local Burp Pro or the hosted Tinfoil Security.

The question was about people running their own webapps. $6k is a reasonable price for a smaller project.

There aren't many non-brochure-ware applications I can imagine getting audited in 3 days. 2 person/weeks is a small app pentest project.

Yeah, I run things on my own. 6k is out of my league. I am surprised this costs so much. Can it not be automated?

Nope. It takes at least a couple months of doing daily pentests to become proficient at finding vulns. As to why it can't be automated, it takes a book to answer that. I'd recommend The Web Application Hacker's Handbook, along with The Tangled Web.

There are things you can do, of course. But unless your app is basically read-only, there are almost always one or two noteworthy vulns.

None of this concerns me for an application like NextCloud. Deploying TLS properly is table stakes. What does concern me: this app is written in PHP, famous for such a horrific design that it frequently leads developers down dangerous code paths that result in remotely exploitable bugs.

Seriously WTF are the PHP devs smoking? Just look at these tables: https://secure.php.net/manual/en/types.comparisons.php

Given the size of the codebase and the insecure language and frameworks it's built on, I would consider a NextCloud instance that touches the internet to be at enormous risk of compromise.

If you want to investigate my gut there are a million and one things having to do with its architecture and implementation that you want to look into. None of those things involve what TLS cipher suites it uses.

Just as a remark, we run a bug bounty program at https://hackerone.com/nextcloud offering up to $5,000 for Remote Code Executions.

If someone here feels challenged: We look forward to your reports. :)

This is a great response :-) Especially to people who "claim" PHP is hackable with no follow through.

While it is true that PHP is evolved more than it is designed, and as such retains the hallmarks of earlier generations and sometimes surprises you with its anachronisms, it is not true that this makes it impossible to create secure software. It just takes more discipline to avoid cutting corners. The same goes for many other languages and platforms so PHP is not alone here.

That aside, Nextcloud and similar user-extensible platforms are very hard to secure as it only takes a single slip of the thought by a single app author to open up the doors for unwanted visitors. As it is just the flexibility which gives Nextcloud (et al) its appeal this is a hard problem to solve.

I used to use all these Sync programs, but each of them had their own issues (or missing features). So I eventually switched to regular rsync + ssh.

The upside is that you don't have to install much serverside.

The nice thing with nextcloud is it allows you to share to the public, just like dropbox but self hosted.

That just means you rsync to the public www directory instead. :)

So your rsync+ssh solution to one-click share-a-link that is one-time use or with an expiration date is what?

The knowledge that one time links are a terrible means of access control.

Ahh, the old "I don't have a response so I'll just say the feature you use everyday is 'terrible'". The market would suggest you are completely wrong.

Can you help me understand how you think your solution is an alternative?

* What do you do for mobile access?

* How do you share to a single person or a group?

* What do you do for team collaboration?

Maybe I should add that I'm the only user and I don't need to sync between mobile.

I also don't need to share since all I need is to sync between my laptop and my Desktop.

What features did you miss with such minimal requirements?

Well, I guess I wanted to see what gets synced, before it gets synced. I can easily do that with rsync by running it in dry mode first.

There is also Unison, which is similar.