SSL/TLS Deployment best Practices

Original: https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3.pdf Translator: Shawn the R0ck, (after correcting themselves plus to the back) SSL /TLS Deployment Best Practices Ivan Risti?version 1.3 (September) 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. We started working on SSL Labs in 2009 because we wanted to understand exactly how SSL was being used, and we also intended to compensate for the lack of easy-to-use tools and documentation for SSL. https://www.ssllabs.com/ 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, you can look at section 6. 1. Private keys and certificates SSL provides a security quality that 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 identity of the server. 1.1 Use a 2048-bit private key to use a 2048-bit RSA or equivalent-strength ECDSA private key 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. Recommended strategies include: * Generate a private key and a CSR (Certificate Signing requests) on a trusted computer (Shawn Note: A hardened physical machine). There are some CAs that generate keys and CSRs for you, but this 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. * Renew the certificate every year, always use the latest private key. 1.3 Make sure to overwrite all host names to ensure that your certificate is overwrittenTo the site you want 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: * Most CAs have regular security audits, but some will be more concerned about security. Figuring out which approach to security is not an easy task, but it's a simple way to look at their security history, how they are "day" and how to learn from their mistakes. * Actual market share * Business focus * What services are available at the bottom line, the CA you choose should provide at least the CRL (Certificate List) and OCSP (Online Certificate Status Protocol) recall mechanism as well as for OCS  The performance of the P service. At a minimum, the CA provides domain name validation and extended certificate validation, ideally allowing you to choose your own public key algorithm, most of which use RSA today, but the performance benefits of ECDSA in the future 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 A valid 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 easy to detect because some browsers can self-A complete chain of trust is reconstructed and some are not. 2.2 There are 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 phase) * SSL v2 unsafe, resolute cannot use. (Shawn Note: The current version of OpenSSL and GnuTLS (2014.12.2) does not support SSL v2) * SSL v3 old and outdated, she lacks some key features, you should not use her unless there are particularly good reasons. (Shawn Note: Poodle the emergence of the vulnerability of the 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 vulnerabilities. * TLS v1.1 and TLS v1.2 are not known to expose security vulnerabilities. (Shawn Note: Due to Edward Snowden's exposure to the NSA "Today Records, Tomorrow decryption" story, so a lot of free software community and dark nets messenger in the past 1 years to the TLS v1.2 PFS) The 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 Using a 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 communications, first make sure that you are in 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 ciphersuites that provide authentication and 128-bit encryption or stronger, and others should be excluded: * Anonymous Diffie-hellman (ADH) kit does not provide authentication * NULL Ciphersuites does not provide encryption * Export key exchange Kit (exported key exchange suites) uses the easy to be "day" Authentication * makesCiphersuites 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 in the future * 3DES only provide 108-bit security (or 112-bit, see the specific situation), This is also less than the recommended minimum of 128 bits. 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 can open a secure session that does not depend on the server's private key. The ciphersuites of forward secrecy is not supported, and if the attacker logs the communication, she can decrypt it after obtaining the private key (Shawn Note: The NSA is doing this, 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 Turn off client initiated renegotiation in SSL/TLS, renegotiation allows a 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 Note: Each renegotiation request server is 15 times times more computationally than the client). 2.7 Reducing the risk of known vulnerabilities nothing is 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: * Closing the unsecured renegotiation feature was found to be unsafe in 2009 and the protocol needs to be updated. Most manufacturers have repaired today, at least with a temporary solution. Unsafe renegotiation is dangerous because she is easily exploited. * Off TLS compression 2012, the crime attack [6] showed us that the information disclosure caused by TLS compression could be used by attackers to restore sensitive data (such as session cookies) to the part of the attacker. Only several clients support TLS compression, so even turning off TLS compression does not affect the user experience of the knife. * Reduce the risk of information leakage from HTTP Compression 2 x CrimThe variant of E was exposed in 2013, unlike crime for TLS compression, time and breach vulnerabilities are for compressed HTTP return packets. HTTP compression is important for many companies, and the problem is not easy to spot, and risk-reducing scenarios may require modifications to 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 closed. At present, the best situation for attackers requires millions of requests, so the harm is relatively low, we look forward to the future with improved attack tactics. * Note that the Beast Attack of the Beast attack in 2011 was one of 2004 's vulnerabilities for TLS 1.0 or earlier but was considered difficult 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 during 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 links (HTTP) Many of today's SSL excesses are not from the CPU's cryptographic operations, but 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). 4. The application Design (HTTP) HTTP protocol and web-related platforms continue to evolve after the advent of SSL. The result of evolutionSome of the features that are included today are already bad for encryption. In this section, we will list these features, including how to use them safely. 4.1 100% Encryption your site in fact, the idea of "encryption is an alternative" is probably one of the most serious security issues today. Let's take a look at the following questions: * website does not need ssl* website has SSL but not mandatory use * website mixed with SSL and non-SSL content, sometimes even on the same page * Website programming error causes SSL to be "Day" if you know what you're doing, these problems can be confrontational, The most direct and effective way is to force all content encryption. 4.2 A page that avoids mixed content mixed content is used with SSL, but some content (such as JavaScript files, images, CSS) is transmitted in a non-SSL manner. 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 Understanding third-party site sites often use JavaScript code for third-party services, and 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 recommendations, at least your third-party links are encrypted to prevent man-in-the-middle attacks. 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 Safe cookies ....... .................. 4.5 The Department of HSTs ................ ........ 4.6 Caching off 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, and SSL is designed to cover only 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 may 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 need to have a deeper understanding of SSL/TLS and public key architecture (PKI)These issues are still controversial. * Extended Validation Certificate EV certificate offline detection after issue is a more reliable certificate. EV certificates are more difficult to forge and provide better security. * Public key pinning public key pinning is designed for Web site operations to restrict which CAs can issue certificates for their sites. This feature was developed by Google and is now hard-coded into the Chrome browser and proves to be valid. 2 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 In fact, all Web sites rely on RSA private keys. This algorithm is the basis of web communication security. For some reason, we are turning from 1024 bits to a 2048-bit RSA key. Increasing the key length may cause performance problems. Elliptic curve Cryptography (ECC) uses different mathematics and can have strong security under a smaller key length. RSA keys can be replaced by ECDSA, and there are only a handful of CAs that support ECDSA, but we expect more in the future. * OCSP stapling OCSP stapling is a revised OCSP protocol that allows you to recall the information of the binding certificate itself, directly serving the server and the 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 (September) 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 was disabled in the a 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.; march) http://www.isg.rhul.ac.uk/tls/[2] Deployin G Forward secrecy (Qualys Security Labs; June) 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; August) 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) 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) 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) 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 20 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) Https://community.qualys.com/blogs/securitylabs/2011/10/17/mitigating-the-beast-attack-on-tls[9] is BEAST still a Threat? (Qualys Security Labs; September) https://community.qualys.com/blogs/securitylabs/2013/09/10/ Is-beast-still-a-threat

SSL/TLS deployment best practices