Early Testing for Untrusted (Encrypted) Devices

[cosas]

The log is here : https://github.com/syncthing/syncthing/issues/7137

length: read tcp 192.168.22.30:23000->192.168.22.29:22290: wsarecv: An existing connection may have been closed by remote host. (translated)

One device now sees the other stable after changing own setting from tcp://23000 to dynamic+https://relays.syncthing.net/endpoint, tcp://23000 but the other still suffers disconnections (setting is dynamic+https://relays.syncthing.net/endpoint, tcp://:22290):

192.168.22.29:22290-192.168.22.30:23000/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256 closed: receiver error: illegal base32 data at input byte 1

[calmh (Jakob Borg)]

The log entries quoted here are not mentioned in that issue. It looks related to encryption though, so might warrant an issue of its own with more log context on both sides.

[cosas]

I deleted the folder at untrusted side and the connections drops stopped. At the same time, the issue described in the filled bug disappeared. Disconnections seem to be related to the described issue. Easy to reproduce : just add a file at untrusted side, and wait for detection. Eventually deleted it.

[cosas]

@calmh

The log entries quoted here are not mentioned in that issue

Yes Jakob, these are the log at untrusted. Above is a piece from trusted.

[imsodin (Simon)]

@cosas

When a device is set Untrusted, sharing any Folder with them “requires” a passphrase as stated in the doc. This is OK (Save button disabled in Folder’s Edit/Folders tab as long as no pw is set for them), but when I add the Folder from within the Device’s Edit/Folders tab the check is not performed.

Also, I’d like to see why the Save button is greyed, e.g. using a red font for “If untrusted, enter encryption password” text in fields for which the device didn’t successfully passed the test… better or plus, “You set it Untrusted. Use a password”. There may be a challenge coding this for Device tab at the moment of Device creation. I beg you’ll find, it seems the same you met some years ago when you reached to workaround create a new Folder paused by allowing ignores settings on folder creation.

The first paragraph was a simple fix. For the second the field without a PW was already marked as “invalid”, which gives it a red frame. Now I also changed the text in it similar to how you proposed - didn’t require any weird workarounds: gui: Fix & improve sharing with untrusted device by imsodin · Pull Request #7148 · syncthing/syncthing · GitHub

[tomasz86 (Tomasz Wilczyński)]

I would like to test the encryption, but I am unable to get the GUI to change.

I have set all devices to “Untrusted” like this:

    <device id="" name="" compression="metadata" introducer="false" skipIntroductionRemovals="false" introducedBy="">
        <address>dynamic</address>
        <paused>false</paused>
        <autoAcceptFolders>false</autoAcceptFolders>
        <maxSendKbps>0</maxSendKbps>
        <maxRecvKbps>0</maxRecvKbps>
        <maxRequestKiB>0</maxRequestKiB>
        <untrusted>true</untrusted>
        <remoteGUIPort>0</remoteGUIPort>
    </device>

but the GUI is not changing.

Am I doing something wrong? Previously, I did get the GUI to work no problem when I compiled directly from the encryption branch, but now, after everything has been merged into the main branch, I cannot make it work again. I have tested two different browsers, but to no avail.

I am testing with the current main (ab53687).

Edit 1: Never mind. I missed the necessity to add the feature flag . I got confused by the “Untrusted” option available in the config for each device.

Edit 2: By the way, the GUI seems to work fine in IE11 under Windows 7, for what it is worth .

[tomasz86 (Tomasz Wilczyński)]

I am getting these errors when trying to accept a new encrypted folder.

Failure checking encryption consistency with device XXXX for folder "test1" (zh3on-qqt9y): folder is configured to be encrypted but not announced thus

Connection to XXXXX at 192.168.56.1:13624-192.168.56.1:13620/tcp-server/TLS1.3-TLS_AES_128_GCM_SHA256 closed: closed by remote: receiving cluster config: folder is configured to be encrypted but not announced thus

What I am doing is:

1. Add the untrusted flag to both Device A and Device B.
2. Create and share a new folder encrypted with password from A to B.
3. Accept the folder on B.

Then the connection between A and B drops completely and does not seem to reconnect until I remove the newly shared folder.

[imsodin (Simon)]

On the untrusted side when accepting or creating the folder, you need to set its folder type to “receive-encrypted”.

There’s two things to potential improve here: Better error messages and some way to convey the information to the gui that the to-be-added folder should be receive-encrypted.

[tomasz86 (Tomasz Wilczyński)]

Ah, I see. Now it is working .

Maybe the other folder types should simply be unavailable (i.e. greyed out) when accepting an encrypted folder?

Why does the entire connection between the two devices drop though? Is this expected?

