Share transfer of useful articles on how to properly deploy SSL / TLS on your site. Today - the theory, the second (practical) part will be after launch.
introduction
SSL / TLS is deceptively seems simple technology. It is simple to deploy, and then it just works, without providing an adequate level of security. But the main problem lies in the fact that SSL / TLS are not easy to deploy. To TLS provides the necessary security, system administrators and developers should make an extra effort to set up their own servers and application development.
In 2009, Qualys SSL Labs began work with SSL. They wanted to understand how to use TLS, and to remedy the lack of easy-to-use tools TLS, as well as their documentation. With global research use TLS, as well as through online assessment tools Qualys SSL Labs has made some of its goals. But the lack of documentation is still making itself felt. This document is a step towards addressing this problem.
1. The private key and certificate
The quality of protection provided by TLS depends entirely on the secret key, laying the groundwork security, and a certificate of authenticity that tells the server to its visitors.
1.1 Use a 2048-bit private keys
Use a 2048-bit RSA and 256-bit ECDSA private key for all your servers. The keys of this strength are safe and will remain safe for a significant period of time. If you have a 1024-bit RSA keys, you should replace them with stronger keys as soon as possible.
1.2 Protection of the private key
Treat your private keys as an important asset, providing access to the lowest possible group of employees. Recommended action:
• Generate private keys and certificate requests (CSRs) on a trusted computer. Some offer a CA key generation and CSRs for you, but it is impractical.
• Use password protection for private keys, to prevent compromise in cases where they are stored on the backup system. Password protection for the private key does not work on the production server, because an attacker can get the keys from the process of memory. There are hardware devices that can protect the secret key, even if the server is compromised, but they are expensive and thus, only justified in organizations with high security requirements.
• After the compromise revoke old certificates and generate new keys.
• Update certificates every year and always with the new private key.
1.3 Ensure coverage of all used domain names
Make sure that your certificates cover all the domain names that you want to use on the site. For example, you have a primary domain www.example.com, but you are also using a domain www.example.net. Your goal - to avoid warnings about invalid certificates, which will confuse your users and weaken their confidence.
Even when the server is configured, only one domain name, you need to keep in mind that you can not control how users come to your site or any links to his point. In most cases, you should make sure that the certificate works with and without WWW (for example, for example.com and www.example.com). Secure Web server must have a certificate that is valid for each configured domain name. Certificates for the entire domain (Wildcard) have the advantage, but should be avoided if their use is to provide the private key large group of people, such as system administrators to different organizations. Also, keep in mind that Wildcard certificates can be used by attackers to transmit vulnerability from one web site to all other sites that use the same certificate.
1.4. Purchase certificates from a trusted Certification Authority
Choose a reputable certification authority (CA), who take care of their business and security. Consider the following criteria when choosing CA:
Related to safety
All CA pass regular audits (otherwise they would not have the right to act as a CA), but some are more serious about security than others. Find out which one is better in this respect is not easy, but one way is to study the history of their security incidents and to identify how they react to compromise and security incidents and whether they studied their mistakes.
The main activity
CA, in which the issue of certificates is the main activity, will lose business if they do something horribly wrong, and they probably will not be neglected division of certificates, pursuing potentially more lucrative opportunities elsewhere.
services offered
As a minimum, the selected CA should provide support for Certificate Revocation List (CRL) and Protocol OCSP.
Tools for managing certificates
If you need a large number of certificates, select the CA that will give you good tools to manage them.
support
Select the CA that provides good support when you need it.
1.5. Use reliable algorithms to sign the certificate
Security certificate depends on the length and strength of the private key used by the hash function. Today, most of the certificates used algorithm SHA1, which is considered weak.
You need to immediately replace all of your certificates using the algorithm SHA1, if they expire after 2015.
introduction
SSL / TLS is deceptively seems simple technology. It is simple to deploy, and then it just works, without providing an adequate level of security. But the main problem lies in the fact that SSL / TLS are not easy to deploy. To TLS provides the necessary security, system administrators and developers should make an extra effort to set up their own servers and application development.
In 2009, Qualys SSL Labs began work with SSL. They wanted to understand how to use TLS, and to remedy the lack of easy-to-use tools TLS, as well as their documentation. With global research use TLS, as well as through online assessment tools Qualys SSL Labs has made some of its goals. But the lack of documentation is still making itself felt. This document is a step towards addressing this problem.
1. The private key and certificate
The quality of protection provided by TLS depends entirely on the secret key, laying the groundwork security, and a certificate of authenticity that tells the server to its visitors.
1.1 Use a 2048-bit private keys
Use a 2048-bit RSA and 256-bit ECDSA private key for all your servers. The keys of this strength are safe and will remain safe for a significant period of time. If you have a 1024-bit RSA keys, you should replace them with stronger keys as soon as possible.
1.2 Protection of the private key
Treat your private keys as an important asset, providing access to the lowest possible group of employees. Recommended action:
• Generate private keys and certificate requests (CSRs) on a trusted computer. Some offer a CA key generation and CSRs for you, but it is impractical.
• Use password protection for private keys, to prevent compromise in cases where they are stored on the backup system. Password protection for the private key does not work on the production server, because an attacker can get the keys from the process of memory. There are hardware devices that can protect the secret key, even if the server is compromised, but they are expensive and thus, only justified in organizations with high security requirements.
• After the compromise revoke old certificates and generate new keys.
• Update certificates every year and always with the new private key.
1.3 Ensure coverage of all used domain names
Make sure that your certificates cover all the domain names that you want to use on the site. For example, you have a primary domain www.example.com, but you are also using a domain www.example.net. Your goal - to avoid warnings about invalid certificates, which will confuse your users and weaken their confidence.
Even when the server is configured, only one domain name, you need to keep in mind that you can not control how users come to your site or any links to his point. In most cases, you should make sure that the certificate works with and without WWW (for example, for example.com and www.example.com). Secure Web server must have a certificate that is valid for each configured domain name. Certificates for the entire domain (Wildcard) have the advantage, but should be avoided if their use is to provide the private key large group of people, such as system administrators to different organizations. Also, keep in mind that Wildcard certificates can be used by attackers to transmit vulnerability from one web site to all other sites that use the same certificate.
1.4. Purchase certificates from a trusted Certification Authority
Choose a reputable certification authority (CA), who take care of their business and security. Consider the following criteria when choosing CA:
Related to safety
All CA pass regular audits (otherwise they would not have the right to act as a CA), but some are more serious about security than others. Find out which one is better in this respect is not easy, but one way is to study the history of their security incidents and to identify how they react to compromise and security incidents and whether they studied their mistakes.
The main activity
CA, in which the issue of certificates is the main activity, will lose business if they do something horribly wrong, and they probably will not be neglected division of certificates, pursuing potentially more lucrative opportunities elsewhere.
services offered
As a minimum, the selected CA should provide support for Certificate Revocation List (CRL) and Protocol OCSP.
Tools for managing certificates
If you need a large number of certificates, select the CA that will give you good tools to manage them.
support
Select the CA that provides good support when you need it.
1.5. Use reliable algorithms to sign the certificate
Security certificate depends on the length and strength of the private key used by the hash function. Today, most of the certificates used algorithm SHA1, which is considered weak.
You need to immediately replace all of your certificates using the algorithm SHA1, if they expire after 2015.
No comments:
Post a Comment