Client unable to connect with recent openSSL library / disable SSLv3 usage

[jor123]

Because of CVE-2014-3566 (POODLE) OpenSSL 1.0.1j has option to build without SSLv3 support (The Debian unstable distribution now has a version which does this). This breaks the rpcserver ssl connections.

The WebUI was switched to TLSv1_METHOD in 1.3.10. But the RPCserver still has SSLv3_METHOD. Not sure if compatibility of the TLS version between a deluge client and server is a big issue (or if you would want to limit it to TLSv1 only).

Here's a quick patch I applied, which also supports TLS 1.1 and TLS 1.2

[jor123]

Patch to use TLSv12

[Cas]

That is not helpful of Debian, the POODLE issue affects HTTPS only so doesn't apply to usage such as RPC.

I was looking to change the rpcserver to TLS (makes sense to use TLS 1.2) in develop code.

[jor123]

Yes, makes sense to use TLS 1.2 when interoperability with older clients/servers (on WinXP or Android 2.x?) is not an issue.

And regarding the helpfulness of Debian: that's probably a bit off-topic for this bug report... so I'll try to keep it short :) Yes, the only known exploit is with the HTTP protocol (and a browser with javascript), but others could be similarly vulnerable. I'm not familiar with the used RPC protocol, are you absolutely sure it's not vulnerable? (no session-id like content? can I maybe manipulate the content of rpc messages by doing something through the torrent protocol?) Anyway, I believe the general consensus is to phase out the usage of sslv3 before more exploits show up. It's only in Debian 'unstable' distribution for now, probably one of the few places where something like this can be phased out more quickly and get some testing to see what breaks :) I suspect other distributions (and OpenSSL itself) will follow in their next major releases.

[Cas]

It is important to note that the context options are bitmasks so when setting with set_options you need to use bitwise or |. So in the attached patch using & will set those options to zero thus resulting in no effect.

[Cas]

This is now fixed in 1.3-stable, [40382002f64], so the daemon will no longer allow clients to connect over SSLv3. As the client SSL code already defaulted to using SSLv23_METHOD is won't affect compatibility.