Related #288

Bumping this thread.

I'm interested in providing a secured solution. I'm not convinced that TLS carries as much security as people think it does, but I do think it's a good start and a sensible recommendation.

The ideal would be, eg, when Known is used in a group environment, that only the members of that group can feasibly access the content. The trick is to maintain this when members are added to, or removed from, the group. Access-controlled content carries the same principle: you're essentially adding people to the group, but dealing with non-local users.

And, of course, doing this in such a way that it's as easy to use as Facebook and Twitter, and easier to install & maintain than WordPress, which is the bar we need to meet.

TLS depends on your attack vector: TLS is very good at securing point to point, renders passive on-the-wire attacks impractical, at least at scale. Perhaps more importantly, TLS means that you can, with some degree of certainty, ensure that resources provided by your server haven't been modified en-route... which is an attack vector previously thought nearly impossible, but now it turns out is fairly widespread.

Widespread use also provides cover/herd immunity to others, so is a generally Good Thing to do.

TLS is pretty secure, certainly much better than not using TLS, but it isn't a silver bullet. It relies on well implemented libraries with no exploitable bugs (see Heartbleed), it relies on good algorithm selection on the server (apache's defaults were terrible, they're now better, but still not perfect). Corporate solutions often have to pick compatibility over security, but the death of XP & IE6-8 will do a lot for this.

TLS is also only for transit security; typically TLS is removed at your data centre, and this is where most attacks are focussed (see NSA smiley).

My view, is a strength in depth approach is what's required and we should ABSOLUTELY use TLS as part of that, and make it super easy to set it up - via tutorials, links to certs and validators, nudging, bullying and general pestering, etc (see #210).

More widely, I think Known helps to a large degree by providing target dispersal - lots of one/two user installs rather than one or two installs with millions of users. If we can make the communication between them secure (webmentions over TLS sent via a TOR proxy to disguise the social graph, as I'm keen to do) then that will go a large way towards our goals.

Next thing to look at I think is data at rest: largely this boils down to storing stuff on encrypted drives, which is fine if your attack vector is someone breaking in to your data centre, but not if your attack vector is someone holding a gun to your kids head until you type in your password (cartel attack). Encryption of data at rest then, I think, is really only a factor if you are holding data for a third party (known hosted, rather than self hosted).

So, to mitigate cartel attacks (which in reality generally come in the form of national security letters), it is best to be able to hand-on-heart say that you have no data to turn over. Again, target dispersal plays a part here (you can tell them who your friends are, but they couldn't then find out who your friends of friends are, without going through the process over again), however it brings us back to data retention.

This was a point I made on #292 but was overruled: to really stand a chance of resisting a cartel attack you need to not be holding the data in the first place (since even if it's encrypted you can be compelled either by threat of arrest or a $5 wrench to decrypt it, and at some point someone somewhere needs to have the key). I made the point that we should only collect the minimum amount of data necessary to complete a specific task, and hold it only as long as necessary to do it.

Since the only reason to collect Exif right now is to sort out the orientation of thumbnails, we shouldn't be keeping it for any longer than that. Sure, in the future we might have another use for it, and we can start collecting it again when we do, but right now we don't. So all we're doing is making a specific node a more juicy target.

I got overruled on this unfortunately, but if you're want to get serious on this issue, you're going to have to start addressing the "collect everything just in case" instinct that pervades our industry. Encryption is only part of the solution...

Not that I'm necessarily advocating this as a "solution", but I've also been experimenting with client side encryption of data e.g. https://www.marcus-povey.co.uk/2014/06/05/openpgp-encrypted-forms-for-idno/

This might be a technique to explore for truly locked down data stores - i.e. keys generated on and never leave the client, meaning even if we get hacked/NSLed we have no way of getting the data back. Of course, the flip side of this means that if the client loses the key then their data is gone forever.

Bumping this again with thoughts regarding the hosted version.

If you're going to offer a managed solution, you're going to need to put in protection for your customers, especially if you become successful.

If you provide services to UK based users, you'll fall under the data retention laws introduced in DRIP. If you provide services to Russian users, you will have to store your data on a cloud within the RF. The trend is continuing.

Step 1 would be to make your customers fully aware of what might go on via a data jurisdiction statement.
Step 2 would be to start building in countermeasures, first and foremost you should aim to store the absolute minimum amount of data necessary to perform a service (see #292 etc), and encrypt what you do, ideally in a way that only the customer can retrieve.

One thing I was mulling is, could you move the hosted solution to a model whereby a user, on signup, enters details of their own cloud based database server (or better yet, can click on a button, enter in their AWS details and have one generated automatically). That way, you could have known run as a halfway house between hosted and centralised and fully indieweb - i.e. it's not "on their own server", but they own and pay for their own database that they legally own, but benefit from the management and software updates of a hosted service.

Since the customer owns the database, data retention laws shouldn't apply. An attacker then is left to going after the individual customer, because if they go after you your customer can simply change the access credentials, install their own copy of the codebase and go fully indieweb, or they can attack AWS itself, inwhich case they should in theory face some push back.

Plus, if you start encrypting data based on a key provided by your customer, an attack on aws itself would be of minimal utility.

Just thinking aloud....

@benwerd what are your thoughts about hardening the hosted solution? Centralised solutions are a target, and the UK's new law for example means you'd have to retain data.

You Can Give Franchise of Known to the people of other Companies for Hosting and Managing Known

The hosted solution will support TLS by default. Beyond that I don't want
to open up the hosted version for discussion in the open source community.
On Jul 17, 2014 1:08 AM, "harsh5455555" notifications@github.com wrote:

You Can Give Franchise of Known to the people of other Companies for
Hosting and Managing Known

—
Reply to this email directly or view it on GitHub
#203 (comment).

We will absolutely be creating partnerships with other companies providing Known services.

It's also worth saying that Known will be on the IndieBox, which will let anyone easily run it on a friendly appliance that can actually live inside your home or office.

If u want we can take up the responsibility for INDIA we have a nice infrastructure and server facility also

Bumping this with some notes on corporate environments:

It is quite common for corporate installs to install a SSL proxy with a certificate trusted by all the machines in the network.

Not a great deal coders can do (although folk might want to look at my in browser PGP form submission tool [/plug]). More of a FYI - got very disturbed when, on a visit to a corporate a while ago, I started getting warnings when testing out stuff over curl and started getting massive numbers of cert errors.

Also, it seems, on airline wifi: https://nakedsecurity.sophos.com/2015/01/07/gogo-forges-youtube-ssl-certificate-to-throttle-high-bandwith-usage-on-flights/

The IETF have an RFC (https://tools.ietf.org/html/rfc7258) which all internet protocols should factor.

In a nutshell, things should be built with an understanding of selector based surveillance. Largely this means never sending unique identifiers in the clear.

In an ideal world I'd suggest not even using sessions on non TLS connections, but I'm aware that's not practical for the project, at least at this stage.

Bumping with the info that letsencrypt is now out. Is it possible to integrate with this somehow?

For example, could the installer detect whether it's installed and trigger a generation of cert?

Also noting that given that TLS is now essentially free, can we revisit the level of nudging and pestering we do?

Modern browsers now start giving in-your-face warnings when a password input field is delivered over a non-TLS connection, with the obvious intention of eventually blocking POSTing of those forms entirely.

Could we start warnings? Perhaps starting with admin logged in warnings on the diagnostics terminal and ramping up from there...?

Archiving this.

Good discussion, but this is going to be an ongoing thing