More error messages, this time after trying to manually change the folder type in the advanced configuration. It does not seem to work though. Only by completely removing and re-adding the folder as “Receive Encrypted” I can get the two devices to connect.

2020-11-28 01:08:15 Connection to XXXXX at 192.168.56.1:13620-192.168.56.1:13624/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256 closed: receiving index: illegal base32 data at input byte 1
2020-11-28 01:08:15 Exiting indexSender for rn5bb-vz5is to XXXXX at 192.168.56.1:13620-192.168.56.1:13624/tcp-client/TLS1.3-TLS_AES_128_GCM_SHA256: service should not be restarted

[imsodin (Simon)]

@tomasz86

Maybe the other folder types should simply be unavailable (i.e. greyed out) when accepting an encrypted folder?

There’s no information about whether a new folder is encrypted or not available in the GUI right now. That’s one of the two things to improve potentially (maybe not that easy to do) mentioned above.

@tomasz86

Why does the entire connection between the two devices drop though? Is this expected?

Yes, that’s expected: If a device notices a wrongly (un-)encrypted connection it drops that connection.

@tomasz86

More error messages, this time after trying to manually change the folder type in the advanced configuration. It does not seem to work though. Only be completely removing and re-adding the folder I can get the two devices to connect.

You are on the RC, right? That’s a bug fixed on main. At this point if you want to test encryption/untrusted, you’ll have to use nightly releases.

[tomasz86 (Tomasz Wilczyński)]

@imsodin

You are on the RC, right? That’s a bug fixed on main. At this point if you want to test encryption/untrusted, you’ll have to use nightly releases.

I have mentioned this above but it probably got lost in my long posts, but I compiled from main (ab53687) today and have been testing using only that, so I should have all the encryption-related commits.

@imsodin

Yes, that’s expected: If a device notices a wrongly (un-)encrypted connection it drops that connection.

Hmm, but this seems to persist even after removing the folder from B… Only after removing the folder from A too and recreating it from scratch I seem to be able to get the two devices to connect again.

[imsodin (Simon)]

Yeah missed, then you should be good indeed.

I don’t quite get anymore what exactly you are doing now and which error you see (there have been two: the encryption config one and the base32 one). Could you recap the current situation again please.

[tomasz86 (Tomasz Wilczyński)]

Yeah, I am sorry for the confusion.

Let us start again from scratch.

1. Enable the “Untrusted” flag on Device A and Device B.
2. Share a folder encrypted with password from A to B.
3. Accept the folder on B, but not as “Receive Encrypted”.
4. Connection dropped and closed: receiving cluster config: folder is configured to be encrypted but not announced thus in the logs.
5. Manually change the folder type on B to “Receive Encrypted”.
6. Both devices reconnect and are “Up to Date”.

However, this suggests that everything works as expected. I am unsure now how I managed to get the base32 error… as I was using exactly the same Syncthing version then. Now there are no errors.

I will report back once I find the culprit.

[tomasz86 (Tomasz Wilczyński)]

I have found a different problem. 9d1ee2f seems to be missing from the encryption GUI. This means that the “Ignore” button for new folders does not work in certain circumstances.

[imsodin (Simon)]

You aren’t suposed to change folder type from/to receive-encrypted. It’s possible that when before you already had scanned items while not being receive-encrypted, that after changing that those items were still around, causing this error.

@tomasz86

I have found a different problem. 9d1ee2f seems to be missing from the encryption GUI. This means that the “Ignore” button for new folders does not work in certain circumstances.

That’s a noop change, just renameing id to device.

[cosas]

Some things may need to be greyed/disabled on untrusted side : ignores as this makes no sense (real file names being unknown), and some (if not all) styles of versioning (maybe simple trash can could perhaps be kept for restore purpose ?).

Keep zen devs, this is just cosmetic as long as Untrusted isn’t pushed in the wild, allow yourself to postpone.

[calmh (Jakob Borg)]

Yeah this is why we do the testing, there’s a lot of things to tweak before general availability.

[imsodin (Simon)]

@cosas

Another wish: it would be great, when a peer that is intended to be receiveEncrypted receives a membership notification, that he was warned to switch to Advanced tab to set himself “Receive Encrypted” before “Save” as we won’t give him the password.

Automatically selecting receive-encrypted folder type when accepting a remote shared that is encrypted for us is pending here: all: Automatic/disabled folder-config when receive-encrypted by imsodin · Pull Request #7327 · syncthing/syncthing · GitHub

[cosas]

Hi

Does the Untrusted feature still depend on the advanced Feature Flags setting?

[imsodin (Simon)]

Yes.