|Level 0||Everything is permitted. This retains compatibility with previous versions of OpenSSL.|
|Level 1||The security level corresponds to a minimum of 80 bits of security. Any parameters offering below 80 bits of security are excluded. As a result RSA, DSA and DH keys shorter than 1024 bits and ECC keys shorter than 160 bits are prohibited. All export ciphersuites are prohibited since they all offer less than 80 bits of security. SSL version 2 is prohibited. Any ciphersuite using MD5 for the MAC is also prohibited.|
|Level 2||Security level set to 112 bits of security. As a result RSA, DSA and DH keys shorter than 2048 bits and ECC keys shorter than 224 bits are prohibited. In addition to the level 1 exclusions any ciphersuite using RC4 is also prohibited. SSL version 3 is also not allowed. Compression is disabled.|
|Level 3||Security level set to 128 bits of security. As a result RSA, DSA and DH keys shorter than 3072 bits and ECC keys shorter than 256 bits are prohibited. In addition to the level 2 exclusions ciphersuites not offering forward secrecy are prohibited. TLS versions below 1.1 are not permitted. Session tickets are disabled.|
|Level 4||Security level set to 192 bits of security. As a result RSA, DSA and DH keys shorter than 7680 bits and ECC keys shorter than 384 bits are prohibited. Ciphersuites using SHA1 for the MAC are prohibited. TLS versions below 1.2 are not permitted.|
|Level 5||Security level set to 256 bits of security. As a result RSA, DSA and DH keys shorter than 15360 bits and ECC keys shorter than 512 bits are prohibited.|
WARNING at this time setting the security level higher than 1 for general internet use is likely to cause considerable interoperability issues and is not recommended. This is because the SHA1 algorithm is very widely used in certificates and will be rejected at levels higher than 1 because it only offers 80 bits of security.
The default security level can be configured when OpenSSL is compiled by setting -DOPENSSL_TLS_SECURITY_LEVEL=level. If not set then 1 is used.
The security framework disables or reject parameters inconsistent with the set security level. In the past this was difficult as applications had to set a number of distinct parameters (supported ciphers, supported curves supported signature algorithms) to achieve this end and some cases (DH parameter size for example) could not be checked at all.
By setting an appropriate security level much of this complexity can be avoided.
The bits of security limits affect all relevant parameters including ciphersuite encryption algorithms, supported ECC curves, supported signature algorithms, DH parameter sizes, certificate key sizes and signature algorithms. This limit applies no matter what other custom settings an application has set: so if the ciphersuite is set to ALL then only ciphersuites consistent with the security level are permissible.
See SP800-57 for how the security limits are related to individual algorithms.
Some security levels require large key sizes for non-ECC public key algorithms which can severely degrade performance. For example 256 bits of security requires the use of RSA keys of at least 15360 bits in size.
Some restrictions can be gracefully handled: for example ciphersuites offering insufficient security are not sent by the client and will not be selected by the server. Other restrictions such as the peer certificate key size or the DH parameter size will abort the handshake with a fatal alert.
Attempts to set certificates or parameters with insufficient security are also blocked. For example trying to set a certificate using a 512 bit RSA key using SSL_CTX_use_certificate() at level 1. Applications which do not check the return values for errors will misbehave: for example it might appear that a certificate is not set at all because it had been rejected.
These functions were first added to OpenSSL 1.1.0