SSL/TLS Deployment best Practices

Original: https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3.pdf translator: shawn the  R0ck, (self-added to back correction) SSL/TLS deployment Best Practices ivan risti?version 1.3  (17 september 2013) Copyright  ? 2012-2013 qualys ssl labs abstraction: SSL/TLS is a seemingly simple technology. Very easy to deploy and let her run up, but ... Did she really run? The first part is true---SSL is easy to deploy---but she is not so easy to deploy correctly. To ensure that SSL provides security, the user must devote extra effort to configure her. In 2009, we started our work at Ssl labs ( https://www.ssllabs.com/) because we wanted to understand how SSL is being used, and we intend to compensate for the lack of easy-to-use tools and documentation for SSL. We conducted a complete survey of SSL usage and implemented an online detection tool, but the lack of documentation persisted. This document is the first step in solving a document problem. Our goal is to allow the already overburdened system administrators and programmers to spend as little time as possible on a secure site deployment, precisely because of our purpose, so this document may not be complete because it provides simple, practical, easy-to-understand recommendations. For those who want to learn more about the information, you can look at section 6. The security quality provided by the 1.  private key and certificate SSL is entirely dependent on the private key, which is the basis of the security certificate, and the security certificate is an important factor in verifying the server's identity. 1.1  uses a 2048-bit private key to use 2048-bit RSA or equivalent strength ECDSA private keys on all your servers. The length of the key is guaranteed to be secure for a certain amount of time, if you have used 1024-bit RSA, try to replace them. If your requirements must use a key greater than 2048 bits, consider ECDSA because it is a good performance. 1.2  protect private key Private key is an important property, as far as possible to limit access to the private key person. The recommended strategy includes:*  to generate a private key and a CSR (  certificate signing requests) on a trusted computer (Shawn Note: A hardened physical machine). YesSome CAs generate keys and CSRs for you, but doing so    is obviously inappropriate. *  password-protected keys can prevent interception in the backup system *  after discovery is "Day", recall the old certificate, generate a new key and certificate. *  updates the certificate every year, always using the latest private key. 1.3  ensure that all hostnames are overwritten to ensure that your certificate overwrites the site you wish to be visited. For example your main station is www.example.com, but you may still have a www.example.net. Your goal is to avoid invalid certificate warnings, because that will confuse your users and affect your trust. Even if your server has only one hostname configuration, remember that you cannot control what path users are accessing your site from, possibly other links. In most cases, you should ensure that certificates work without the WWW prefix (for example, example.com and www.example.com). So here's the principle: a secure Web server should have a certificate configuration that is normal for all DNS name resolution. Wildcard certificates ( wildcard certificates) have their application scenarios, but should be avoided, as the use of the words implies exposure to many people. In other words, fewer people can access the private key the better. 1.4  obtain a certificate from a trusted CA Choose a reliable CA ( certificate authority) that treats security more seriously, and consider the following factors in choosing a CA:*  attitude towards safety     Most CAS will have regular security audits, but some will be more concerned about security. It's not easy to figure out what's safe for   , but one simple way to do this is to look at the history of their security   , how they are "day" and how they learn from their mistakes. *  actual market share *  business center of gravity *  provide what services    at the bottom line, the CA you choose should provide at least CRLs ( certificate list) and OCSP (   online certificate status protocol) recall mechanism and performance for OCSP services.   CA provides at least domain name verification and extended certificate validation, ideally allowing you to choose the public    key algorithm, most sites today use RSA, but in the future EThe performance benefits of CDSA may become important. *  Certificate management Options If your operational environment is required *  technical support Select a good CA provider 2.  Configure the correct SSL server configuration to ensure that visitors to your site will trust you. 2.1  deploying an effective certificate chain in many deployment scenarios, a single server certificate appears to be insufficient, and multiple certificates require a chain of trust. A common problem is to correctly configure the server certificate but forget to include other required certificates. In addition, although other certificates usually have a long validity period, they also expire, and if they expire, they affect the entire chain. Your CA should provide all the additional required certificates. An invalid certificate chain can cause server certificate invalidation and client browser warning, which is sometimes not so easy to detect because some browsers can reconstruct a complete chain of trust themselves and some do not. 2.2  has 5 protocols in the SSL/TLS family using secure protocols:s slv2, ssl v3, tls v1.0, tls v1.1,  tls v1.2. ( shawn Note:  tls v1.3 is still in the draft stage) * ssl v2 Unsafe, resolute cannot use. ( shawn Note:  openssl and GnuTLS current version    (2014.12.2) does not support Ssl v2) * ssl v3 old and outdated, she lacked some key features , you should not use her unless there is a special good reason   . ( shawn Note:  poodle the emergence of the loophole has been completely abolished SSLv3, many local support   sslv3 because of compatibility issues, gnutls 3.4 will not be supported by default SSLV3) *  tls v1.0 is largely secure, at least without exposing significant security breaches. * tls v1.1 and tls v1.2 do not have a famous security vulnerability exposure. ( shawn note:  due to Edward  snowden exposure to the contents of the NSA "Today Records, Tomorrow declassified" story, so a lot of freedom    The software community and the messenger of the dark web have turned to tls v1.2 's PFS for the past 1 years tls v1.2 should be your main agreement. This version has a huge advantage because she has features that were not in the previous version. If your server platform does not support tls v1.2, make an upgrade plan. If your service provider does not support tls v1.2, ask them to upgrade. For those older clients, you still need to continue to support tls v1.0 and tls v1.1. For a temporary solution, these protocols are still considered safe for most Web sites. 2.3  Use secure Ciphersuites ( shawn Note: True TM does not know how to turn the word, meaning a bunch of cipher sets, including key exchange, encryption algorithm, HMAC, etc.) to secure communication, First make sure that you are in the communication with the peer you want to communicate with. In SSL/TLS, Ciphersuites is the definition of how you communicate securely. They are made up of a variety of components. If one of the components is found to be unsafe, you should switch the knife on the other ciphersuites. Your goal should be to use only authentication and 128-bit encryption or stronger ciphersuites, and the rest should be excluded: * anonymous diffie-hellman ( ADH) package does not provide certification *  Null ciphersuites does not provide encryption *  export key exchange set ( export key exchange suites) is easy to use "Day" certification *  Using Ciphersuites with insufficient strength (such as 40 or 56-bit encryption strength) is also easy to be "day" * RC4 than previously imagined weaker, you should remove, or plan to remove * 3des in the future only provide 108-bit security (or 112-bit, This is less than the recommended minimum of 128 digits. You should get rid of her in the future. 2.4  control Ciphersuite Selection in Ssl v3 and later versions, the client requests a list of ciphersuites that she supports, and the server chooses one from the list to negotiate with the client. Not all servers can handle this process well, and some servers will choose the Ciphersuite supported in the first request list, and the server choosing the right ciphersuites is extremely important for security. 2.5  Support Forward secrecyforward secrecy is a protocol feature that enables you to open a secure session that does not depend on the server's private key. does not support FOrward secrecy Ciphersuites, if the attacker records the communication, then she can decrypt it after obtaining the private key ( shawn Note:  nsa is doing it, so see how important PFS is). You need to prioritize support for the Ecdhe suite, which can be used as an alternative to negotiate fallback ( fallback) with the Dhe suite. 2.6  shutdown client initiated renegotiation in SSL/TLS, renegotiation allows one party to stop exchanging data and renegotiate a secure session. Some scenarios require the server to initiate a renegotiation request, but the client does not initiate a renegotiation request. In addition, there have been denial-of-service attacks on client-initiated renegotiation requests ( shawn annotations:  Each renegotiation request server is 15 times times more computationally than the client). 2.7  reducing the risk of known vulnerabilities is nothing completely secure, and many protection scenarios become security issues over time. Best practice is to keep an eye on what's happening in the world of information security and then take the necessary steps. The simplest thing is that you should hit every patch as soon as possible. Some of the following questions should be brought to your attention:*  the unsecured renegotiation    renegotiation feature was found to be unsafe in 2009 and the protocol needs to be updated. Today, most manufacturers have    repaired, at least one temporary solution is provided. Unsafe renegotiation is dangerous because she is easily exploited by   . *  off TLS compression     2012, crime attack [6] shows us that the information disclosure caused by TLS compression can be used by attackers with    to restore sensitive data ( such as Session cookies). Only a few clients support TLS compression,   so even if you turn off TLS compression will not affect the user experience of the knife. *  reduce the risk of information leakage from HTTP compression     2 a crime variant attack was exposed in 2013, unlike crime for TLS compression, time and breach   The vulnerability is in the return packet for compressed HTTP. HTTP compression is important for many companies, and the    problem is not easy to spot, and the risk reduction scenario may require a change in the business code. For time and breach attacks, the effect is equivalent to CSRF as long as the attacker has enough reason to attack you. *  Close Rc4  rc4 cihpeRsuites has been considered unsafe and should be shut down. At present, the best    of the attackers need millions of requests, so the harm is relatively low, we look forward to the future with improved    attack tactics. *  Note the Beast Attack of Beast attack     2011 exposure was a 2004 target for tls 1.0 or earlier but was then recognized    For a loophole that is hard to exploit ...... 3.  performance The security in this document is a major concern, but we must also pay attention to the problem of knife performance. A security service that does not meet performance requirements will undoubtedly be abandoned. However, because SSL configuration usually does not lead to significant performance overhead, we limit the discussion to common configuration issues. 3.1  do not use high-intensity private keys in the process of establishing a secure link key negotiation, the maximum cost is determined by the size of the private key, too short to use the key is not safe, the use of the key too long will lead to some scenarios unbearable performance degradation. For most Web sites, using more than 2048-bit keys is a waste of the CPU and impacting the user experience. 3.2  ensure correct use of session reuse session reuse is a performance optimization technique that allows time-consuming cryptographic operations to be reused over a period. A scenario that shuts down or does not have a session reuse mechanism can cause severe performance degradation. 3.3  using Persistent link (HTTP) Many of today's SSL overhead is not from the CPU's cryptographic operations, but rather the network latency. An SSL handshake is established after the end of the TCP handshake, she needs more exchange packet, in order to minimize network latency, you should enable HTTP persistence ( keep-alives), and she lets your users send multiple HTTP requests on a TCP link. 3.4  Open cache for public resources (HTTP) When you start using SSL communication, the browser assumes that all traffic is sensitive and caches some specific resources in memory, but once you close the browser, the content is lost. To achieve performance, open a long-term cache for some resources by adding "cache-control: public" to return to the header to mark the browser as a public resource (a slice). The 4.  Application Design (HTTP) HTTP protocol and web-related platforms continue to evolve after the advent of SSL. The result of evolution is that some of today's included features are bad for cryptography. In this section, we will list these features, including how to use them safely. 4.1 100% 'sEncrypt your site in fact, the idea that encryption is an alternative is probably one of the most serious security issues today. Let's take a look at the following questions:*  site does not need ssl*  site has SSL but not mandatory use *  site mixed with SSL and non-SSL content, and sometimes even on the same page *  site programming error causes SSL to be "Day" If you know what you're doing, these problems can be confrontational, and the most straightforward and effective way is to force all content encryption. 4.2  avoid mixed content mixed content page is the premise of using SSL, but some content (such as JavaScript files, pictures, CSS) is transmitted by non-SSL way. These pages are unsafe, such as a man-in-the-middle attack that can hijack these JavaScript resources and user sessions. Even if you follow the previous recommendations to encrypt all content, but also do not exclude from third-party web site resources are not encrypted. 4.3  understand that third-party Web sites often use JavaScript code for third-party services, Google analytics is a widely used example. The included third-party code creates an implicit trust link that allows a third party to take full control of your site. Third parties themselves may not be malicious, but they are easily targeted by attackers. The reason is simple, if a large third-party provider is "Day", the attacker can use this path to "day" her users. If you adopt section 4.2 's advice, at least your third-party link will be encrypted to prevent a man-in-the-middle attack. In addition, you should take a closer look at what services your site uses and understand the risks you are willing to take on. 4.4  security cookies ......... ................ 4.5  deployment HSTs ......... ................ 4.6  caching of sensitive content as cloud-based applications increase, you must differentiate between open resources and sensitive content. ............. 4.7  Make sure there are no other vulnerabilities SSL does not represent security, the design of SSL is just one aspect of security-the confidentiality and integrity of the communication process, but there are other threats you must face. 5. validation ...... Parameter tuning and testing, you can also consider using the online tool:https://www.ssllabs.com/ssltest/...........6.  advanced topics These topics are beyond the scope of this document, and they require the SSL/TLS and public key architecture (PKI)With a deeper understanding, these issues remain controversial. * extended validation Certificate   ev Certificate is a more reliable certificate for offline detection after issue. EV certificates are more difficult to forge and provide better    security. * public key pinning  public key pinning is designed to limit which CAs can be used for website operations to sign     issued a certificate. This feature was developed by Google and is now hard-coded into chrome,   and proves to be valid. 2 x proposals:1, public key pinning extension for http:http://tools.ietf.org/html/ draft-ietf-websec-key-pinning2, trust assertions for certificate keyshttp://tack.io/ DRAFT.HTML* ECDSA private key    virtually all Web sites rely on the RSA private key. This algorithm is the basis of web communication security. For a    some reason, we are turning from 1024 bits to 2048-bit RSA keys. Increasing the key length may result in    performance issues. Elliptic curve Cryptography (ECC) uses different mathematics and can have    strong security under a smaller key length. RSA keys can be replaced by ECDSA, there are only a handful of CAs that support ECDSA, but I    expect more in the future. * ocsp stapling  ocsp stapling is a revamped OCSP protocol that allows the revocation of information from the binding certificate itself, directly serving the    server and browser. This improves performance without the need to remotely validate expired certificates like OCSP. The original version of the revised document was released on February 24, 2012. This section tracks the time the document was modified, starting with 1.3. version 1.3  (17 september 2013) The following changes were made in this version:? recommend  Replacing 1024-bit certificates straight away.?  recommend against supporting ssl v3.?  remove the recommendation to use rc4 to mitigate the beast  attack server-side.?  recommend that rc4 is disabled.?  recommend that 3des is disabled in the near future.?  Warn about the CRIME attack variations  (Time and breach).?  recommend supporting forward secrecy.?  add discussion of ecdsa certificates. Thanks for the valuable feedback and the drafting of this document, special thanks to marsh ray  ( Phonefactor), naskooskov  (Google),  adrian f. dimcev and Ryan hurst (GlobalSign). And thanks to other people who have generously shared information about security and cryptography. Although I wrote this document, it came from the entire security community. About Ssl labs ..... ........ About Qualys ........... [1] on the security of rc4 in tls and wpa  (Kenny  paterson et al.;  13 march 2013) http://www.isg.rhul.ac.uk/tls/[2] deploying forward secrecy  (qualys security labs; 25 june 2013) https://community.qualys.com/blogs/securitylabs/ 2013/06/25/ssl-labs-deploying-forward-secrecy[3] increasing dhe strength on apache  2.4.x  (ivan risti? ') s blog; 15 august 2013) http://blog.ivanristic.com/2013/08/ increasing-dhe-strength-on-apache.html[4] tls renegotiation and denial of  service attacks  (qualys security labs blog, october 2011) https:// Community.qualys.com/blogs/securitylabs/2011/10/31/tls-renegotiation-and-denial-of-service-attacks[5] ssl  and TLS Authentication Gap Vulnerability Discovered  (qualys security labs blog; november 2009) https://community.qualys.com/blogs/securitylabs/2009/11/05/ ssl-and-tls-authentication-gap-vulnerability-discovered[6] crime: information leakage  attack against ssl/tls  (qualys security labs blog; september 2012) HTTPS://COMMUNITY.QUALYS.COM/BLOGS/SECURITYLABS/2012/09/14/CRIME-INFORMATION-LEAKAGE-ATTACK-AGAINST-SSLTLS[7]  Defending against the BREACH Attack  (qualys security labs; 7  august 2013) https://community.qualys.com/blogs/securitylabs/2013/08/07/ defending-against-the-breach-attack[8] mitigating the beast attack on tls  ( qualys security labs blog; october 2011) https://community.qualys.com/blogs/ Securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls[9] is beast still a threat ?  (Qualys security labs; 10 september 2013) https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat 

SSL/TLS Deployment best Practices