Traffic decryption in wireshark

[brianrho]

How does one decrypt the TLS traffic sent between GSConnect and KDEConnect in Wireshark?

Per this page, I've tried adding the GSConnect private.pem file to the Wireshark RSA keys list, but the packets still appear encrypted, even for new captures.

Am I missing some step? Or does this have to do with the ECDHE usage here (like I suspect), which makes decryption impossible with the PEM file alone?

If the latter, would it be possible for GSConnect to spit out the needed secrets to decrypt the session traffic (just like it shows the SHA fingerprints under Encryption Info)?

[andyholmes]

Based on the link, it doesn't seem like the traffic can be decrypted by WireShark. If you're just looking to view the incoming JSON packets, you can just enable debugging:

dconf write /org/gnome/shell/extensions/gsconnect/debug true

This will dump a lot of private data into the log though, so you'll want to be sure to turn it off when you're done.

Other than that, you may have to go digging around in the source to modify the TLS connection.

[andyholmes]

I've been having connection/mount issues with GSConnect, I thought it'd be good to see exactly what happens in the often very-brief TLS connections.

Fair enough, but it really is just serialized JSON packets 🤷

I could try and trust that the application already logs everything relevant, but I'd rather not have to, especially with all the tickets talking about SSL or SFTP issues -- there are still errors that can happen out of band, or there could be just poor log coverage (not that I've checked).

Well, as often mentioned, SFTP and mounting are not handled by GSConnect at all 🙂. Debugging SFTP mounts for GSConnect is more or less done by debugging GVfs.

[ferdnyc]

I could try and trust that the application already logs everything relevant, but I'd rather not have to, especially with all the tickets talking about SSL or SFTP issues -- there are still errors that can happen out of band, or there could be just poor log coverage (not that I've checked).

Well, as often mentioned, SFTP and mounting are not handled by GSConnect at all slightly_smiling_face. Debugging SFTP mounts for GSConnect is more or less done by debugging GVfs.

Well, then I have good news and bad news there.

