AES key prevents HTML5 client from loading SSL-protected websockets

[basilgello]

@totaam Regardless of "Secure Sockets" turned on, connection ends with "no key specified for encryption".

The issue is here: https://github.com/Xpra-org/xpra-html5/blob/master/html5/connect.html#L584

Also, check sequential clicking of "AES" -> "Secure Sockets" -> "AES"... and you'll see inconsistency in interface pane toggling.

[basilgello]

Fix:

diff --git a/html5/connect.html b/html5/connect.html
index b5291e7..7e39756 100644
--- a/html5/connect.html
+++ b/html5/connect.html
@@ -565,6 +565,7 @@ function fill_form(default_settings) {
        aes_input.onchange = function() {
                if (aes_input.checked) {
                        ssl_input.checked = false;
+                       ssl_input.onchange();
                        $('select#encryption').show();
                        $('img#toggle-key').show();
                        $('span#aes-label').hide();
@@ -587,6 +588,7 @@ function fill_form(default_settings) {
                if (enc=="AES") {
                        if (!ssl) {
                                aes_input.checked = true;
+                               aes_input.onchange();
                        }
                        let enc_mode = encryption.split("-")[1] || "CBC";
                        document.getElementById("encryption").value = "AES-"+enc_mode;
@@ -620,6 +622,7 @@ function fill_form(default_settings) {
                        if (ssl_input.checked) {
                                $('span#insecure-span').hide();
                                aes_input.checked = false;
+                               aes_input.onchange();
                        }
                        else {
                                $('span#insecure-span').show();
@@ -632,6 +635,7 @@ function fill_form(default_settings) {
                ssl_input.onchange = function() {
                        if (ssl_input.checked) {
                                aes_input.checked = false;
+                               aes_input.onchange();
                                $('span#encryption-key-span').hide();
                        }
                }
diff --git a/html5/js/Client.js b/html5/js/Client.js
index 00d8d14..d40d2a6 100644
--- a/html5/js/Client.js
+++ b/html5/js/Client.js
@@ -375,7 +375,7 @@ XpraClient.prototype.connect = function() {
        this.on_connection_progress("Connecting to server", details, 40);
        // open the web socket, started it in a worker if available
        // check we have enough information for encryption
-       if(this.encryption) {
+       if(this.encryption && (!this.ssl) && (!this.insecure)) {
                if((!this.encryption_key) || (this.encryption_key == "")) {
                        this.callback_close("no key specified for encryption");
                        return;
@@ -1195,7 +1195,7 @@ XpraClient.prototype._make_hello_base = function() {
                "clipboard.preferred-targets" : this.clipboard_targets,
        });

-       if(this.encryption) {
+       if(this.encryption &&(!this.ssl) && (!this.insecure)) {
                const enc = this.encryption.split("-")[0];
                if (enc!="AES") {
                        throw "invalid encryption specified: '"+enc+"'";

[totaam]

Ah. Dang. I've applied your fixes without really testing them, with one change: (!this.insecure) should not be relevant for deciding when to use encryption. This flag is for sending unencrypted password data.

Funny how I had assumed that some_element.checked = Bool would trigger the onchange event..

I'll probably re-spin the packages without a version bump.

[basilgello]

Unfortubately, we still need an explicit AES checkbox value to be considered in client.js If you try connecting HTML5 client to Xpra server via HTTP/WS with AES checkbox turned off, you will not be able to do so.

[totaam]

Unfortubately, we still need an explicit AES checkbox value ...

I'm not sure what you mean or what version you are testing. The following fixes were needed: 5f425f5dfc7439c1673e7eaf3c0f1c4d06bc804c, a5f7b8d326ebe2e06ef694ebb67cbf8b0a5826bf, e6f3d515cad8c0f216075b47462b8701ad13f193. I was going to release 4.4.1 with these fixes but then I managed to sneak in #96 so I will probably release 4.5 with that instead.

[basilgello]

oh la la… It is good approach but one might need to specify user name too if first login attempt failed. Also, attempting to connect the latest HTML5 client to existing Xpra session ends with big password prompt where I can type nothing, and pressing OK errors out with "unsupported digest xor". message. Do I need to update Xpra server, too?

EDIT: Restarting Xpra server solved login issue for me. However, did I propose the following improvement?

Since you resolved #96, can we also request authentication on Xpra seamless/shadow server side not once but configurable number of times? Typically 2 or 3. Also I want to implement the "socket name" Xpra option which instructs Xpra to open socket with a predefined name.

Why might one need it? Consider Xpra proxy server capable of launching seamless and shadow Xpra servers. The end user wants to spin the Xpra server with different credentials (for example, inside a container) and access it via central proxy interface. Now, the proxy server passes down the credentials retrieved from user to seamless or shadow server, and drops connection if that downstream server rejected authentication. What I want to achieve is as follows: first, proxy server passes authentication to the downstream server as usual, and if the downstream server rejects it, the proxy server asks the end user the second username/password that might satisfy the downstream server.

Once authentication passes are separated for proxy server and downstream Xpra servers, the --socket-name improvement can be trivially used to accomplish seamless integration of cintainerized Xpra servers into proxy server, just like:

podman run --rm --env XPRA_SOCKET_NAME=test-0 -v $HOME/.xpra/test-0:/home/xpra/.xpra/test-0 xpra-container:latest

and doing xpra lust on host side.

[totaam]

but one might need to specify user name too if first login attempt failed

You should get sent back to the connect page where you can do that. Doing more complicated things could be added later.

attempting to connect the latest HTML5 client to existing Xpra session ends with big password prompt where I can type nothing...

What's your browser? Version?

and pressing OK errors out with "unsupported digest xor"

What is your server command line? In particular the authentication bit.

Do I need to update Xpra server, too?

No.

[basilgello]

@totaam I updated my previous answer, sorry :)

[basilgello]

You should get sent back to the connect page where you can do that.

No you can not if Xpra seamless server was started with different authentication mode than the proxy one. I.e how do you connect via proxy server if you started your Xpra server as follows:

xpra start --start=firefox --env=password:xpra

?

[totaam]

can we also request authentication on Xpra seamless/shadow server side not once but configurable number of times? Typically 2 or 3.

This is going to require both client and server changes. Please create a new issue for this and link back here and #96

Also I want to implement the "socket name" Xpra option which instructs Xpra to open socket with a predefined name

Can't you already do that with --bind=/path/to/asocketname?

Once authentication passes are separated for proxy server and downstream Xpra servers..

OTOH, the python client already supports multiple authentication challenges. The html5 client does not. This should be added first. (and it would be a good time to add U2F, etc) "All" that would be needed then would be to forward challenges through the proxy.

No you can not if Xpra seamless server was started with different authentication mode than the proxy one

OK. So you're going through the proxy. The way it works at the moment is that the proxy handles the authentication to the backend server.

[Jonas-Metzger]

does this disallow using both aes and ssl at the same time? That would be very unfortunate! In my application, I'd like to use ssl such that the browser does not flag the connection as insecure (basically for cosmetic reasons only). To minimize costs, I would only have one ssl cert used by multiple xpra servers. But to guarantee security in this setting, it is important that each uses separate aes secrets. So I would like to use both aes and ssl. Can we make that work?

[totaam]

does this disallow using both aes and ssl at the same time?

@Jonas-Metzger It did. I'm not sure exactly when AES and SSL became mutually exclusive. The two commits above should allow you to enable both AES and SSL and do this through the connect dialog. On the server side, you need to use the syntax documented here: https://github.com/Xpra-org/xpra/issues/2793#issuecomment-765546649 to enable AES on SSL sockets.

[Jonas-Metzger]

@totaam Super cool! Thanks so much for your awesome work, really appreciate it.

[open-contracts]

@totaam @Jonas-Metzger Client side works, but unfortunately the server does not seem to take into account the AES flags. I get:

2021-10-07 04:07:30,962 Warning: authentication failed
2021-10-07 04:07:30,963  the server does not support encryption on this connection
2021-10-07 04:07:31,965 Warning: the python netifaces package is missing
2021-10-07 04:07:31,967 Disconnecting client 127.0.0.1:54820:
2021-10-07 04:07:31,968  the server does not support encryption on this connection

On the server side, and something similar on the client side.

Here is my command:

xpra start :0 --daemon=no --start-child=[some cmd] --bind-wss=127.0.0.1:14500,encryption=AES,encryption-keyfile=key.txt,ssl-cert=ssl_cert.pem,ssl-key=ssl_key.pem,ssl-ca-certs=ca_cert.pem

Disabling AES but having SSL enabled on the client side connects to this server.

[totaam]

but unfortunately the server does not seem to take into account the AES flags

@open-contracts See https://github.com/Xpra-org/xpra/issues/2793#issuecomment-765546649 TLDR:

xpra start --env=ENCRYPTED_SOCKET_TYPES=tcp,ws,wss,ssl ...

Or upgrade to https://github.com/Xpra-org/xpra/commit/ecf5782f751f1768e64e51d035325d110369d549 or later.

[totaam]

Works-for-me(tm)