Best Practices for SSL / TLS Deployment, Part 2. Configuration
We present to you the second part of the translation of the article on the deployment of SSL / TLS, the first part can be read here.
2. Configuration
If you have correctly configured the TLS server, then you can be sure that your site data is displayed correctly for site visitors, only secure algorithms are used and all known vulnerabilities are eliminated.
')
2.2. Use secure protocols
There are five protocol versions in the SSL / TLS family: SSL v2, SSL v3, TLS v1.0, TLS v1.1 and TLS v1.2. Of them:
• SSL v2 is insecure and should not be used.
• SSL v3 is insecure when used with HTTP and weak when used with other protocols. This version is also outdated, so it should not be used.
• TLS v1.0 is still a secure protocol. When used with HTTP, this protocol provides security, but only with careful configuration.
• TLS v1.1 and v1.2 do not have known security issues.
TLS v1.2 should be your main protocol. This version is better because it supports important features that are not available in earlier versions. If your server (or any intermediate device) does not support TLS v1.2, then plan its upgrade in an accelerated mode. If your service providers do not support TLS v1.2, require them to upgrade their system.
To support older clients, you must continue to support TLS v1.0 and TLS v1.1 for some time. With some workarounds, these protocols can still be considered fairly secure for most websites.
2.3. Use secure encryption algorithms
For secure data exchange, you must first make sure that you are communicating directly with the desired subscriber (and not through someone who will eavesdrop). SSL and TLS encryption algorithms are used to determine how secure the data exchange is. They consist of various building blocks. If there is poor security in one of the building blocks, then you should be able to switch to another.
Your goal is to use only those encryption algorithms that provide authentication and encryption of 128 bits or more. Everything else should be avoided:
• Sets with weak encryption algorithms (usually 40 to 56 bits) can be easily cracked
• RC4 is also now considered weak. You should remove support for this algorithm as early as possible, but only after verifying the potential negative impact on compatibility.
• 3DES provides about 112 security bits. This is below the recommended minimum of 128 bits, but it is still a fairly strong algorithm. The big practical problem is that 3DES is much slower than alternatives. Therefore, we do not recommend it for better performance.
2.4. Control over the choice of encryption algorithm
In SSL version 3 and later versions of the protocol, clients send a list of encryption algorithms that they support, and the server selects one of them to establish a secure communication channel. Not all servers can do this well, as some choose the first supported algorithm from the list. Thus, choosing the right encryption algorithm is critical to security.
2.5. Forward Secrecy support.
Forward Secrecy is a protocol feature that provides secure data exchange, it does not depend on the server's private key. With encryption algorithms that do not support Forward Secrecy, it is possible to decrypt previously encrypted conversations using the server's private key. You need to support and prefer ECDHE (abbreviation ECDHE stands for “Diffie-Hellman ephemeral algorithm using elliptic curves”) encryption algorithms. To support a wider range of clients, you should also use DHE as a fallback after ECDHE.
2.6. Disable client initiation Renegotiation
In SSL / TLS renegotiation allows the parties to stop data exchange in order to re-initiate it to ensure security. There are some cases in which renegotiation must be initiated by the server, but there is no known need to allow the client to initiate renegotiation. In addition, it can facilitate the organization of DDoS attacks on your servers.
2.7. Reduced known issues
At some point, there may be security problems with any product. Well, if you are always up to date in the world of information security. At the very least, you should monitor the security releases of the products you use and install them as soon as they become available.
Watch what happens in the world of security and adapt to the situation when it is necessary. At the very least, you should immediately install the patches covering the detected vulnerabilities as soon as they become available. Pay attention to the following questions:
- Disable TLS compression
In 2012, a CRIME attack showed how TLS compression can be used by attackers to identify sensitive data details (for example, session cookies). Very few clients supported TLS compression then (and currently), so it is unlikely that you will experience any performance problems after disabling TLS compression on the servers.
- Disable RC4
The RC4 algorithm is unsafe and must be disabled. We currently know that hacking RC4 requires millions of requests, a lot of bandwidth and time. Thus, the risk is still relatively small, but it is possible that the attacks will be bigger in the future. Before removing RC4, check if your existing users will be affected; in other words, check if you have clients that only support RC4.
- Be aware of the attack BEAST
A successful BEAST attack is like a hacking session. Unfortunately, RC4 is required to mitigate the threat posed by the server, which is no longer recommended. Because of this, and also because the BEAST attack is now largely reduced on the client side, we no longer recommend server mitigation by using RC4. In some situations, when there are a large number of old clients vulnerable to BEAST attacks, it is safer to use RC4 with TLS 1.0 and earlier versions of the protocol. This decision should be made carefully and only after a complete understanding of the environment and its threat model.
- Disable SSL v3
SSL v3 is vulnerable to the POODLE attack, which was discovered in October 2014. The best way to eliminate the POODLE attack vulnerability is to disable SSL v3, which can be done safely in most sites.
2. Configuration
If you have correctly configured the TLS server, then you can be sure that your site data is displayed correctly for site visitors, only secure algorithms are used and all known vulnerabilities are eliminated.
')
2.2. Use secure protocols
There are five protocol versions in the SSL / TLS family: SSL v2, SSL v3, TLS v1.0, TLS v1.1 and TLS v1.2. Of them:
• SSL v2 is insecure and should not be used.
• SSL v3 is insecure when used with HTTP and weak when used with other protocols. This version is also outdated, so it should not be used.
• TLS v1.0 is still a secure protocol. When used with HTTP, this protocol provides security, but only with careful configuration.
• TLS v1.1 and v1.2 do not have known security issues.
TLS v1.2 should be your main protocol. This version is better because it supports important features that are not available in earlier versions. If your server (or any intermediate device) does not support TLS v1.2, then plan its upgrade in an accelerated mode. If your service providers do not support TLS v1.2, require them to upgrade their system.
To support older clients, you must continue to support TLS v1.0 and TLS v1.1 for some time. With some workarounds, these protocols can still be considered fairly secure for most websites.
2.3. Use secure encryption algorithms
For secure data exchange, you must first make sure that you are communicating directly with the desired subscriber (and not through someone who will eavesdrop). SSL and TLS encryption algorithms are used to determine how secure the data exchange is. They consist of various building blocks. If there is poor security in one of the building blocks, then you should be able to switch to another.
Your goal is to use only those encryption algorithms that provide authentication and encryption of 128 bits or more. Everything else should be avoided:
• Sets with weak encryption algorithms (usually 40 to 56 bits) can be easily cracked
• RC4 is also now considered weak. You should remove support for this algorithm as early as possible, but only after verifying the potential negative impact on compatibility.
• 3DES provides about 112 security bits. This is below the recommended minimum of 128 bits, but it is still a fairly strong algorithm. The big practical problem is that 3DES is much slower than alternatives. Therefore, we do not recommend it for better performance.
2.4. Control over the choice of encryption algorithm
In SSL version 3 and later versions of the protocol, clients send a list of encryption algorithms that they support, and the server selects one of them to establish a secure communication channel. Not all servers can do this well, as some choose the first supported algorithm from the list. Thus, choosing the right encryption algorithm is critical to security.
2.5. Forward Secrecy support.
Forward Secrecy is a protocol feature that provides secure data exchange, it does not depend on the server's private key. With encryption algorithms that do not support Forward Secrecy, it is possible to decrypt previously encrypted conversations using the server's private key. You need to support and prefer ECDHE (abbreviation ECDHE stands for “Diffie-Hellman ephemeral algorithm using elliptic curves”) encryption algorithms. To support a wider range of clients, you should also use DHE as a fallback after ECDHE.
2.6. Disable client initiation Renegotiation
In SSL / TLS renegotiation allows the parties to stop data exchange in order to re-initiate it to ensure security. There are some cases in which renegotiation must be initiated by the server, but there is no known need to allow the client to initiate renegotiation. In addition, it can facilitate the organization of DDoS attacks on your servers.
2.7. Reduced known issues
At some point, there may be security problems with any product. Well, if you are always up to date in the world of information security. At the very least, you should monitor the security releases of the products you use and install them as soon as they become available.
Watch what happens in the world of security and adapt to the situation when it is necessary. At the very least, you should immediately install the patches covering the detected vulnerabilities as soon as they become available. Pay attention to the following questions:
- Disable TLS compression
In 2012, a CRIME attack showed how TLS compression can be used by attackers to identify sensitive data details (for example, session cookies). Very few clients supported TLS compression then (and currently), so it is unlikely that you will experience any performance problems after disabling TLS compression on the servers.
- Disable RC4
The RC4 algorithm is unsafe and must be disabled. We currently know that hacking RC4 requires millions of requests, a lot of bandwidth and time. Thus, the risk is still relatively small, but it is possible that the attacks will be bigger in the future. Before removing RC4, check if your existing users will be affected; in other words, check if you have clients that only support RC4.
- Be aware of the attack BEAST
A successful BEAST attack is like a hacking session. Unfortunately, RC4 is required to mitigate the threat posed by the server, which is no longer recommended. Because of this, and also because the BEAST attack is now largely reduced on the client side, we no longer recommend server mitigation by using RC4. In some situations, when there are a large number of old clients vulnerable to BEAST attacks, it is safer to use RC4 with TLS 1.0 and earlier versions of the protocol. This decision should be made carefully and only after a complete understanding of the environment and its threat model.
- Disable SSL v3
SSL v3 is vulnerable to the POODLE attack, which was discovered in October 2014. The best way to eliminate the POODLE attack vulnerability is to disable SSL v3, which can be done safely in most sites.
Source: https://habr.com/ru/post/252747/
All Articles