xpra icon
Bug tracker and wiki

Opened 5 years ago

Closed 2 years ago

Last modified 22 months ago

#584 closed enhancement (wontfix)

Implementation of API for crypto modules

Reported by: Benoit Gschwind Owned by: Antoine Martin
Priority: minor Milestone: 2.0
Component: core Version: trunk
Keywords: Cc:

Description

The state encrypted connection is not rely know but discussion was started on #198, but at the moment Xpra seems to define a proper API to include modules that can encrypt connections.

This ticket intend to be fixed before implementing new crypto modules

Change History (5)

comment:1 Changed 5 years ago by Benoit Gschwind

At the moment in #198, mvrable proposed a patch that separate encryption module from the core protocol which seems to be a good way to implement encryption.

At the moment I imagine the following protocol for establishing encrypted connection:

  • the client start a connection to the server
  • the client send hello message with a list of desired encryption module from preferred one to lest preferred.
  • the server select the most favorite encryption module that the client wish from the list of encryption module it support.
  • the server return a message to inform the client to start encryption negotiation with the selected encryption module
  • the client and the server communicate in some way (the encryption is called to do so). At this step an authentication may be required.
  • when the client and the server are agree, all next messages are encoded/decoded using the encryption modules. The encryption module can encapsulate messages in the way the want.

Maybe, we have to include some message that allow the encryption module to discuss to change some encryption parameters, for example temporary encryption keys.

Taking in account this step we may implement an API.

Best regards

comment:2 Changed 4 years ago by Antoine Martin

Notes:

  • please also see ticket:614#comment:2, this work should allow one to disable crypto completely. So that if the user does not wish to use crypto, no packets should ever trigger any crypto code to be called
  • see ticket:198#comment:25
Last edited 4 years ago by Antoine Martin (previous) (diff)

comment:3 Changed 3 years ago by Antoine Martin

See also #876 and #1029

comment:4 Changed 2 years ago by Antoine Martin

Resolution: wontfix
Status: newclosed

Superseded by #1252.
The next release will scale back on the crypto modules too and drop support for pycrypto. (which looks totally unmaintained)

comment:5 Changed 22 months ago by Antoine Martin

Milestone: future2.0

2.0 removed support for pycrypto and only supports python-cryptography, see r14512

Note: See TracTickets for help on using tickets.