[Core] Implement SSL peers support

[rcarpa]

This feature is interesting when multiple deluge instances are managed by the same administrator who uses it to transfer private data across a non-secure network.

A separate port has to be allocated for incoming SSL connections from peers. Libtorrent already supports this. It's enough to add the suffix 's' when configuring libtorrent's listen_interfaces. Implement a way to activate listening on an SSL port via the configuration.

To actually allow SSL connection between peers, one has to also configure a x509 certificate, private_key and diffie-hellman for each affected torrent. This is achieved by calling libtorrent's handle->set_ssl_certificate. The certificates are only kept in-memory, so they have to be explicitly re-added after each restart. Implement two ways to set these certificates:

• either by putting them in a directory with predefined names and letting deluge set them when receiving the corresponding alert;
• or by using a core api call.

[rcarpa]

Some core-functions added in this PR rely on a pending PR in libtorrent to expose the needed function in the python bindings: arvidn/libtorrent#7509 . So will be available in the next libtorrent release the earliest. Is there any convention on how to handle cases of requiring a specific libtorrent version for functions which are not required for normal deluge operation, but may be useful for some users?

[cas--]

This should be a useful addition, I've added comments for changes and happy to hear your thoughts on how you expect the feature to be used.

If possible it would be quite nice to have some tests.

[cas--]

This should be log.error and if the exception message is useful then it should also be included.

[cas--]

I'm not sure about having this as an exported method since it requires prior knowledge of the server setup and to me indicates this should be just an internal implementation.

We should also avoid exposing libtorrent implementation details and instead look at what the end-user needs for exported methods. This also applies to naming, so this method it should really be named set_ssl_torrent_cert.

I would consider the simplest option to have one core method accept cert, private key and DH param which are stored to the default SSL cert location for the daemon.

If really need the cert storage could be controlled by an optional parameter if the certs only want to be retained in memory but would that even be a use-case??

[cas--]

For naming of this feature we should use the more common term 'SSL Torrents' that end-users are more likely to know and use. I would also prefer that we keep with the existing layout for config, partially since our validator doesn't parse nested dicts.

For the random port option we could simplify it so that the SSL random port is listen_random_port + 1.

This narrows our set to just three config options:

Suggested change

	'ssl_peers': {
	'enabled': False,
	'random_port': True,
	'listen_ports': [6892, 6896],
	'listen_random_port': None,
	'certificate_location': os.path.join(
	deluge.configmanager.get_config_dir(), 'ssl_peers_certificates'
	),
	},
	'ssl_torrents': False,
	'ssl_listen_ports': [6892, 6896],
	'ssl_torrents_certs': os.path.join(
	deluge.configmanager.get_config_dir(), 'ssl_torrents_certs'
	),
	},

[cas--]

Should be log.error

[cas--]

This is a tricky one since we are both adding a new RPC method and relying on a new libtorrent exposed method...

Sometimes we check for specific libtorrent version but it likely is easier in this case to catch the AttributeError and log a warning. For the clients we could either re-raise the exception with a nice message or return an invalid port number, not sure which would be better long-term

Suggested change

	return self.session.ssl_listen_port()
	try:
	return self.session.ssl_listen_port()
	except AttributeError:
	log.warning("libtorrent version >=2.x required to get active SSL listen port")
	return -1

[cas--]

Is there a consensus on file naming convention here? I notice that the cert file is missing an extension which doesn't seem quite right.

I feel that the files should end in .pem to indicate the encoding. The libtorrent tests use:

• dhparams.pem
• <torrent_id>.pem
• <torrent_id>_key.pem

Also these default files will need documented.

I wonder if we can make the code cleaner with pathlib and for else:

Suggested change

	certificate_path = None
	private_key_path = None
	dh_params_path = None
	for file_name in [torrent_id + '.dh', 'default.dh']:
	params_path = os.path.join(base_path, file_name)
	if os.path.isfile(params_path):
	dh_params_path = params_path
	break
	if dh_params_path:
	for file_name in [torrent_id, 'default']:
	crt_path = os.path.join(base_path, file_name)
	key_path = crt_path + '.key'
	if os.path.isfile(crt_path) and os.path.isfile(key_path):
	certificate_path = crt_path
	private_key_path = private_key_path
	break
	certs_dir = Path(self.config['ssl_torrents_certs'])
	dh_params_file = certs_dir / f'{torrent_id}.dh'
	if not dh_params.is_file():
	dh_params_file = certs_dir / 'dhparams.pem'
	for filename in [torrent_id, 'default']:
	cert_file = certs_dir / f'{filename}.pem'
	priv_key_file = certs_dir / f'{filename}_key.pem'
	if dh_params_file.is_file() and cert_file.is_file() and priv_key_file.is_file():
	break
	else:
	log.error('<Certs not found...>')
	return

In fact this feels like reusable code for a common helper function

[rcarpa]

Thank you for the review. I updated the pull request. I slightly deviated from the naming convention you proposed for the files on the disk, because it seemed strange to have a specific naming for dh_params.pem, while calling it <torrent_id>.dh.pem for per-torrent configuration. Files are now automatically saved on disk when set via RPC. I also added a test which creates a seeder and a leecher instance and performs an actual transfer between the 2 using SSL torrents. I did some minor adjustments to facilitate adding this test case. I also rebased on top of #430 which allows to slightly simplify the test case (create and return the torrent on the seeder in one call) + avoids merge conflicts because both PRs change the signature of create_torrent.

[rcarpa]

Just rebased. No functional changes in last force push.

[cas--]

Thanks for all the changes and tests! I'll try to get to this PR next, oh and don't worry about rebasing