Gnome-shell-extension-gsconnect: Deprecate/remove DSA

[rugk]

This issue has already been brought up in https://github.com/andyholmes/gnome-shell-extension-gsconnect/issues/83#issuecomment-429296303, but I strongly suggest to track it properly in a specific issue.

So as far as I understand:

• DSA is still used by the current Android app.
• Oreo+ devices will have RSA in the next device. (So what is about old devices?)
• I is used only used for sftp as far as I see, as the rest of KDE Connect uses TLS, AFAIK.

As this is a security issue is very obvious. They have been disabled in OpenSSH in 2015(!!) e.g..

Generally ssh-dss is deprecated because it is possible to break with current technology allowing an attacker to impersonate you, but still not decrypt a session.

Yes, and when they can impersonate you, they can do a Man-in-the-middle attack and thus catch everything what you send. This is effectively breaking the encryption.

There is no way around it. In the shorter or longer time you have to remove it. At some point of time you really need to show a warning for "insecure connection" ("legacy connection" or so) as to make users aware that some component/device needs to be upgraded.
Of course this requires that RSA support is present in all KDE Connect implementations.

[andyholmes]

Yes, and when they can impersonate you, they can do a Man-in-the-middle attack and thus catch everything what you send. This is effectively breaking the encryption.

Actually, MITM attacks are not possible because of the Diffie-Hellman exchange, whose parameters are signed with the device's private key. In the case of the KDE Connect protocol, before a DSA encrypted session is even started:

• the two clients negotiate a trust-on-first-use TLS connection, which must then be manually paired
• the local client requests the remote client start the sftp server over TLS
• the remote client responds with an arbitrary port between 1739-1764 and a per-session, randomly generated password (still over TLS)
• the local client mounts the remote filesystem:
  
  
  
  • at the port provided and...
  
  
  • using the randomly generated password and...
  
  
  • using private key authentication which...
  
  
  • must be the same private key used to pair with the device, and its TLS connection
  
  
  • [now DSA encryption is happening]
  
  
• if either the sftp server or device disconnects, everything above is reset

So to successfully "crack" on of these sftp sessions, you must break the RSA key of the TLS connection, not the DSA key:

• break the 2048-bit RSA key used for TLS connections
• impersonate the KDE Connect device...
  
  
  
  • at a time when the real client is not on the network (device connections are exclusive)...
  
  
  • and fake it's kdeconnect.identity packet and all relevant fields
  
  
• proceed with normal mounting process above

Here's a couple posts that might explain the ssh/dss part a little better/more thoroughly:

• Why OpenSSH deprecated DSA keys
• How does SSH use both RSA and Diffie-Hellman?

As it stands now, DSA is only used as a fallback when a device requires it, but that currently amounts to about 99.9% of users, since you will currently need the Android app built from git, running on Oreo+.

[rugk]

Yeah, okay I do not too few about the KDE Connect protocol to evaluate whether it enables an attack. However, what's for sure is that it that it won't hurt to finally get rid of legacy encryption algorithms.

BTW upstream issue opened here: https://bugs.kde.org/show_bug.cgi?id=400340

[andyholmes]

That's to be expected, I had to review the plugin quickly to remind myself how it all worked. We should still leave this open though, since hearing that you're using a deprecated encryption is worrying if there's no explanation. OpenSSH didn't actually explain it very well when they deprecated DSA, they just said "it's deprecated".

I think that what's holding RSA back is the Apache MINA server, which is about to be updated in the next Android app release. If it's actually the Android OS version then older devices will just be stuck with it, but that would a upstream bug in Android and nothing we can fix.

If RSA ends up being supported for all devices, then I think it will be good to show warning notification because we can link to the new Android app, but otherwise it will just show every time for almost everyone.

[andyholmes]

So, as mentioned in the release notes for v15, the latest release of the Android app (v1.10) doesn't rely on DSA encryption anymore and GSConnect (and KDE Connect) will already prefer RSA encryption.

It should be at least a week or two before there are enough changes to release a v16, but I think we can be sure everyone has upgraded by then, so we can target DSA removal for that release. This will also help with #83 since we'll know we don't need to do anything weird with GIO.