Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
Mannitou opened this issue Apr 10, 2024 · 8 comments
Labels
bug Something isn't working invalid This doesn't seem right

Comments

@Mannitou
Copy link

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: #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)

2024-04-10_09-22-45

@Mannitou Mannitou added the bug Something isn't working label Apr 10, 2024
@totaam totaam transferred this issue from Xpra-org/xpra Apr 10, 2024
@totaam
Copy link
Collaborator

totaam commented Apr 10, 2024

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:

isFirefoxVersionSupported() {
var match = navigator.userAgent.match(/firefox\/(\d+)/i);
if (match && match[1]) {
var version = parseInt(match[1], 10);
return version >= 108;
}
return false;
},

@Mannitou
Copy link
Author

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
Copy link
Author

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
Copy link
Collaborator

totaam commented Apr 10, 2024

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
Copy link
Author

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
Copy link
Collaborator

totaam commented Apr 11, 2024

Please answer all the questions.

In particular: can you reproduce this without the proxy.

@Mannitou
Copy link
Author

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/;

@Mannitou Mannitou closed this as not planned Won't fix, can't repro, duplicate, stale Apr 11, 2024
@totaam
Copy link
Collaborator

totaam commented Apr 12, 2024

This is probably just a problem of cached files.

@totaam totaam added the invalid This doesn't seem right label Apr 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working invalid This doesn't seem right
Projects
None yet
Development

No branches or pull requests

2 participants