Context Navigation

← Previous Ticket
Next Ticket →

#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 ...

[tlaloc@jimador ~]$ 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:

[tlaloc@jimador ~]$  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 (3)

comment:1 Changed 6 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 place → clients 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 6 years ago by Antoine Martin (previous) (diff)

comment:2 Changed 6 years ago by alas

Resolution:	→ invalid
Status:	new → closed

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.