Skip to content

WeakSSLCertificates

Jump to bottom
Chris Wilson edited this page Oct 25, 2023 · 22 revisions

Weak SSL Certificates

Certificates in Box Backup

Certificates ensure the security of the Box Backup server (bbstored) against malicious clients connecting, which could damage or delete existing backups, prevent new backups from occurring, and waste CPU time and disk space on the server. Certificates and their keys are not used to encrypt client data at rest.

They also allow the client (bbackupd) to verify that it is connecting to the correct server, not an imposter, who could not decrypt the encrypted data, but could substitute bad data on restore, or prevent new backups from occurring.

Box Backup uses X.509 certificates, which are generated on the server and clients. They are signed by a Certificate Authority (CA), usually a private (free) one created by the included scripts, which should be kept on a separate machine to all servers and clients, strongly protected from the Internet, and with an encrypted disk.

Certificates and security

Certificates can and sometimes must be changed, for example:

  • Every certificate has a built-in expiry date, which cannot be changed. Box Backup's certificates normally expire in the year 2038 for server certificates, and 5000 days (about 13 years) after creation for client certificates.
  • If a client or server is compromised, it needs a new certificate as part of the repair/recovery process.
  • If the CA is compromised, a new one should be created (on a fresh, secure box) and all certificates generated by the old one and still in use should be replaced. (This is a pain, which is why you should keep the CA really secure, to avoid the need to do this.)
  • Ever-increasing processor speeds and cryptographic techniques make it easier to crack encryption with shorter keys. Therefore the recommended key lengths increase too. At some point an old certificate will no longer be secure against a well-funded adversary, and should be replaced with a new one that uses a longer key.

Debian and the OpenSSL Security Level

Debian Linux have recently, for Debian 10 Buster, increased their default global security level from 1 to 2 (possibly related to the upgrade to OpenSSL 1.1.1). At security level 2, "RSA, DSA and DH keys shorter than 2048 bits and ECC keys shorter than 224 bits are prohibited" (source). Certificates with 1024-bit keys, and certificates signed with the SHA1 algorithm, are considered to be weak and therefore dangerous, and not allowed.

This has caused problems for several applications, including Box Backup (Debian bug 907135) and OpenVPN and Unbound (Debian bug 907049). The effects on Box Backup are that:

  • All existing certificates are signed with the SHA1 algorithm, and can no longer be used (by default); and
  • Some tests use 1024-bit certificates which can no longer be used either.

Clients and servers with OpenSSL 1.1.1 installed will refuse to load old (weak) certificates, and to connect to servers (clients) with old (weak) certificates.

The most correct (and unfortunately painful) solution is to replace all certificates. Three workarounds are available (for now) if this is too difficult, but you cannot delay it forever and expect to remain secure.

Solution

The Debian security level update resulted in all existing Box Backup installations on Debian being broken by default. This is annoying but inevitable: certificates are not good forever. As Box Backup is designed and supposed to be secure, we must strike a tricky balance between security and usability.

We have therefore decided to:

  1. Ensure that new installations are secure (stronger certificates generated and required);
  2. Ensure that existing installations are not broken, even if they are considered "weak";
  3. Warn users if their certificates are (or might be) weak;
  4. Allow them to disable this warning if required (not recommended);
  5. Make it easy for users to do the right thing: replace their certificates with safer ones, and require safer certificates;
  6. Provide the option to not override the system-wide security level (which may be higher than 2 in future).
  7. Eventually change the default security level from -1 to 2 (probably around December 2023).

In order to support point 2, we will override Debian's default security level of 2 for now, reducing it to level 1 (which is compatible with old certificates), but with a warning that users should increase their security level (point 3), which will eventually become mandatory (e.g. after about a year).

