borgbackup / borg

Deduplicating archiver with compression and authenticated encryption.
https://www.borgbackup.org/
Other
10.73k stars 733 forks source link

Security Feature: Error if local / repository nonce are not in agreement -- improve encryption trust #8218

Closed QUser534 closed 1 month ago

QUser534 commented 1 month ago

Given that borg encryption is based on a trusted setup with the server in the case that the local nonce is lost, then I think it would be useful to error if local / repos nonce is ever out of sync. This can help detect malicious backup servers. Encryption appears to be a major weakness of borg and it's need for a trusted server. This change would remove the need to trust the server and thus make borg encryption far more robust.

Having a "--error-on-nonce-mismatch" option would mean that any time the local / server nonce are not in agreement (not equal because one is missing or of different value), then instead of backup up borg will present a security notice. This would be completely opt-in as only a backup run with "--error-on-nonce-mismatch" would be affected, so it is backwards compatible.

For example, many people use borgbase. There is no easy way to determine if borgbase is serving bad nonces, so people could be getting silently attacked. Of course this could only happen if the local nonce was lost (I assume) which is unlikely in most cases, but better to be safe than sorry by detecting when nonces are not in agreement.

ThomasWaldmann commented 1 month ago

The local and server nonce can be easily out of sync, e.g. if you back up with 2 different clients to same repo. Or if you run borg commands on the server also (which would make it client also).

The solution for this will come in borg2, which does not need nonce management any more, because it just uses new session keys for each borg invocation.

Also, I suggest trying the nonce behaviour with borg 1.x practically. The problematic case is if the server suggests an older / lower nonce value than it should (and than the client usually knows locally also) - that would lead to nonce reuse IF the borg client would take that value (which it does not if the local value is higher). IIRC, borg already complains loudly in that case and rejects to work with the repo.