I just configured a kopia server, but I’m very surprised: I was expecting at some points that I would need to provide the password of the created repository when connecting, but it is not the case, I just need to provide the password of the current user. Similarly, the password is not even asked in the server when rebooting. So is the repository really encrypted server side? Said differently, if one corrupts the server, can they decrypt my whole backups? If not, how can the kopia server encrypt the repository while sharing deduplication between users? (i.e. all users must “know” the password, or the server) I’m quite worried that kopia’s server is insecure in server mode against a corrupted server…
The Kopia server acts as a proxy for access control and therefore needs to verify a user’s credentials only. It does not have to know the repository password as all data is encrypted and decrypted at the client’s end.
@christoph thanks, but after checking, your statement is wrong: kopia server IS insecure and data are NOT encrypted client side but server side, hence the server must be trusted. The first clue is that I don’t need to specify the repository key when connecting from the client: the only specified credential is the password of the user, but as far as I know it relates in no way to the repository key.
Worse, I can run on the server kopia repository status indicating that the server itself is connected to the local filesystem repository, explaining why I don’t need to re-specify the key of the repository on restart as connection is not removed upon restart. Since the repository is opened server-side, I can run any mount command from the server to read user data, and this way I succesfully decrypted all backups server side without knowing any user password. I don’t understand how the doc can be so misleading, a huge warning the be written here saying that the server must be trusted!!
This leads me to my second question: how can we have both an untrusted server and forbid users to remove snapshots unless they specify a specific non-cached password? (I want to prevent a virus on the client to remove my snapshots on the backup server)
Object locking by your cloud provider is only way to ensure that your data is protected fully from malicious user:
and kopia is only FOSS backup software I am aware of which has it implemented. Be careful when playing with it… There is really no way to delete your data before lock expires (and of course paying for storage space used) short of terminating your cloud storage account completely.
You can not solve it reliably relying only on local solution. As at the end you have to trust some machine and user in order for backup to work:) The best what you can do is to run your server in append only mode.
Would you mind sharing the source of this statement?
Well I can’t find official sources, but I just tried to run in the server kopia snapshot list and kopia mount SNAPSHOTID FOLDER and I could read all data… so unless I misconfigured it is a proof of not being secure.
1 Like
I’ll do that then if server mode can’t work, thanks!
It seems like the s3:BypassGovernanceRetention + governance mode (Locking objects with Object Lock - Amazon Simple Storage Service) can help to remove them before no? And I plan to use minio to self host it.
You mean kopia server? Seems to be insecure for what I see as discussed above.
Well you can assume that either the client or the server are honest and get meaningful security guarantees in either cases with a proper protocol.
This is completely by design and client-side vs server-side encryption have different use cases and trade-offs. Doing encryption client side is appropriate when you don’t trust the server and Kopia supports it, just not in the “repository server” mode.
Kopia repository server mode is specifically designed to avoid having to distribute data encryption keys to semi-trusted/untrusted clients (typically employees in a company who can’t be fully trusted to not spy on/attack one another), hence it must be the only one that can encrypt/decrypt the content on behalf of them. In server mode hashing/deduplication happens on the client side, but encryption happens on the server. The data between client and server is protected in transit using TLS so it can’t be spied upon on the network.
The classic/non-server mode of Kopia supports end-to-end encryption where all clients (who trust one another, typically a single user on multiple machines/home lab/family situation) have access to shared repository encryption key and they are responsible for encrypting data before it is sent. In this mode the encrypted data lands directly in S3 so no server ever sees the data unencrypted.
For example in my home I use the classic mode backing up ~15 machines to Wasabi. Many businesses use Kopia in server mode - since that allows the server to apply certain access controls and policies centrally and protect the encryption keys.
1 Like
Thanks a lot for this clarification, this use case is indeed interesting in specific settings, but it should really be properly documented, as I was myself expecting to have client-side encryption for any client (and I’m not the only one).
It’s precisely because of the access controls that I wanted to use the server mode. It would be great then to provide two modes for the server: client-side encryption vs server-side encryption.
This is quite the opposite of what the server documentation say (which I linked to before):
Repository Server allows an instance of Kopia to proxy access to the underlying storage and has Kopia clients proxy all access through it, only requiring a username and password to talk to the server without any knowledge of repository storage credentials.
(Emphasis by me)
Now I’m utterly confused. 
Edit: Oh wait, I got that wrong: It’s not the server but the clients who don’t need any knowledge about the credentials.
Edit 2: Could that sentence be made clearer, e.g.:
Repository Server acts as a gatekeeper: it is the only place that holds the repository’s actual storage credentials. Clients never use them. Instead, a client merely authenticates to the server with a username and a password; the server then forwards the client’s traffic to the underlying storage.
I think that this is indeed quite unclear, and easy to miss. I’d add a big warning in the doc saying that contrary to the other modes, the server has the capability to decrypt all backup data of all users. For now, saying that users don’t know the repository storage credentials does not imply that the server knows them (e.g. they could do some sort of multi-partite computation to encrypt while nobody knows the key…)
Well… that has been the case for any backup server out there, which has to be able to perform deduplication on the data it handles… As @jkowalski stated, this is by design and rather than getting all worked up about this fact, I’d suggest to think hard about how you can safeguard your Kopia server host. There’s no such thing like a free lunch and you’ll always have to put in the work to secure such a system - or not, but then don’t try to shift this responsibility to the backup software. Keeping a backup server save is, has been and always will be paramount!
Repos do have ACLs and a repo’s user will only be able to access its own data, so even if some client got compromised, it would only affect its own snapshots - but that would be the same for any other backup solution, where a client got compromised.
Regarding your 2nd question… you could place an ACL on your repo, which only allows a client to add new snapshots. Then, you’d set the repo owner as the maintenance user for the repo, so Kopia server still can remove snapshots that are no longer subject to the repo’s retention policy/policies.