In order to support points 2 and 4-6, we will add a new configuration option, SSLSecurityLevel, which can have the following values:

  • 0-5: as documented in OpenSSL. Higher levels are more restrictive (and secure) than lower levels:
    • 0: Everything is permitted. This retains compatibility with previous versions of OpenSSL.
    • 1: Minimum of 80 bits of security. RSA, DSA and DH keys shorter than 1024 bits are prohibited, and MAC using MD5 and SHA1 (since OpenSSL 3.0). Not recommended.
    • 2: Minimum of 112 bits of security. RSA, DSA and DH keys shorter than 2048 bits are also prohibited. (Same as Debian's current system-wide default, supports points 1 and 5 above). Not recommended.
    • 3: Minimum of 128 bits of security. RSA, DSA and DH keys shorter than 3072 bits are also prohibited.
    • 4: Minimum of 192 bits of security. RSA, DSA and DH keys shorter than 7680 bits are also prohibited.
    • 5: Minimum of 256 bits of security. RSA, DSA and DH keys shorter than 15360 bits are also prohibited.
  • -1: Use the system-wide default security level, which may be 1, 2 or even higher (supports point 6 above).

Levels 0 and 1 are not recommended, only for users who like to live dangerously, or cannot replace their certificates right now (supports point 4 above).

To actually increase your security to the level required by Debian 10 Buste, you must:

Workaround 1

The new SSLSecurityLevel option is only available in Box Backup from 2019-05-19. It is only functional when compiled with OpenSSL 1.1 or higher. When compiled with older versions of OpenSSL, this new version of Box Backup will recognise the SSLSecurityLevel option, but ignore its value and give a warning on startup (if it is not set to the default value, -1).

So one possible workaround is to:

  • Upgrade to Box Backup 2019-05-19 or later, with OpenSSL 1.1 or above.
  • Set the SSLSecurityLevel option to 1 in bbackupd.conf and/or bbstored.conf, enabling you to load your old certificates, and connect to clients and servers using the old certificates.

Note that this will not actually increase your security, only restore the previously available functionality and security level.

Unfortunately, the changes required to solve the problem fully were quite large, and Box Backup was removed from Debian Unstable (Buster) much faster than we could implement them. Therefore Box Backup is currently not available at all in Debian 10. We hope to see it in debian-backports as soon as possible.

Workaround 2

You can work around this change globally (and keep using old, weak certificates) by editing /etc/ssl/openssl.cnf and finding the following section (at the end of the file):

[system_default_sect]
MinProtocol = TLSv1.2
CipherString = DEFAULT@SECLEVEL=2

and changing SECLEVEL=2 to SECLEVEL=1. However you would be going against Debian's recommendations by doing this, and it also affects (reduces the security level of) the whole system, not just Box Backup. The different security levels of OpenSSL are defined here.

Replacing certificates

This is the correct solution. It also requires upgrading (at least the CA) to Box Backup 2019-05-19 or later. After that, follow the Certificates and Account Management instructions to create a new CA, and new certificates for the server(s) and client(s).

If you control all the clients, then you can generate new certificates and keys for them all on the CA. The new certificates will work with older versions, and will allow them to start (if they are running OpenSSL 1.1.1) and to connect to any servers running OpenSSL 1.1.1. In this case, you don't need to upgrade them all, only the CA.

We recommend that after upgrading a client or server to Box Backup 2019-05-19 or later and installing its new certificates, you set its SSLSecurityLevel to 2, which enforces the new higher security level in communications with other clients and servers.

Replacing private keys

Certificates themselves are public, not secret. Every certificate is linked to a private key (e.g. an RSA key) which provides its security. Many certificates can be generated using the same key. If the key is compromised, then a new one must be generated, and any certificates which refer to the old key must be revoked and discarded, to regain security of the system.

It is often technically possible to generate a new certificate while reusing the old key. However this is usually not a good idea because:

  • If the key is compromised, the new certificate is too, and security is not regained by just replacing the certificate.
  • Even if you think that the key has not been compromised, it may have been without your knowledge, and generating a new key would limit the damage.
  • An opportunity to increase the key length, and hence the security of the key, is missed.

Therefore we recommend always generating a new key as well. The supplied scripts (such as bbstored-certs) make this easy.

Replacing this key does not invalidate existing backups, since they are encrypted with different key (the file encryption key) which is not usually replaced. But it does mean that the certificate and key files will need to be replaced on all clients and servers which use that certificate.

In the case of a single server or client certificate, only that server or client needs to be reconfigured to use the new key. Other servers and clients use the CA's signature to determine whether to trust each other, and new certificates are required to be signed by a recognised CA.

If the CA key is compromised, then the attacker can create new certificates with valid signatures at will, and no amount of revoking existing certificates will protect you. At this point it is necessary to discard the old CA and generate a new one, with new certificates. All client and server certificates will need to be replaced, or at least resigned by the new CA. This is a pain, which is why you should keep the CA really secure, to avoid the need to do this.

Recommendations

We recommend that all users upgrade all their systems, increase their SSLSecurityLevel to 2, and generate new certificates for everything (a new CA and new client and server certificates).

If you cannot do this immediately, we recommend that you plan to do it as soon as possible (definitely before May 2020), and leave SSLSecurityLevel at its default value (-1) for the time being, with the warning on startup to remind you. We recommend that you do not disable the warning by setting SSLSecurityLevel to 1, but it's there as an option if you really need it.

You should never explicitly use SSLSecurityLevel -1 in your configuration files, as this will prevent the security level from being automatically increased in a future version (forcing you to replace the certificates).

For Users

For Developers

Support

Clone this wiki locally