February 3, 2015 at 09:31SSL / TLS Deployment Best Practices, Part 1. Theory
- Transfer
- Tutorial
Part 2 We
share the translation of a useful article on how to properly deploy SSL / TLS on your site. Today - the theory, the second (practical) part will be after the launch.
SSL / TLS is deceivingly a simple technology. It is easy to deploy, and then it just works, without providing an adequate level of security. But the main problem is that SSL / TLS is not easy to deploy correctly. In order for TLS to provide the necessary level of security, system administrators and developers must make additional efforts to configure their servers and develop applications.
In 2009, Qualys SSL Labs began working with SSL. They wanted to understand how TLS was used and make up for the lack of easy-to-use TLS tools, as well as their documentation. Through global research on the use of TLS and online assessment tools, Qualys SSL Labs has achieved some of its goals. But the lack of documentation still makes itself felt. This document is a step towards solving this problem.
1. Private key and certificate
The quality of protection provided by TLS completely depends on the secret key that lays the foundation for security and the certificate that reports the authenticity of the server for its visitors.
1.1 Use 2048-bit private keys
Use 2048-bit RSA or 256-bit ECDSA private keys for all your servers. The keys of such a fortress are safe and will remain secure for a considerable period of time. If you have 1024-bit RSA keys, you should replace them with stronger keys as soon as possible.
1.2 Protect the private key
Treat private keys as important assets, providing access to the smallest possible group of employees. Recommended actions:
• Generate private keys and certificate requests (CSRs) on a trusted computer. Some CAs offer key generation and CSRs for you, but this is not practical.
• Use password protection of private keys to prevent their compromise when they are stored in backup systems. Password protection of private keys does not help on the industrial server, because an attacker can get the keys from the memory process. There are hardware devices that can protect private keys even if the server is compromised, but they are expensive and, therefore, justified only in organizations with high security requirements.
• After compromising, revoke old certificates and generate new keys.
• Renew certificates every year and always with new private keys.
1.3 Ensure coverage of all domain names used
Make sure that your certificates cover all the domain names that you want to use on the site. For example, you have the main domain www.example.com , but you also use the domain www.example.net . Your goal is to avoid a certificate invalidation warning that will confuse your users and weaken their trust.
Even when only one domain name is configured on the server, you need to keep in mind that you cannot control how users come to your site or which links point to it. In most cases, you should make sure that the certificate works with and without WWW (for example, as for example.com and www.example.com) The secure web server must have a certificate valid for each configured domain name. Certificates for the entire domain (Wildcard) have their own advantage, but they should be avoided if their use means providing the private key to a large group of people, for example, system administrators of different organizations. In addition, keep in mind that Wildcard certificates can be used by attackers to transfer vulnerabilities from one website to all other sites that use the same certificate.
1.4. Obtain certificates from a trusted certification authority.
Choose a trusted certification authority (CA) that takes care of your business and security. Consider the following criteria when choosing a CA:
Security Attitude
All CAs are regularly audited (otherwise they would not have the right to operate as a CA), but some of them are more serious about security than others. Finding out which ones are better in this regard is not easy, but one way is to look at their history of security incidents and identify how they reacted to compromises and security incidents and whether they learned from their mistakes.
The main business
CA, in which the issuance of certificates is the main business, will lose business if they do something terribly wrong, and they probably will not neglect the separation of certificates, pursuing potentially more profitable opportunities elsewhere.
Services offered
At a minimum, the selected CA should provide support for the certificate revocation list (CRL) and the OCSP protocol.
Certificate Management Tools
If you need a large number of certificates, then select a certificate authority that will give you good tools for managing them.
Support
Select a certification authority that provides good support when needed.
1.5. Use reliable certificate signing algorithms Certificate
security depends on the length of the private key and the strength of the hash function used. Today, most certificates use the SHA1 algorithm, which is considered weak.
You need to immediately replace all of your certificates using the SHA1 algorithm if they expire after 2015.
share the translation of a useful article on how to properly deploy SSL / TLS on your site. Today - the theory, the second (practical) part will be after the launch.
Introduction
SSL / TLS is deceivingly a simple technology. It is easy to deploy, and then it just works, without providing an adequate level of security. But the main problem is that SSL / TLS is not easy to deploy correctly. In order for TLS to provide the necessary level of security, system administrators and developers must make additional efforts to configure their servers and develop applications.
In 2009, Qualys SSL Labs began working with SSL. They wanted to understand how TLS was used and make up for the lack of easy-to-use TLS tools, as well as their documentation. Through global research on the use of TLS and online assessment tools, Qualys SSL Labs has achieved some of its goals. But the lack of documentation still makes itself felt. This document is a step towards solving this problem.
1. Private key and certificate
The quality of protection provided by TLS completely depends on the secret key that lays the foundation for security and the certificate that reports the authenticity of the server for its visitors.
1.1 Use 2048-bit private keys
Use 2048-bit RSA or 256-bit ECDSA private keys for all your servers. The keys of such a fortress are safe and will remain secure for a considerable period of time. If you have 1024-bit RSA keys, you should replace them with stronger keys as soon as possible.
1.2 Protect the private key
Treat private keys as important assets, providing access to the smallest possible group of employees. Recommended actions:
• Generate private keys and certificate requests (CSRs) on a trusted computer. Some CAs offer key generation and CSRs for you, but this is not practical.
• Use password protection of private keys to prevent their compromise when they are stored in backup systems. Password protection of private keys does not help on the industrial server, because an attacker can get the keys from the memory process. There are hardware devices that can protect private keys even if the server is compromised, but they are expensive and, therefore, justified only in organizations with high security requirements.
• After compromising, revoke old certificates and generate new keys.
• Renew certificates every year and always with new private keys.
1.3 Ensure coverage of all domain names used
Make sure that your certificates cover all the domain names that you want to use on the site. For example, you have the main domain www.example.com , but you also use the domain www.example.net . Your goal is to avoid a certificate invalidation warning that will confuse your users and weaken their trust.
Even when only one domain name is configured on the server, you need to keep in mind that you cannot control how users come to your site or which links point to it. In most cases, you should make sure that the certificate works with and without WWW (for example, as for example.com and www.example.com) The secure web server must have a certificate valid for each configured domain name. Certificates for the entire domain (Wildcard) have their own advantage, but they should be avoided if their use means providing the private key to a large group of people, for example, system administrators of different organizations. In addition, keep in mind that Wildcard certificates can be used by attackers to transfer vulnerabilities from one website to all other sites that use the same certificate.
1.4. Obtain certificates from a trusted certification authority.
Choose a trusted certification authority (CA) that takes care of your business and security. Consider the following criteria when choosing a CA:
Security Attitude
All CAs are regularly audited (otherwise they would not have the right to operate as a CA), but some of them are more serious about security than others. Finding out which ones are better in this regard is not easy, but one way is to look at their history of security incidents and identify how they reacted to compromises and security incidents and whether they learned from their mistakes.
The main business
CA, in which the issuance of certificates is the main business, will lose business if they do something terribly wrong, and they probably will not neglect the separation of certificates, pursuing potentially more profitable opportunities elsewhere.
Services offered
At a minimum, the selected CA should provide support for the certificate revocation list (CRL) and the OCSP protocol.
Certificate Management Tools
If you need a large number of certificates, then select a certificate authority that will give you good tools for managing them.
Support
Select a certification authority that provides good support when needed.
1.5. Use reliable certificate signing algorithms Certificate
security depends on the length of the private key and the strength of the hash function used. Today, most certificates use the SHA1 algorithm, which is considered weak.
You need to immediately replace all of your certificates using the SHA1 algorithm if they expire after 2015.