Fix Raccoon vulnerability (CVE-2020-1968)

[Nils Toedtmann]

Xenial's current OpenSSL (1.0.2g-1ubuntu4.16) seems to not have been patched yet against the Raccoon Attack (CVE-2020-1968):

- https://www.openssl.org/news/secadv/20200909.txt
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1968
- https://raccoon-attack.com/

Ubuntu's CVE tracker still lists this as NEEDED for Xenial:

- https://people.canonical.com/~ubuntu-security/cve/2020/CVE-2020-1968.html
- https://people.canonical.com/~ubuntu-security/cve/pkg/openssl.html

Other supported Ubuntu releases use versions of OpenSSL that are not affected.

Indeed:

  $ apt-cache policy openssl
  openssl:
    Installed: 1.0.2g-1ubuntu4.16

  $ apt-get changelog openssl | grep CVE-2020-1968 || echo "Not patched"
  Not patched

What is the status?

[Dimitri John Ledkov (xnox)]

It is true that said vulnerability is not patched in xenial; but also it is low; and no public patches for it exist.

Please upgrade to bionic or focal? which are unaffected / fixes released?

[Nils Toedtmann (m-launchpad-net-mail-nils-toedtmann-net)]

> "Please upgrade to bionic or focal?"

Is this an official recommendation from Ubuntu, that users shall migrate off Xenial now, because of a security issue in a core library?

And there I was, thinking we have until April 2021 ...

[Seth Arnold (seth-arnold)]

Alternatively, you could use one of the recommended TLS configurations from Mozilla, https://wiki.mozilla.org/Security/Server_Side_TLS which do not enable the unsafe cryptography suites.

Thanks

[Marc Deslauriers (mdeslaur)]

This has now been fixed:

https://ubuntu.com/security/notices/USN-4504-1

[Nils Toedtmann (m-launchpad-net-mail-nils-toedtmann-net)]

Thank you very much for fixing swiftly!

Please forgive me for pointing this out though:

I note that rather than stopping the affected cipher suites from re-using secrets across connections, you chose to declare the suites as weak and disabled them altogether.

I appreciate that this is an elegant way to close this vulnerability, in particular in the absence of an upstream patch.

However, this solution introduces the risk that when trying to establish a connection with some legacy client or server, they can no longer agree on a shared cipher, and the TLS handshake fails. That is not in the spirit of a LTS, which is often elected and used precisely because it makes it easier to to support legacy products reliably.

[Marc Deslauriers (mdeslaur)]

It's not feasible to stop the affected ciphers from re-using secrets, it's in the specification.

Removing the ciphers is what was done in later releases of openssl, including the 1.0.2w version that was released specifically to address this issue:

https://www.openssl.org/news/secadv/20200909.txt

[Nils Toedtmann (m-launchpad-net-mail-nils-toedtmann-net)]

Oh, indeed!

> 1.0.2w moves the affected ciphersuites into the "weak-ssl-ciphers" list. [...]
> This is unlikely to cause interoperability problems in most cases since use of these ciphersuites is rare.

Fair enough. Thank you for clarifying.

(And apologies for this noise)