Closed totaam closed 4 years ago
Thanks, the wiki page was out of date - this syntax used to work as a fallback but it no longer does.
It has now been updated - this fixes the tcp-auth
setting.
FYI, in v4, the newer syntax (#1160) aims to prevent this sort of confusion, use:
--bind-tcp=0.0.0.0:10000,auth=file:filename=password.txt
As for AES, I will look into it.
Thank you for the quick update! #1160 syntax looks much better.
I tried the option
--bind-tcp=0.0.0.0:10000,encryption=AES,encryption-keyfile=./key.txt
which I found in #1160 but it seems to be completely ignored.
I tried the option .. but it seems to be completely ignored.
The html5 client is ignoring the encryption options because some bugs were introduced in a recent version (r26569 and others) - that's what I need to fix for this ticket.
Connecting with a python client should work, ie:
xpra attach tcp://192.168.0.10:10000 --encryption=AES --encryption-keyfile=./aes.txt
(the client syntax for encryption will be improved soon too: #2794)
The server should reject your html5 client connection - it does for me - with this message:
Warning: authentication failed
missing encryption tokens
The fix for websockets not honouring encryption options is in r26591.
(one could conceivably use SSL and AES at the same time by overriding XPRA_ENCRYPTED_SOCKET_TYPES
and enabling it for ssl
and wss
sockets - though I don't really see the point of doing that.
This will be included in the next stable update.
I think we can close this ticket, feel free to re-open if you still encounter issues, and thanks for reporting it!
Hit some more issues during testing.
I understand that you're still working on this. I appreciate that. I'm just adding my experience.
I made the changes in r26591 on the server. I started it with
--bind-ws=0.0.0.0:4430,encryption=AES,encryption=aes.txt
. Using the Python client with--encryption=AES --encryption-keyfile=./aes.txt
I get an authenticated connection but then it hangs.server:
2020-06-04 13:45:54,855 sending data using AES encryption 2020-06-04 13:45:54,857 receiving data using AES encryption 2020-06-04 13:45:54,857 Authentication required by password authenticator module 1 2020-06-04 13:45:54,857 sending challenge for username 'kyler' using hmac+sha512 digest 2020-06-04 13:47:54,862 Error: connection timed out: ws socket: 10.0.0.164:4430 <- xxx.xxx.xxx.xxx:10976 2020-06-04 13:47:54,864 Warning: failed to query SO_RCVLOWAT, SO_REUSEPORT 2020-06-04 13:47:54,864 Warning: failed to query TCP_MAXSEG
client:
2020-06-04 08:46:45,931 Xpra GTK3 X11 client version 4.0.1-26379 64-bit 2020-06-04 08:46:46,091 running on Linux Ubuntu 18.04 bionic 2020-06-04 08:46:46,092 window manager is 'GNOME Shell' 2020-06-04 08:46:46,126 Warning: failed to import opencv: 2020-06-04 08:46:46,126 No module named 'cv2' 2020-06-04 08:46:46,127 webcam forwarding is disabled 2020-06-04 08:46:46,545 GStreamer version 1.14.5 for Python 3.6.9 64-bit 2020-06-04 08:46:46,720 No OpenGL_accelerate module loaded: No module named 'OpenGL_accelerate' 2020-06-04 08:46:46,914 Warning: vendor 'Intel Open Source Technology Center' is greylisted, 2020-06-04 08:46:46,915 you may want to turn off OpenGL if you encounter bugs 2020-06-04 08:46:46,966 OpenGL enabled with Mesa DRI Intel(R) HD Graphics 5500 (Broadwell GT2) 2020-06-04 08:46:47,316 receiving data using AES encryption 2020-06-04 08:48:47,445 Connection lost
AES certainly seems to be working. If I don't use it on the client, I get "missing encryption tokens". If I use it with a different key, I get an Exception in parse_ws_frame().
I understand that you're still working on this.
I believe the fix is in r26614. I am just testing now.
Almost identical to #2431.
AES
packets are padded to the next 32-byte boundary (that's just how CBC mode operates) and when authentication is enabled, this will be used on the challenge
packets, before we get a chance to parse the hello
packets fully, before we can disable legacy compatibility mode.
And legacy mode was buggy with padded packets (must have been broken since #2121): the xpra header uses the non-padded packet size, but websocket framing requires the full packet size. (this explains why the browsers were failing to parse websocket frames)
For trunk: r26614 just disabled legacy mode, and then r26615 removed it entirely.
For v4 and v3 backports, I used a less disruptive solution: 26616 fixes the headers without removing the legacy mode.
@kylerlaird: please close if that works for you.
I've tested the wiki examples with browsers, python client with ws://localhost:10000/
connection URIs, all with and without AES, with and without authentication.
r26617 also helps?
No, hits another bug later, workaround applied as per #2799.
I checked out the code from svn and made that. I copied it to the server and ran my AES test. When I attempt to connect, the server flags "unsupported cipher".
I'd be happy to try a package.
My mistake; previous libraries were used in my earlier testing. I removed them all to ensure that the fresh ones were used.
It works from Python client. Using the HTML5 client, I briefly see the desktop (with an xterm) but then it dies.
I see this on the server.
2020-06-04 14:32:26,696 Warning: AES decryption failed: invalid padding 2020-06-04 14:32:26,696 Error: AES encryption padding error - wrong key? 2020-06-04 14:32:26,698 xpra client 3 disconnected. 2020-06-04 14:32:27,985 Warning: authentication failed 2020-06-04 14:32:27,986 missing encryption tokens 2020-06-04 14:32:28,988 Disconnecting client 127.0.0.1:57884: 2020-06-04 14:32:28,988 missing encryption tokens
On the browser, it says "You were disconnected for the following reason: missing encryption tokens"
Very promising!
I made my own version of index.html, with encryption and key hardcoded.
Again, the xterm displays beautifully...for a moment.
hello capabilities Object { version: "4.1", "build.revision": "26619", "build.local_modifications": "0", platform: "Posix", "platform.name": "Posix", "platform.processor": "Linux x86_64", "platform.platform": "5.0 (X11)", "session-type": "Firefox", "session-type.full": "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0", namespace: true, … } Utilities.js:1:557 connection-lost Utilities.js:1:557 audio-state: stopped Utilities.js:1:557 connection closed: missing encryption tokens 2 Utilities.js:1:557 The connection to ws://localhost:4430/kyler.html was interrupted while the page was loading. Protocol.js:1:1643
I just now noticed this on the server. It seems more relevant:
2020-06-04 14:55:00,497 Warning: AES decryption failed: invalid padding 2020-06-04 14:55:00,498 Error: AES encryption padding error - wrong key? 2020-06-04 14:55:00,499 xpra client 9 disconnected. 2020-06-04 14:55:01,850 Warning: authentication failed 2020-06-04 14:55:01,851 missing encryption tokens 2020-06-04 14:55:02,852 Disconnecting client 127.0.0.1:59224: 2020-06-04 14:55:02,853 missing encryption tokens
It works from Python client. Using the HTML5 client, I briefly see the desktop (with an xterm) but then it dies.
I have just re-tested from a fresh checkout, using trunk, 3.0.x and 4.0.x branches and then following the exact steps from the wiki Clients HTML5:
PASSWORD=YOURPASSWORD
AES_KEY=0123456789ABCDEF
echo -n $PASSWORD > password.txt
echo -n $AES_KEY > aes.txt
xpra start :10 --bind-tcp=0.0.0.0:10000 --html=on --start=xterm \
--tcp-auth=file:filename=./password.txt \
--tcp-encryption=AES --tcp-encryption-keyfile=`pwd`/aes.txt
sleep 5
xdg-open "http://localhost:10000/index.html?username=$USER&password=$PASSWORD&encryption=AES&key=$AES_KEY"
Works for me every time.
Please provide more details on your steps so that I can reproduce. Maybe you forgot to clean the html5 installation before installing from source, then the code actually used might be a mix of your old and new build.
Thanks for the new package! I was having a heck of a time building and installing xpra from source.
Using 4.0.2 and the example in the AES section of https://xpra.org/trac/wiki/Clients/HTML5, I get this from the server:
2020-06-05 06:57:54,782 sending data using AES encryption 2020-06-05 06:57:54,785 receiving data using AES encryption 2020-06-05 06:57:54,785 Authentication required by password file authenticator module 1 2020-06-05 06:57:54,785 sending challenge for username 'kyler' using hmac+sha512 digest 2020-06-05 06:57:54,858 Error: error in network packet reading/parsing 2020-06-05 06:57:54,858 initializer for ctype 'unsigned char *' must be a cdata pointer, not memoryview Traceback (most recent call last): File "/usr/lib/python3/dist-packages/xpra/net/protocol.py", line 801, in _read_parse_thread_loop self.do_read_parse_thread_loop() File "/usr/lib/python3/dist-packages/xpra/net/protocol.py", line 929, in do_read_parse_thread_loop data = self.cipher_in.decrypt(data) File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/base.py", line 149, in update return self._ctx.update(data) File "/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl/ciphers.py", line 120, in update n = self.update_into(data, buf) File "/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl/ciphers.py", line 135, in update_into data, len(data)) TypeError: initializer for ctype 'unsigned char *' must be a cdata pointer, not memoryview 2020-06-05 06:58:01,022 Warning: authentication failed 2020-06-05 06:58:01,023 missing encryption tokens 2020-06-05 06:58:02,025 Disconnecting client 127.0.0.1:47836: 2020-06-05 06:58:02,026 missing encryption tokens
If I remove the password requirement, I get this:
2020-06-05 07:01:09,114 sending data using AES encryption 2020-06-05 07:01:09,119 receiving data using AES encryption 2020-06-05 07:01:09,119 Handshake complete; enabling connection 2020-06-05 07:01:09,338 HTML5 Posix Firefox client version 4.0.2-26625 2020-06-05 07:01:09,339 as 'kyler' 2020-06-05 07:01:09,345 setting keyboard layout to 'us' 2020-06-05 07:01:09,464 client root window size is 1136x648 with 1 display: 2020-06-05 07:01:09,464 HTML (301x171 mm - DPI: 95x96) 2020-06-05 07:01:09,464 Canvas 2020-06-05 07:01:09,504 server virtual display now set to 1088x640 (best match for 1136x648) 2020-06-05 07:01:09,662 Error: error in network packet reading/parsing 2020-06-05 07:01:09,663 initializer for ctype 'unsigned char *' must be a cdata pointer, not memoryview Traceback (most recent call last): File "/usr/lib/python3/dist-packages/xpra/net/protocol.py", line 801, in _read_parse_thread_loop self.do_read_parse_thread_loop() File "/usr/lib/python3/dist-packages/xpra/net/protocol.py", line 929, in do_read_parse_thread_loop data = self.cipher_in.decrypt(data) File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/base.py", line 149, in update return self._ctx.update(data) File "/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl/ciphers.py", line 120, in update n = self.update_into(data, buf) File "/usr/lib/python3/dist-packages/cryptography/hazmat/backends/openssl/ciphers.py", line 135, in update_into data, len(data)) TypeError: initializer for ctype 'unsigned char *' must be a cdata pointer, not memoryview
TypeError: initializer for ctype 'unsigned char *' must be a cdata pointer, not memoryview
The version of python-cryptography in Ubuntu Bionic is too old (2.1.4): python3-cryptography to support memoryview
s.
As per this comment: As of cryptography 2.5 we support the buffer protocol for many key inputs (and we have update_into in symmetric cryptography to write into a rw buffer).
The quick fix would be to call our helper function memoryview_to_bytes
, but this would penalize (adding an extra memory copy every time) all the other distributions that ship with a more recent version of the library.
So I will make a patch and apply it selectively only on the distros that need it.
In the meantime, you can try replacing:
data = self.cipher_in.decrypt(data)
with:
data = self.cipher_in.decrypt(memoryview_to_bytes(data))
It works!!! I appreciate that you not only explained the dependency but also gave a quick workaround.
I am integrating this into a big project. Being able to use shared keys instead of certificates will simplify it immensely.
Xpra feels like a niche project, not getting nearly the coverage of VNC. My every interaction with it, however, screams of high quality. I am delighted that I chose to depend on it for this project.
Thank you, Antoine. I see only a sliver of your workload but the grace and competence you bring to it are marvelous.
I see only a sliver of your workload but the grace and competence you bring to it are marvelous.
Thank you very much!
A nicer solution has been merged in r26631 and will be in the next stable update.
So...it turns out that I do need to use AES over SSL, as mentioned in comment:4. I can set
ENCRYPTED_SOCKET_TYPES=wss
and use--bind-wss=0.0.0.0:1234,encryption=AES,encryption-keyfile=/tmp/aes.txt
but the AES encryption appears to be ignored.
it turns out that I do need to use AES over SSL ...
--bind-wss=0.0.0.0:1234,encryption=AES,encryption-keyfile=/tmp/aes.txt
This works for me, I've tested both with 4.1 beta and 4.0.
Maybe try the legacy syntax form:
XPRA_ENCRYPTED_SOCKET_TYPES=wss xpra start --start=xterm --no-daemon -d auth,crypto,http \
--bind-wss=0.0.0.0:10000 --wss-auth=file:filename=./password.txt \
--tcp-encryption=AES --tcp-encryption-keyfile=`pwd`/aes.txt \
--ssl-cert=./ssl-cert.pem
I can connect with:
xpra attach wss://127.0.0.1:10000/ --tcp-encryption=AES --tcp-encryption-keyfile=aes.txt -d auth,crypto --ssl-server-verify=none
Or with the browser:
xdg-open "https://127.0.0.1:10000/index.html?username=$USER&password=$PASSWORD&encryption=AES&key=$AES_KEY"
If that still fails, please post the server debug output (with -d auth,crypto,http
as above) and keep an eye on your browsers console log, which may have more information.
That solution works for me! I'm working again.
Thank you!
FYI: in 4.1 you can now use the nicer syntax:
xpra attach tcp://user:password@127.0.0.1:10000/keydata=0123456789ABCDEF
See #2794#comment:2 for details.
FYI: the new javascript rencoder https://github.com/Xpra-org/xpra-html5/issues/84 works with AES and LZ4.
See also: ecf5782f751f1768e64e51d035325d110369d549
From now on, encryption can be enabled simply with the per-socket options without having to set XPRA_ENCRYPTED_SOCKET_TYPES
for wss
or ssl
sockets.
Issue migrated from trac ticket # 2793
component: html5 | priority: critical | resolution: fixed
2020-06-01 16:45:06: kylerlaird created the issue