search

qbittorrent / qBittorrent

qBittorrent BitTorrent client
https://www.qbittorrent.org
Other
27.75k stars 3.92k forks source link

WebUI fails SSL Labs server test #18483

Closed eakaye closed 1 year ago

eakaye commented 1 year ago

qBittorrent & operating system versions

qBittorrent: 4.5.0 x64 Operating system: Windows 10 Pro 22H2/19045 x64

What is the problem?

The TLS-enabled web UI fails the SSL Labs test. The most pressing issue is that it's vulnerable to the ROBOT oracle attack, but it also supports TLS 1.0 and 1.1, offers weak DH parameters, and has no option to send the intermediate certificate to the client.

Steps to reproduce

  1. Enable web UI and TLS with a trusted certificate.
  2. Forward port 443 to your system on the firewall.
  3. Enter your host name at https://www.ssllabs.com/ssltest and wait for the results.

Additional context

image

Log(s) & preferences file(s)

No response

NotTsunami commented 1 year ago

I am unfamiliar with hosting the web UI, but if you serve it through a reverse proxy with nginx, you should be able to configure SSL parameters, correct?

eakaye commented 1 year ago

I am unfamiliar with hosting the web UI, but if you serve it through a reverse proxy with nginx, you should be able to configure SSL parameters, correct?

edit: I misunderstood your suggestion, and I think that Windows IIS has a reverse proxy feature that can serve a similar purpose. Still, I think that if qBittorrent is going to offer TLS support, they need to keep it up to date. Offering a broken TLS implementation is more dangerous than if they didn't offer it at all because it provides a false sense of security, whereas if it only supported bare HTTP, then users would at least know to gate it behind a SSH tunnel or similar.

sledgehammer999 commented 1 year ago

@eakaye are you using vanilla qbittorrent to connect to the webui or are you behind a proxy? I can't test with SSLlabs because I don't have a hostname. I tested with sslyze locally and qbittorrent passes the ROBOT test.

Are you using the Qt5 or the Qt6 version? I tested with Qt5.

sledgehammer999 commented 1 year ago

Or can you share what the "MORE INFO" link in SSLlabs report says?

NotTsunami commented 1 year ago

I'll prepare a PR for restricting protocols (QSsl::TlsV1_2OrLater) and updating the ciphers

eakaye commented 1 year ago

Here's the link. I'm using vanilla qBittorrent built with Qt 5.15.7 and no proxy, just port forwarding -- I configured qBT with an arbitrary port, which is normally the same port I forward to the Internet, but SSL Labs doesn't support changing the port so I had to change the external one to 443 for the test. For "production" use I'd be changing it back to the arbitrary one.

I tested with sslyze and it also passed the ROBOT test, so I'm not sure which of the two is correct. I was also able to get qBT to pass the intermediate certificate by concatenating it to the server cert, so that's solved at least.

edit: robot-detect also returns "not vulnerable", so I suspect SSL Labs is giving a false positive.

sledgehammer999 commented 1 year ago

If I understood correctly the online docs on ROBOT, this vulnerability depends on RSA key exchange. And if I understand correctly RSA key exchange is removed/disabled entirely in TLS 1.3. So is all we have to do is drop < TLS 1.3 support?

NotTsunami commented 1 year ago

If I understood correctly the online docs on ROBOT, this vulnerability depends on RSA key exchange. And if I understand correctly RSA key exchange is removed/disabled entirely in TLS 1.3. So is all we have to do is drop < TLS 1.3 support?

TLSv1.3 is still fairly new, I think TLSv1.3 would be too restrictive.

sledgehammer999 commented 1 year ago

@eakaye can you take a look at PR #18500? Once the CI finish, can you test one of the "artifacts" against ssllabs and report what you get?