March 11, 2015 at 13:37SSL / TLS Deployment Best Practices, Part 2. Configuration
- Transfer
- Tutorial
We present to your attention the second part of the translation of the article on deploying SSL / TLS, the first part can be read here.
2. Configuration
If you configured correctly on the TLS server, you can be sure that the data on your site is displayed correctly for site visitors, only safe algorithms are used and all known vulnerabilities are fixed.
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 these:
• SSL v2 is unsafe and should not be used.
• SSL v3 is unsafe 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 were not available in earlier versions. If your server (or any intermediate device) does not support TLS v1.2, then plan to upgrade it in an accelerated mode. If your service providers do not support TLS v1.2, request that they upgrade their system.
To support older clients, you should continue to support TLS v1.0 and TLS v1.1 for some time to come. With some workarounds, these protocols can still be considered quite secure for most websites.
2.3. Use secure encryption algorithms
To securely exchange data, you must first make sure that you are communicating directly with the right person (and not through someone who will eavesdrop). SSL and TLS use encryption algorithms to determine how securely data is exchanged. They consist of various building blocks. If one of the building blocks has poor security, 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:
• Kits with weak encryption algorithms (usually from 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 checking the potential negative impact on compatibility.
• 3DES provides about 112 bits of security. This is below the recommended minimum of 128 bits, but it is still a pretty strong algorithm. The big practical problem is that 3DES is much slower than alternatives. Therefore, we do not recommend it to improve 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 organize a secure communication channel. Not all servers can do this well, as some choose the first supported algorithm from the list. Therefore, choosing the right encryption algorithm is critical to security.
2.5. Support Forward Secrecy.
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. It is necessary to support and prefer ECDHE (the abbreviation ECDHE stands for "ephemeral Diffie-Hellman algorithm using elliptic curves") encryption algorithms. To support a wider range of customers, you should also use DHE as a fallback after ECDHE.
2.6. Disable Renegotiation on Customer Initiative
In SSL / TLS, renegotiation allows parties to stop the exchange of data in order to re-initiate it for 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. Reducing known issues
At some point, security issues may arise with any product. Well, if you are always up to date with events in the world of information security. At the very least, you should keep track of the security releases of the products you use and install them as soon as they become available.
Keep track of what is happening in the security world and adapt to the situation when it is necessary. At the very least, you should immediately install patches to cover detected vulnerabilities as soon as they become available. Please note the following questions:
- Disable TLS compression
In 2012, a CRIME attack showed how TLS compression can be used by attackers to identify details of sensitive data (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. Currently, we 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 larger in the future. Before removing RC4, check to see if your existing users will be affected; in other words, check if you have clients that only support RC4.
- Stay on top of BEAST attack
A successful BEAST attack is like a hack session. Unfortunately, mitigating the server threat requires RC4, which is no longer recommended. Because of this, and also because the BEAST attack is now significantly reduced on the client side, we no longer recommend mitigation on the server by using RC4. In some situations where 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 the model of its threats.
- Disable SSL v3
SSL v3 is vulnerable to the POODLE attack, which was discovered in October 2014. The best way to fix the vulnerability of the POODLE attack is to disable SSL v3, which can be done safely in most sites.
2. Configuration
If you configured correctly on the TLS server, you can be sure that the data on your site is displayed correctly for site visitors, only safe algorithms are used and all known vulnerabilities are fixed.
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 these:
• SSL v2 is unsafe and should not be used.
• SSL v3 is unsafe 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 were not available in earlier versions. If your server (or any intermediate device) does not support TLS v1.2, then plan to upgrade it in an accelerated mode. If your service providers do not support TLS v1.2, request that they upgrade their system.
To support older clients, you should continue to support TLS v1.0 and TLS v1.1 for some time to come. With some workarounds, these protocols can still be considered quite secure for most websites.
2.3. Use secure encryption algorithms
To securely exchange data, you must first make sure that you are communicating directly with the right person (and not through someone who will eavesdrop). SSL and TLS use encryption algorithms to determine how securely data is exchanged. They consist of various building blocks. If one of the building blocks has poor security, 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:
• Kits with weak encryption algorithms (usually from 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 checking the potential negative impact on compatibility.
• 3DES provides about 112 bits of security. This is below the recommended minimum of 128 bits, but it is still a pretty strong algorithm. The big practical problem is that 3DES is much slower than alternatives. Therefore, we do not recommend it to improve 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 organize a secure communication channel. Not all servers can do this well, as some choose the first supported algorithm from the list. Therefore, choosing the right encryption algorithm is critical to security.
2.5. Support Forward Secrecy.
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. It is necessary to support and prefer ECDHE (the abbreviation ECDHE stands for "ephemeral Diffie-Hellman algorithm using elliptic curves") encryption algorithms. To support a wider range of customers, you should also use DHE as a fallback after ECDHE.
2.6. Disable Renegotiation on Customer Initiative
In SSL / TLS, renegotiation allows parties to stop the exchange of data in order to re-initiate it for 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. Reducing known issues
At some point, security issues may arise with any product. Well, if you are always up to date with events in the world of information security. At the very least, you should keep track of the security releases of the products you use and install them as soon as they become available.
Keep track of what is happening in the security world and adapt to the situation when it is necessary. At the very least, you should immediately install patches to cover detected vulnerabilities as soon as they become available. Please note the following questions:
- Disable TLS compression
In 2012, a CRIME attack showed how TLS compression can be used by attackers to identify details of sensitive data (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. Currently, we 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 larger in the future. Before removing RC4, check to see if your existing users will be affected; in other words, check if you have clients that only support RC4.
- Stay on top of BEAST attack
A successful BEAST attack is like a hack session. Unfortunately, mitigating the server threat requires RC4, which is no longer recommended. Because of this, and also because the BEAST attack is now significantly reduced on the client side, we no longer recommend mitigation on the server by using RC4. In some situations where 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 the model of its threats.
- Disable SSL v3
SSL v3 is vulnerable to the POODLE attack, which was discovered in October 2014. The best way to fix the vulnerability of the POODLE attack is to disable SSL v3, which can be done safely in most sites.