KMS is using insecure protocols and ciphers (TLS1.0, TLS1.1, RC4, CBC)

RaistGH commented 2 years ago

Prerequisites

These are MANDATORY, otherwise the issue will be automatically closed.

[x] I agree to fill this issue template.
[x] I have read the Troubleshooting Guide and Support Instructions.

Issue description

After running a security audit we got a few security vulnerabilities related to Kurento due to obsolete protocols:

TLS/SSL RC4 cipher is enabled:
- https://owasp.org/www-project-web-security-testing-guide/v41/4-Web_Application_Security_Testing/09-Testing_for_Weak_Cryptography/01-Testing_for_Weak_SSL_TLS_Ciphers_Insufficient_Transport_Layer_Protection
- https://nvd.nist.gov/vuln/detail/cve-2015-2808
TLS1.0 and TLS 1.1 insecure protocols are offered
- https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
Insecure SSL/TLS ciphers: CBC (Cipher Block Chaining) enabled
- https://www.owasp.org/index.php/Testing_for_SSL-TLS_(OWASP-CM-001)

Context

The link between Application Server and KMS is vulnerable to attacks when in different servers.

How to reproduce?

Run a security audit against KMS

Expected & current behavior

Some modifications should be done at server/docker level

Disable RC4 cipher
Offer only TLS1.2 and TLS1.3
Disable CBC cipher

(Optional) Possible solution

This thread is relevant related to the websocket security layer.

About Kurento Media Server

Kurento version: All versions
Server OS: Ubuntu 16.04 (Xenial)
Installation method:
- x

github-actions[bot] commented 2 years ago

Hello @RaistGH! :wave: we're sorry you found a bug... so first of all, thank you very much for reporting it.

To know about progress, check in Triage. All issues are considered Backlog Candidates until work priorities align and the issue is selected for development. It will then become part of our official Backlog.

RaistGH commented 2 years ago

Related to vulnerability 2, new versions of OpenSSL use function SSL_CTX_set_min_proto_version to limit the lower protocol. Method SSLv23_method becomes deprecated and TLS_method is used instead, but I can't figure out if the current version of Boost Library used by the Kurento Websocket has got something similar.

RaistGH commented 2 years ago

Sorry, mistakenly closed

j1elo commented 2 years ago

Hi,

Could you point to where exactly are points (1.) and (3.) in Kurento? Is it in the WebSocket interface?

Regarding (2.), Kurento 6.x uses OpenSSL 1.0.2 (see docs), which doesn't support the version-flexible "TLS" method, but it does support an equivalent method called "SSLv23". Docs say this when describing the SSLv23_method:

SSLv23_method() These are the general-purpose version-flexible SSL/TLS methods. [...] Most applications should use these method, and avoid the version specific methods described below.

Later:

The SSLv2 and SSLv3 protocols are deprecated and should generally not be used. Applications should typically use SSL_CTX_set_options() in combination with the SSL_OP_NO_SSLv3 flag to disable negotiation of SSLv3 via the above version-flexible SSL/TLS methods. The SSL_OP_NO_SSLv2 option is set by default [...]

To this intent, Kurento uses the version-flexible method, and explicitly disables SSLv2 and SSLv3 (see this block).

There is no need, nor intention, of disabling support for TLS 1.0, which would break backwards compatibility with legacy clients such as embedded systems. The server simply offers support of multiple different methods, and it is the client app's prerogative to request using a higher version (ideally, with a similar version-flexible selection method, so the common highest can be selected).

Kurento 7.0.0 is now ready to work on top of Ubuntu 20.04, which comes with OpenSSL 1.1.1, so when it gets released will already have support for the generic "TLS" method. This time, docs state that this should be used, as all other methods are deprecated:

TLS_method() These are the general-purpose version-flexible SSL/TLS methods. The actual protocol version used will be negotiated to the highest version mutually supported by the client and the server. [...] Applications should use these methods, and avoid the version-specific methods described below, which are deprecated.

And

The SSLv3 protocol is deprecated and should generally not be used. Applications should typically use SSL_CTX_set_min_proto_version() to set the minimum protocol to at least TLS1_VERSION.

This is already done by Boost 1.71 when choosing the "TLS" method (source):

  case context::tls:
    handle_ = ::SSL_CTX_new(::TLS_method());
    if (handle_)
      SSL_CTX_set_min_proto_version(handle_, TLS1_VERSION);
    break;

Regardless of all this, note that Kurento does not even try to secure the WebSocket port: it is considered a private resource in any given deployment, and should be protected by means of a firewall or access controls. See Securing Kurento Media Server.

j1elo commented 1 year ago

As explained in https://github.com/Kurento/bugtracker/issues/640#issuecomment-1318681764, this is as intended and client applications should request usage of the most secure protocol they are able to handle.

Kurento / bugtracker