The good news is, SSH communication will also be automatically decrypted, since its encryption keys will also end up in the SSLKEYLOGFILE when the envvar is set. (In fact, in my first test that's all I got, because I missed the initial handshake between GSConnect and my phone.)

The bad news is, watching SSH negotiate ciphers and exchange credentials turns out to be extremely boring and unenlightening, in terms of debugging SFTP issues.

[brianrho]

The bad news is, watching SSH negotiate ciphers and exchange credentials turns out to be extremely boring and unenlightening, in terms of debugging SFTP issues.

That's fine, I'm assuming that the basic stuff works most times, that any errors I'm encountering won't be terribly low-level (or if they are (say, like #1203), then Wireshark's dissectors will hopefully complain loudly so I notice). Instead, it's the layers above, that will be of interest most times, which may or may not be covered by the app's logs. (And even for low-level errors that Wireshark doesn't announce, it is enough that the info is present in the trace to be found, merely requiring time and careful analysis.)

Generally, for applications that are usually too abstracted away from the network activity to give useful failure reasons, a packet trace like this should yield more precise info about exactly where/when a connection or procedure failed, even if not exactly why -- which is a better start for debugging than a lot of guessing.

[brianrho]

Enabling the application debug also works 🙂️ I already had dconf-editor installed, so I just used that convenience instead of the command-line. (And you weren't kidding about private data in the logs -- it felt odd to see texts from 5 years back suddenly get spilled in my syslog lol)

Now paired with the Wireshark trace, I hope to get a lot more insight about what's going on. For instance, here are the app logs from when I tried to Share a very small text file (containing just 1234\n) to my phone:

Jan 17 23:17:12 RhoPC gnome-shell[2424]: message repeated 7 times: [ g_signal_handler_disconnect: assertion 'handler_id > 0' failed]
Jan 17 23:17:13 RhoPC dbus-daemon[1000]: [system] Activating via systemd: service name='org.freedesktop.hostname1' unit='dbus-org.freedesktop.hostname1.service' requested by ':1.102' (uid=1000 pid=2725 comm="gjs /home/rho/.local/share/gnome-shell/extensions/" label="unconfined")
Jan 17 23:17:13 RhoPC systemd[1]: Starting Hostname Service...
Jan 17 23:17:13 RhoPC dbus-daemon[1000]: [system] Successfully activated service 'org.freedesktop.hostname1'
Jan 17 23:17:13 RhoPC systemd[1]: Started Hostname Service.
Jan 17 23:17:19 RhoPC org.gnome.Shell.Extensions.GSConnect[2725]: [/service/device.js:_readLoop:341]: Redmi  Note  7: {#012  "id": 1673997274419,#012  "type": "kdeconnect.connectivity_report",#012  "body": {#012    "signalStrengths": {#012      "1": {#012        "networkType": "Unknown",#012        "signalStrength": 3#012      },#012      "3": {#012        "networkType": "Unknown",#012        "signalStrength": 3#012      }#012    }#012  }#012}
Jan 17 23:17:43 RhoPC org.gnome.Shell.Extensions.GSConnect[2725]: message repeated 12 times: [ [/service/device.js:_readLoop:341]: Redmi  Note  7: {#012  "id": 1673997274419,#012  "type": "kdeconnect.connectivity_report",#012  "body": {#012    "signalStrengths": {#012      "1": {#012        "networkType": "Unknown",#012        "signalStrength": 3#012      },#012      "3": {#012        "networkType": "Unknown",#012        "signalStrength": 3#012      }#012    }#012  }#012}]
Jan 17 23:17:43 RhoPC systemd[1]: systemd-hostnamed.service: Deactivated successfully.
Jan 17 23:17:47 RhoPC org.gnome.Shell.Extensions.GSConnect[2725]: [/service/device.js:_readLoop:341]: Redmi  Note  7: {#012  "id": 1673997274419,#012  "type": "kdeconnect.connectivity_report",#012  "body": {#012    "signalStrengths": {#012      "1": {#012        "networkType": "Unknown",#012        "signalStrength": 3#012      },#012      "3": {#012        "networkType": "Unknown",#012        "signalStrength": 3#012      }#012    }#012  }#012}

No sign at all that the file transfer or any real activity happened in those logs (other than the handler_id errors maybe?)

And yet, the Wireshark trace at the same timestamp range, clearly shows the data travelling across the TLS link, shortly before it gets Reset by the peer:

In the end, the phone reports a failure to receive the file, whereas the PC says it was sent successfully. Looks like prime opportunity to use my newfound powers 🙂️ will take some time later to dig.

[brianrho]

Okay, turns out my issue was https://bugs.kde.org/show_bug.cgi?id=432368 -- all I had to do was set the Custom Destination to the same default Downloads folder, from a file picker.

While the Wireshark trace helped me narrow the problem to likely being a mobile-app issue, I still couldn't get exact specifics on my own because there's no KDEConnect logs at all in my Android (bugreport) logcat for some reason, despite all the log.e and log.i I can see in the source. Don't know if I need to enable something ...

[ferdnyc]

If the latter, would it be possible for GSConnect to spit out the needed secrets to decrypt the session traffic (just like it shows the SHA fingerprints under Encryption Info)?

Unlikely, but setting the SSLKEYLOGFILE envvar is child's play, and seems to work. It's the GSConnect daemon.js process that would need that value in its environment, and it's already setting TLS-related envvars as part of its setup.

gnome-shell-extension-gsconnect/src/service/daemon.js

Lines 9 to 11 in 2039513

	// Allow TLSv1.0 certificates
	// See https://github.com/GSConnect/gnome-shell-extension-gsconnect/issues/930
	imports.gi.GLib.setenv('G_TLS_GNUTLS_PRIORITY', 'NORMAL:%COMPAT:+VERS-TLS1.0', true);

Pop a line right below that in your $HOME/.local/share/gnome-shell/extensions/ [email protected]/service/daemon.js, something like...

imports.gi.GLib.setenv('SSLKEYLOGFILE', '/tmp/gsconnect-secrets.txt', true);

And you should be in business. GSConnect will even helpfully restart the daemon process if you edit its source while it's already running.

Then run a capture with Wireshark. (Seems to work better if you capture the initial handshake between the devices, so the handshake key can be matched up to the right packets. So, maybe disconnect and reconnect the device, or disable and reenable GSConnect.)

After it's done capturing, right-click any TLS packet and choose Protocol Preferences > Transport Layer Security > Open Transport Layer Security preferences...

That gets you a configuration dialog, including a "(Pre)-Master-Secret log filename" field that you can point at /tmp/gsconnect-secrets.txt.

Once that's done, you should have a "Decrypted TLS" tab on the lower right, next to "Frame".

(Edit: Though, really the "Decrypted TLS" (hexdump+partitioned ASCII) view is far less useful than the packet context menu's Follow > TLS Stream option, which opens a dialog where you can view the entire reassembled back-and-forth between the endpoints in either ASCII or UTF-8.)

[brianrho]

I don't think I'd want to push my luck too much with extraneous data sources.

However I'd expect that right now, everyone using that variable (setting it in their user profile, as is common) is already automatically enabling it for all running applications using OpenSSL or NSS (and perhaps GnuTLS too), if your theory is right that the libraries are the ones watching out for this variable, not the applications. (Excluding the applications that sanitize their environment, that is.)

[brianrho]

I finally rebooted, and the environment variable does work, yielding the needed TLS secrets -- both when set in my .profile and when set inside daemon.js alone. I can now see traffic decrypted in Wireshark for all the GSconnections, though I need to kill + restart the Android app before starting the packet trace, to ensure I capture the handshake of the long-running TLS connection (which makes sense).

I removed the profile setting though, after I noticed a chunky ~64K worth of secrets dumped into the file, after launching a browser with an existing session, though only one tab loaded/focused. No need to have all that data just accumulating, and it's probably not a good idea to leave those secrets hanging around in a widely known location anyways.

As a side-quest, I tried to print GIO_USE_TLS from the daemon to know what backend I'm using, but it seems this variable was never set since the get-env call returned NULL. So I still don't know the current backend. However, based on the discussion here and the other env-var in daemon.js, it seems likely to be GnuTLS.

[ferdnyc]

I removed the profile setting though, after I noticed a chunky ~64K worth of secrets dumped into the file, after launching a browser with an existing session, though only one tab loaded/focused.

Holy crap! I mean, I knew that was a bad idea just on principle, I didn't need any convincing of that fact, but... still, that's a LOT.

I guess (in hindsight) it makes sense: Every individual HTTPS connection would involve its own separate key exchange, and today's browsers probably connect to a dozen or more HTTPS servers just in the course of loading the new-tab page. (Hell, probably more than that when you factor in software-update checks, configurating syncing, etc...)

Yeah, just say no to system/session-wide key logging.

As a side-quest, I tried to print GIO_USE_TLS from the daemon to know what backend I'm using, but it seems this variable was never set since the get-env call returned NULL. So I still don't know the current backend. However, based on the discussion here and the other env-var in daemon.js, it seems likely to be GnuTLS.

Oh, yeah, that one's documented as a normally-unset variable that's only useful for test/debugging purposes. The default that's built in to glib-networking is, indeed, gnutls.

The question, really, is whether there are ANY options other than gnutls. I've seen some discussion around the 'net of possibly setting it to gnutls-pkcs11, but I can't find any evidence of there actually being any sort of gnutls-pkcs11 module, at least not anymore and/or not in Fedora 37. Unlike the equivalent qca-qt5-pkcs11 plugin for the Qt Cryptographic Architecture.

Heck, even the documented GIO_USE_TLS=help option that's supposed to dump a list of valid values for that envvar actually does nothing, and I'm beginning to suspect the reason is that it's working, but there's nothing to display because there are no other TLS options for Gio. We've had conversations in the past (none of which I can find right now) about how, while Gio/Gvfs were designed to be modular in the same way Kio is, in practice that hasn't really happened.

Much of the kdeconnect implementation of remote-file access is facilitated by the fact that, on the Linux side, they have a Kio plugin that adds their own kdeconnect: protocol scheme, with full control over the connection parameters. Many of the issues with SFTP in GSConnect come down to Gvfs' implementation not fitting particularly well with kdeconnect's, and us having very little control over that.

In theory having Gvfs/Gio module that implements a gsconnect: protocol would allow us to better match the KDE side of things, but at a minimum that would require a compiled module written in C, which would mean it couldn't be distributed with the extension. (And in practice, all of the protocols supported by Gvfs are distributed with Gvfs; its theoretical modularity hasn't really amounted to much in reality. Unlike on the KDE side, where Kio plugins are common — though, it has to be said, that's because they are compiled C++ libraries.)

Editorializing a bit, while people have good and bad opinions of C++ for all sorts of valid reasons, IMHO one of the clear advantages it has over straight C is the built-in support for classes and inheritance, which takes a lot of the tedium out of writing things like Kio modules. The kdeconnect Kio module is not that complex — the whole thing is just 250 lines of very readable code! I suspect that being able to throw together relatively quick implementations of things like that is why KDE's core modularity has been embraced more than on the GNOME side, where extensibility is focused on the JS and Vala side of things, and I've never heard a single person outside the core GNOME devs express any excitement, or even interest, when it comes to core system extensions like new Gvfs protocol modules.

[brianrho]

Yeah, I'm not much for C++ but having seen some of the stuff people do to emulate classes in C, I'll admit it's neat to have all that for free from your language/framework.

(Though I'm sure some would scoff, classes aren't needed in the first place -- "you're using the wrong abstraction!")

but there's nothing to display because there are no other TLS options for Gio

Yeah, if I understood that old discussion, they deliberately build glib-networking with support for only a single backend, GnuTLS, for the desktop, and reserve the additional OpenSSL support for developers or for embedded platforms that require it. So, that env-var is likely only usable on the latter setups, regardless of whether you have GnuTLS and OpenSSL libraries independently installed.

[ferdnyc]

*nod* Actually, I was wrong about (at least) one thing: At some point along the way, they decided that while gvfs is modular, it's NOT actually externally-extensible at all. (This feels like info I've discovered, and then forgotten again, at least three times.):

https://wiki.gnome.org/Projects/gvfs/doc

Writing your own backend

GVfs doesn't provide any public headers and the daemon d-bus protocol is considered private and may change any time (and that actually happened with the GDBus port). Out-of-tree backends are simply not supported, the preferred way is to fork/branch gvfs sources and write your backend on top of it. If you then send resulting patch to upstream developers, they'll be happy to review it for you for potential inclusion.

So, that puts it on entirely different footing than Kio, where kdeconnect can build and maintain their module completely independent of the main distribution.

[ferdnyc]

just like popular browsers do with SSLKEYLOGFILE

It's not the browsers that support that, it's the libraries. So it works with GSConnect (or anything else) as well.

[brianrho]

Aaaah, somehow all my searching didn't turn up this bit of info, maybe it's because I didn't search for SSLKEYLOGFILE by itself.

(Though, not sure why people didn't just suggest this as an answer in all those SO questions.)

Now, that I've tried that, it seems this is even on its way to becoming some RFC: https://www.ietf.org/id/draft-thomson-tls-keylogfile-00.html

[brianrho]

A note for anyone who wants to view the SSH/SFTP setup traffic that is generated when you attempt to Mount, for instance --

SSH uses TCP for transport and by default, Wireshark won't interpret the GSConnect TCP traffic as SSH traffic -- likely because the GSConnect ports are non-standard (as opposed to the popular SSH port 22).

So, you'll have to tell Wireshark manually -- Right-Click on any TCP packet you suspect is really carrying SSH. Select Decode As ....

In the new dialog, there should be a single row, with Field set to TCP Port. Under the Current column in that row, click on the cell to cause a dropdown to appear. Select SSH from that dropdown. Click OK to exit the dialog.

(No need to click Save since that may make your change persistent for this port, which would be pointless since the port is dynamically assigned, it doesn't always serve SSH.)

Wireshark should now interpret the SSH traffic.