issue with Google Chrome and TLS proxy (Nginx or Apache) [not with Firefox] - client

[Mannitou]

Describe the bug I am trying to use my web browser to connect in https to a proxy server. This proxy server will rewrite the request xpra in websocket (ws) which is listening on the same machine with bind-tcp feature activated with all setting with default. The proxy server is working perfectly in HTTP with all browser. The browser to XPRA is working perfectly with all browser. In HTTPS, only Firefox is working without any console issue, but on Google chrome or Edge I have having this issue:

Client.js:1 Uncaught TypeError: self.set_encoding_option is not a function at XpraClient.initialize_workers (Client.js:1:10706) at XpraClient.connect (Client.js:1:10384) at init_page (xpra-obsidian/:1537:18) at xhr.onload (xpra-obsidian/:1670:11)
  | initialize_workers | @ | Client.js:1 -- | -- | -- | --   | connect | @ | Client.js:1   | init_page | @ | xpra-obsidian/:1537   | xhr.onload | @ | xpra-obsidian/:1670   | load (asynchrone) |   |     | load_default_settings | @ | xpra-obsidian/:1660   | (anonymes) | @ | xpra-obsidian/:1694   | mightThrow | @ | jquery.js:3764   | process | @ | jquery.js:3832   | setTimeout (asynchrone) |   |     | (anonymes) | @ | jquery.js:3870   | fire | @ | jquery.js:3498   | fireWith | @ | jquery.js:3628   | fire | @ | jquery.js:3636   | fire | @ | jquery.js:3498   | fireWith | @ | jquery.js:3628   | ready | @ | jquery.js:4108   | completed | @ | jquery.js:4118

To Reproduce Steps to reproduce the behavior:

1. install xpra
2. install apache2 in proxy mode Apache-Proxy.md
3. configure apache2 in TLS with a certificate
4. launch xpra start --bind-tcp
5. start chrome and go in https to the apache2 address "https://www.myserver.com/xpra-obsidian/"
6. the browser with be block at the connection step : "www.myserver.com:/xpra-obsidian/ with ssl"
7. The browser Google Chrome will never start the next step: "wss://www.myserver.com:/xpra-obsidian/" but Firefox will continue.

I would like that chrome is acting like Firefox and start websocket connection upgrade. Chrome with working before. I suspect a recent incompatibility between chrome and XPRA.

Maybe link to this bug: https://github.com/Xpra-org/xpra-html5/issues/287 ?

System Information (please complete the following information):

• Server OS: Linux Debian
• Client OS: Windows or Linus
• Xpra Server Version 12.0 beta
• Xpra Client Version 12.0 beta (from the HTML of the server)

[totaam]

I don't think that the proxy is relevant to this ticket, is it? You could just add your SSL certificate to the xpra server and simplify this setup quite a bit - much easier to reproduce that way. I've just tried it without the proxy and a self-signed cert, it worked fine in google chrome beta 124.0.6367.18. Is your proxy configuration identical to the one from the documentation?

---

What version of Firefox are you testing with? Do you see the offscreen canvas is not supported with this version of Firefox message in the javascript console?

Yes, it's likely that the offscreen worker is the problem, as this is disabled in some Firefox versions, so it won't go through the set_encoding_option line: https://github.com/Xpra-org/xpra-html5/blob/085e0df8fde96ca96611932d33ee93577221e6a8/html5/js/OffscreenDecodeWorkerHelper.js#L27-L34

[Mannitou]

I downgrade the package xpra-html5 to the version 8.1-r9-1. And now it is working with all browser and without changing any configuration on the proxy.

@totaam : I test with firefox 124.0.1 (64-bit)

[Mannitou]

after I switch back to the version xpra-html5 (13-r1543-1).

I can see that in Firefox. I having this message about canva:

offscreen canvas is not supported with this version of Firefox OffscreenDecodeWorkerHelper.js:1:659
we can use websocket in webworker Utilities.js:1:11779
we can decode using a worker:

[totaam]

xpra-html5 to the version 8.1-r9-1

The code that triggers the problem is more recent that that.

offscreen canvas is not supported with this version of Firefox

As expected.

Please answer all the questions.

[Mannitou]

please find the nginx.conf:

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}
server {
    listen [::]:443 ssl http2;
    listen 443 ssl http2; 

    server_name www.myserver.com;

    root  /var/www/html/nginx;

    #sendfile        on;

    ssl_certificate /etc/letsencrypt/live/fullchain.pem;
    ssl_certificate_key  /etc/letsencrypt/privkey.pem;
    ssl_prefer_server_ciphers on;

    # Ensure this line points to your dhparams file
        ssl_dhparam /etc/nginx/ssl/dhparams.pem;

        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
        ssl_session_cache shared:SSL:10m;

    location /xpra-obsidian {
            auth_basic "Restricted Content";
            auth_basic_user_file /etc/nginx/.htpasswd;

            proxy_pass http://10.0.0.1:4443;

            proxy_http_version 1.1;
            proxy_buffering off;
            proxy_cache_bypass $http_upgrade;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "Upgrade";
                proxy_set_header Host $host;
            proxy_ssl_verify off;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header SERVER_PORT $server_port;
            proxy_set_header REMOTE_ADDR $remote_addr;
        }
}

[totaam]

Please answer all the questions.

In particular: can you reproduce this without the proxy.

[Mannitou]

Without the proxy in https, I can connect to xpra directly with the browser even with my own certificate or an autogenerate one.

What is strange is at the time, I arrived at the point that on the same proxy and with chrome 1 xpra application was working and an another was not working. I didn't have any issue with Firefox to access both application. I controlled the setting in Nginx and both setting was exactly same. I even restart nginx service. The version of the package xpra-html5 was (13-r1543-1). Without any effect. As soon as, I reboot the the xpra which was blocked at the step 6: "www.myserver.com:/xpra-obsidian/ with ssl" with chrome. The situation was unlock.

Did you any change between on xpra-html5 between "8.1-r9-1" and "10.1-r10-1 and later" which can cause this bug?

I also made this modification in the nginx.conf:

Replace :
proxy_pass http://10.0.0.1:4443;
by:
proxy_pass http://10.0.0.1:4443/;

[totaam]

This is probably just a problem of cached files.