Custom Query (2449 matches)

deluge 1.3.15 libtorrent 1.1.3 Arch Linux

DHT fails bootstrapping at times, whereas qbittorrent doesn't, so if you could kindly please add the bootstrap-node list from qbittorrent and set to append not overwrite(to not mess with ltconfig plugin). Thanks alot in advance! -Martin Hertz.

"dht.libtorrent.org:25401,router.bittorrent.com:6881,router.utorrent.com:6881,dht.transmissionbt.com:6881,dht.aelitis.com:6881"

Following a consideration on ​ticket 3064.

To meet industry standards on SSL/TLS security and to increase security headroom when exposing the Web UI to the Internet, I believe that some changes are required on the transport side.

1. Disable TLS v1.0. Only allow TLS >= v1.1 (​link). All reasonably modern browsers should have no problem with this.

2. Respect certificate x509 extensions, especially key usage

For example: Currently, if keyUsage is set to "critical, digitalSignature", which should forbid plain RSA since that is a keyEncipherment operation, the server will happily still use plain RSA. That is... bad.

3. Enable (only) (elliptic curve or regular) Diffie-Hellman epidermal key exchange cipher suites.

This is necessary to provide Perfect Forward Secrecy. This requires adding DH parameters, but it shouldn't be to hard to generate with dhparams and include it with the distribution or generate it dynamically. Currently there's only plain RSA cipher suites enabled.

4. Tweak cipher list to prefer AES GCM modes and disable MD5/DES/RC4.

More resistant to certain types of attacks. Current list seems to prefer AES CBC for some reason.

(1) and (4) can be trivially done now but might break compatibility with some outdated clients. (2) I don't know about if Twisted even supports. (3) requires a newer version of Twisted than currently in the Trusty repositories.

Hi!

I'm going to try to keep this short. I'm trying to add a certificate chain to the deluge web UI, the subject certificate concatenated with a intermediate certificate, as is standard. I've successfully verified the separate files using the openssl verify" utility.

$ openssl verify -verbose -CAfile root.cert.pem -untrusted intermediate.cert.pem deluge.cert.pem
deluge.cert.pem: OK

However, Firefox gives me an SEC_ERROR_UNKNOWN_ISSUER error. To look at what the server sends my I use:

openssl s_client -CAfile root.cert.pem -connect localhost:8112 -showcerts

Indeed, the output shows the server does not send the intermediate certificate. It seems the deluge web server only sends the first certificate, and skips the rest of the chain. As this has worked correctly in the past, I looked at the git history and the culprit seems to be commit c1902e43, which replaces the code for loading the certificate, specifically

certificate = Certificate.loadPEM(cert.read()).original[/code]
instead of
[code]ctx.use_certificate_chain_file(configmanager.get_config_dir(delugeweb.cert))

As far as I can tell this is an incorrect way to read chain files. Look at the example at ​https://pem.readthedocs.io/en/stable/twisted.html for guidance.

I would fix this myself but I'm sure you that have greater experience with the code can do it much quicker and efficiently.