xpra icon
Bug tracker and wiki

Opened 4 years ago

Closed 4 years ago

#1006 closed defect (invalid)

clients not working with first packet encryption enabled

Reported by: alas Owned by: alas
Priority: major Milestone: 0.16
Component: server Version: 0.16.x
Keywords: Cc:

Description

Running with osx client 0.16.0 r10828 against a fedora 21 0.16.0 r10854 server, when I start a session with ...

XPRA_CRYPTO_INITIAL_PADDING="PKCS#7" XPRA_ENCRYPT_FIRST_PACKET="1" dbus-launch xpra start :13 --no-daemon --bind-tcp=0.0.0.0:2200 --start-new-commands=yes --start-child=xterm --start-child=xterm --html=on --sharing --password-file=password --encryption-keyfile=key --encryption=AES 

... and I'm then foolish enough to try to pull any xpra info, I have no luck ...

[[email protected] ~]$ xpra info :13 --password-file=password --encryption-keyfile=key --encryption=AES
receiving data using AES encryption
disconnect: unencrypted packet dropped

... and the server's output...

2015-10-15 16:50:20,148 New unix-domain connection received on /home/tlaloc/.xpra/jimador.spikes.eng-13
2015-10-15 16:50:20,150 receiving data using AES encryption
2015-10-15 16:50:20,197 New unix-domain connection received on /home/tlaloc/.xpra/jimador.spikes.eng-13
2015-10-15 16:50:20,198 receiving data using AES encryption
2015-10-15 16:50:20,262 Connection lost
2015-10-15 16:50:20,262 Disconnecting client '/home/tlaloc/.xpra/jimador.spikes.eng-13':
2015-10-15 16:50:20,262  unencrypted packet dropped
2015-10-15 16:50:20,263 Connection lost
  • Meanwhile, if I launch with:
[[email protected] ~]$  dbus-launch xpra start :13 --no-daemon --bind-tcp=0.0.0.0:2200 --start-new-commands=yes --start-child=xterm --start-child=xterm  --password-file=password --encryption-keyfile=key --encryption=AES 

... all works as hoped.

Change History (2)

comment:1 Changed 4 years ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Summary: xpra info not working with PKS#7 Padding & First Packet Encryption in placeclients not working with first packet encryption enabled

Edited bug title: this has nothing to do with PKCS#7 or xpra info: you get the same results with "xpra attach" (or any other client subcommand), and with different a padding scheme.

And this is really not a bug: the point of XPRA_ENCRYPT_FIRST_PACKET being disabled by default is that it is a backwards incompatible change.

This works:

XPRA_CRYPTO_INITIAL_PADDING="PKCS#7" XPRA_ENCRYPT_FIRST_PACKET="1" \
    xpra start :13 \
        --auth=file --password-file=password.txt \
        --encryption=AES --encryption-keyfile=aes.txt

XPRA_CRYPTO_INITIAL_PADDING="PKCS#7" XPRA_ENCRYPT_FIRST_PACKET="1" \
    xpra info :13 \
        --auth=file --password-file=password.txt \
        --encryption=AES --encryption-keyfile=aes.txt

Please also note how the commands above do not include arguments that are not relevant to this bug: daemon, bind-tcp, start-new-commands, multiple start-child, html, sharing.

@afarr: please close unless I am missing something.

Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 4 years ago by alas

Resolution: invalid
Status: newclosed

Ahh... didn't think of the use of the environment variables, for some reason (and I'll take more care to pare out the probably irrelevant command details).

I don't see anything you missed either. Closing.

Note: See TracTickets for help on using tickets.