Opened 10 years ago

Closed 10 years ago

#2555 closed bug (Fixed)

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

Reported by: jor Owned by:
Priority: major Milestone: 1.3.11
Component: Core Version: 1.3.10
Keywords: Cc: a.starr.b@gmail.com

Description

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

Attachments (1)

no-sslv3.diff (612 bytes ) - added by jor 10 years ago.
Patch to use TLSv12

Download all attachments as: .zip

Change History (8)

by jor, 10 years ago

Attachment: no-sslv3.diff added

Patch to use TLSv12

comment:1 by Calum, 10 years ago

Milestone: Future1.3.x

comment:2 by Calum, 10 years ago

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.

Version 0, edited 10 years ago by Calum (next)

comment:3 by jor, 10 years ago

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.

comment:4 by andrewsomething, 10 years ago

Cc: a.starr.b@gmail.com added

comment:5 by Calum, 10 years ago

Milestone: 1.3.x1.3.11

comment:6 by Calum, 10 years ago

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.

comment:7 by Calum, 10 years ago

Resolution: Fixed
Status: newclosed

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.

Note: See TracTickets for help on using tickets.