Disaster Recovery - Trusted Vs Untrusted Devices

I guess let’s agree to disagree here.

3 Likes

It’s just POV’s. I appreciate your input. Thanks.

1 Like

Mixing 2 objectives into 1 user function is not wise (even if using the same portions of code), eg

  1. Having the purpose of using “Untrusted Device” is to secure the data on the receiving end device folder
  2. Having the purpose of “double transport encryption” is to secure the data only during transfer (eg making the receiving device “trusted” by supplying a password).

For 2) surely a different method of transfer (more secure) can be done - like a longer compiuter generated Folder ID to use for encryption (which is far more secure than a human typed password). In any case these 2 user functional components should be separated as they serve differnt purposes. eg for 2) even a separate option to enable transfers regardless of trusted/untrusted devices could be designed (this option is really only for ‘trusted’ devices (to use encrypted-then-decrypted data), since untrusted devices have data encrypted anyhow)

Also as it currently stands the function dependency of Folder Type Vs Password is in reverse - when accepting a new encyrpted folder, you need a password FIRST to use the 3 folder types, not the other way around (otherwise don’t accept the adding of the folder, instead add it manually as a normal folder). If decryption is required (eg making an untrusted device ‘trusted’ again), then one can add the password first on the receiving device, then be able to only selct the 3 folder types (ie removing the oopton to select “Recevei encrption”)

I would suggest a review to splitt these 2 “requirements” instead of merging them into one user function as per 1) and 2) above.

1 Like

This is absolutely pointless and does not add any security. Nobody should use the untrusted device mode for this.

We’re using the latest and greatest TLS version and cipher modes for communication. If you don’t trust that, you can’t trust any encrypted communication in the world.

2 Likes

I completely agree. So why allow the untrusted device to decrypt the data via password?

It achieves the same outcome (with much less resources) to simply not set a password on the sending device.

1 Like

And why prevent that? You might want to do that for topological reasons.

You have 3 devices, one of them is out of your control, but has shared the folder with you encrypted. Now you got a password and would like to sync that data with a third device unencrypted.

You need to be able to pick the folder type to do that.

2 Likes

It’s early days for the feature. It’s not inconceivable that there’s a valid use case for it, so it’s not currently forbidden.

1 Like

Fair enough for alpha/beta or dev releases (in controlled environments, etc.), feature requests Vs exploratory feature dev, etc.

in any case, by doing so in the current form, it blocks the legitimate/currently in use usage - that is to prevent decryption on untrusted devices. That’s a pretty big one.

I’ve made a request to add a ‘lock’ feature on the sender side, so it caters for the current valid use and as you say…possibility of these ‘known cases’ eg undoing the feature with providing a password to decrypt folder data. If enabled on the sender device (lock trigger), then its simply stops the ‘folder type’ dropdown from changing and to prevent entering a password, on the untrusted device

Also in current form, the dropdown change to “Send/Receve/Send 7 Receive” on untrusted devices should be dependant on providing a password when adding the folder, not the other way around - although this could be viewed as a ‘chicken and the egg’ conundrum, except folder tyoe has a default setting, passwords do not. This will ensure failures do not occur (eg failure messages, etc.).

Some known and valid cases are when untrusted devices are run by not-so-technical people, and mistake minimisation should be a priority.

1 Like

@AudriusButkevicius Fair enough, but thats not how ‘feature requests’ work - normally devs don’t develop features which are unknown in function, and release then into the wild. They need to be mapped out to knowns and added on as more is known/defined…scope .

In any case, the current form can be kept, but need to also ensure a ‘known use’ is not compromised to ‘known uses’ - ie preventing untrusted devices from decyrpting and locking the data on them for storage only use.

The only other use for decryption may be when someone marks the device itself as “untrustworthy”, but not sure why thats even an option since its the folder syncing that determines trust, not the device alone (ie I can set a device as ‘untrusted’ and it does nothing - I have to sync the data for it to mean anything. The device ‘trust’ appears to just invites errors.

1 Like

Do you mean using the Advanced Configuration to set the own device as “untrusted”? This is a different issue (see https://github.com/syncthing/syncthing/issues/7359). Basically, there are quite a few settings that make no sense when applied to the own device, but right now they are still available to set. Most of them will likely have no real effect though.

1 Like

There’s a thing called scope - creating functions without proper scope appears to be pretty rampant here, and creating functions without clear objectives is just bloatware.

Closing a user “Feature Request” in such an arrogant way clearly shows someone here is on some kind of power-trip.

If the assumptions of what encryption is predefined in some special way here to the norm of “securing owners/sender data”, then don’t call it encryption call it something else. Allowing decryption on untrusted devices defeats the purpose of encrypting it in the first place. Claiming therei s some secret use for decrypting data on untrsrted deviec and claming “Synching has no business determining what the untrusted device does” is hypocritical at best, since its Syncthing that determined the encrypted data in the first place.

Good luck to you all…

1 Like

As I said on the ticket, there are no “owners” of data in syncthing, all devices are made equal, and I think your feature requests are all wanting to force other devices to do something, which is fundamentally opposite of how syncthing is designed.

If it makes you happier, we can remove the untrusted flag, so you can finally find peace, because you seem to over exaggerating of what that flag does, and assume that checking that flag allows your device to go on a power trip changing data or settings on other devices against their will.

5 Likes

Syncthing can decrypt stuff stored on disk at the untrusted device. You need to go to CLI (see command in ST docs) and provide the secret which was originally specified on the trusted (“sending”) device. It is advisable to turn off bash history before running the CLI command - or your password gets logged on the untrusted machine.

2 Likes

A leading space is usually enough to avoid commands showing up in the history

1 Like

That sounds like terrible security advice. I wouldn’t count on it, but copy the encrypted data to some other system and continue there in a trusted environment.

1 Like

You can just read -p "pwd: " -s PASSWORD and then use $PASSWORD env var, this way it does not make it into history.

2 Likes