Opened 3 years ago

Closed 3 years ago

#2555 closed bug (Fixed)

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

Reported by: jor123 Owned by:
Priority: major Milestone: 1.3.11
Component: Core Version: 1.3.10
Keywords: Cc: a.starr.b@…

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 jor123 3 years ago.
Patch to use TLSv12

Download all attachments as: .zip

Change History (8)

Changed 3 years ago by jor123

Patch to use TLSv12

comment:1 Changed 3 years ago by Cas

  • Milestone changed from Future to 1.3.x

comment:2 Changed 3 years ago by Cas

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

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

Last edited 3 years ago by Cas (previous) (diff)

comment:3 Changed 3 years ago by 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.

comment:4 Changed 3 years ago by andrewsomething

  • Cc a.starr.b@… added

comment:5 Changed 3 years ago by Cas

  • Milestone changed from 1.3.x to 1.3.11

comment:6 Changed 3 years ago by 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.

comment:7 Changed 3 years ago by Cas

  • Resolution set to Fixed
  • Status changed from new to closed

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.