Securely Sharing Files from Nextcloud

So we’ve been asked ‘How do you share files from Nextcloud securely’?

It’s a fair question because if you END-TO-END encrypt a file, you can’t actually share the file unless you also share a means of decrypting it.  And we don’t share our end-to-end encryption keys, EVER.

So how do we manage sharing?  How do we protect our files as we hand them over to our customers?  The short answer is with LAYERS of security:

Our files are protected by one of several levels of independent security:

Robust SSL/TLS connectivity (HTTPS all digital coms)

End-to-end encryption for files

Server-side encryption for files

Full Disk Encryption (FDE) for computer drives (server or desktop)

We can ignore FDE here as it doesn’t really come into play (it’s only really applicable here to a stolen PC).

For normal at-rest files, we have end-to-end AND server-side encryption in play.  So our files are protected against threats of all kinds.  You just can’t get at our data without TWO separate sets of credentials, neither of which are connected, neither of which are stored in a file.

When we share a file, we have to remove one of these layers (the end-to-end encryption), and that of course makes the protection weaker during the process of sharing FOR THAT FILE, since it only has server-side encryption to keep it safe.  Note that this is not “bad” – the file is still encrypted, and it’s safe from even quite determined hackers.  But you know, we like to be a bit paranoid and very responsible, so we bring other measures in play.

Firstly, here’s a real file from our server we created with end-to-end encryption still applied:

It’s very exciting.  #notReally.  You can see, the name is complete gibberish.  And for the record, if you download this ‘blob’ and view it in Notepad, this is what you get:

“îe¤ÎÈCÀ’0pMi%?/£`ÕÕäÔ}CÇ+>ê3ؽ[Æ~©HïïþÑàß·”M*ÓÝì?L‚L*x)š!ýU\nW£7zšK‚ubÎ
91Ïií=¡l‰­¸üN#åS›¬Æàçý*¨”PÔãºÕë*,8ƒÇŠûìÒ†Áè‹™p\\©Jšs|Ö_ž›”ÒÿEÊ ÈÈõÁÁ”

And as you will see later, the real file is actually a simple text message.

Once the file has end-to-end encryption removed, we can now more easily find it on the server AS THE SYS-ADMIN (or as a hacker that has somehow penetrated our system).  It takes a while, but you can find it:

Wow, there it is.  Plain as day.  This file is actually present in an lxc container.  If you can ‘see’ this, you are ither a SysAdmin or an unauthorized hacker.  But the good news, you are not at the system root (you just think you are), so your damage potential is still very limited.

The file we created especially for this demo is shown among other directories.  The server ADMIN or hacker (not necessarily the owner of the file) can “see” the file, so it seems.  But before everyone panics, let’s take a close look at what he or she can actually “see”.  There’s a file name and permissions and modification time and apparent size (meta-data if you will).  You can also see file/folder names too.  Gosh, does that mean the SYS-ADMIN or hacker can snoop on my files?  Let’s look at the contents using cat:

Well that doesn’t look terribly useful.  As you can see, the DATA are still encrypted.  Albeit this time via the SERVER keys.  A hacker and even the SysAdmin can’t look at file contents (but it’s true, he or she can see the name and other file meta data).  So, the file is still quite well protected against hacking and theft.

In fact, the ONLY way you can view these data is if you unlock the server-side encryption that’s now in effect for that file.  And for this, you either need an exploit that works against Nextcloud’s encryption (very unlikely) OR you need to somehow secure the credentials needed to login to the Nextcloud account which will then unlock these files.  For that, you need a Nextcloud password AND 2FA code (one that changes every 30 seconds), so that too we think is quite safe from unauthorized disclosure.  But when you do enter those data, the file becomes fully decrypted and is then more visible, albeit over an HTTPS connection only (our final level of protection):

So “finally”, this is a file we can read:  HelloWorld.txt, that says “Hello everyone.  Have a nice day”.  So the Nextcloud user can read the file (just as he/she should).

When it comes to SHARING this file, we actually share an HTTPS:// link for that file that includes the decryption credentials for that file.  In Nextcloud, this is what that looks like:

You can see on the bottom right that a sharing link has been created.  We also add a PASSWORD to that link and an EXPIRATION DATE for the link, so that the link will not be active for long AND you need the extra password to access the file.  We send the LINK to the file via regular email.  Regular email is not terribly safe.  It can be intercepted.  We know that.  But let’s continue:

This link looks like this:

https://cloudvault.exploinsights.com/index.php/s/aeX7irmbWfneipn

(The link won’t exist for long, so it’s probably not worth trying, sorry!).

If you click on the link and it’s still active, it will bring up THIS page:

Which is still not the file.  You need that password.  We do not send the password with the link.  We don’t even send the password via email.  We send that via another means, say WhatsApp, or Signal or even SMS.  So, to get to this file, you need the link (from an email sent to you) AND the password (sent in a different way) sent to you.  Finally, if you get the link and the password, you can click/enter the top secret password assigned to protect this file, you get rewarded in this case with this:

The file.  In decrypted form.  Finally!  You can download the file but ONLY via https:// (SSL/TLS) connection (our final layer), so even then it remains encrypted-in-transit until it hits your download folder.  Only then do we relinquish our management –> OVER TO YOU!  🙂

So that’s how we share our data.  it is ALWAYS protected with up to four layers of encryption: FDE, End-to-End, Server-side and lastly SSL/TLS.

These “layers” are gradually stripped off as we get closer and closer to sharing a file with you, but only when it lands on your machine is our last (but strong) layer of encryption removed.  We use 2FA credentials to share our data and even the Sys-Admin (or unauthorized hacker) has very little access to our data: they NEVER see raw decrypted data, but occasionally they can sometimes view a file name and some basic meta-data.

Is this perfect?  No.  We are always looking to improve it.  This system is our latest and greatest implementation, but it won’t be our last.  Is this pretty good?  We think so!  What do you think?

So this is how we ROLL our file-sharing; how we securely share data with our customer.  What do you do?

Comments by email only – [email protected] or you can catch us on Twitter @SysAdminEI