Trouble debugging a proxied connection

[ydirson]

I'm trying to setup a connection on a QubesOS system between KeePassXC in one VM and Firefox in another. Such a setup has been described in the QubesOS forum, using keepassxc-proxy and ncat (or socat) to bridge to QubesOS' inter-VM communication system.

The lack of debugging logs does not help, but from what I'm seeing when asking ncat to dump the traffic, looks like a success reply to the initial change-public-keys request gets propagated back to the unix socket on client side, but the Firefox plugin complains "Message encryption failed".

One thing that looks fishy in the exchange dump, though, is on client side I can see 3 requests, while only one is visible on server side - apparently due to the time needed to manually accept the connection request. Removing user interaction seems to allows the client side to accept the initial reply, but then only a couple of exchanges occur, without no visible change for the user:

{"action":"change-public-keys","publicKey":"...","nonce":"...","clientID":"..."}
{"action":"change-public-keys","nonce":"...","publicKey":"...=","success":"true","version":"2.6.2"}
{"action":"get-databasehash","message":"...","nonce":"...","clientID":"..."}
{"action":"get-databasehash","message":"...","nonce":"..."}
{"action":"get-databasehash","message":"...","nonce":"...","clientID":"..."}
{"action":"get-databasehash","message":"...","nonce":"..."}

How can we be sure what's happening ? Would it be acceptable to make the plugin more tolerant to slow response ?

[EDIT] I was really able after several attempts to get a connection working in the end when no user interaction gets the way at the Qubes level. It could still be useful for the paranoid kind to be able to activate that additional confirmation, since KeePass is not able to tell which VM is the origin of the request in such a setup.