SSL and TLS deployment practice guide
SSL and TLS deployment practice guide

In TLS, all security starts with the encrypted identifier of the server, which requires a strong private key to prevent attackers from performing simulated attacks. It is also important to have a valid and strong certificate, which grants the private key to represent a specific hostname.

For most websites, the security provided by a 2048-bit RSA key is sufficient. RSA public key algorithm is widely used, which makes it a safe default choice. For a 2048-bit RSA key, approximately 112-bit keys can be provided. If you want more security, RSA keys cannot be extended well. For example, to obtain a 128-bit key, you need a 3072-bit RSA key, which is slower. The elliptic curve digital signature algorithm ECDSA shows you better security and better performance. Taking ECDSA256 as an example, the ECDSA key provides a 128-bit key.

How to protect the private key

(1) The private key must be generated on a trusted computer with sufficient entropy.

(2) Password protection must be set for the key from the beginning to prevent attacks when stored in the backup system. The private key password will not have much security guarantee in actual operation, because the attacker can retrieve the key from the process memory at any time. With hardware devices (hardware security modules or HSMs), private keys can be protected even if the server is damaged, but these devices are expensive, so they are only suitable for institutions that have strict security requirements for security.

(3) After being attacked, revoke the old certificate and generate a new key.

(4) Renew the certificate every year. It is best that your device can automatically perform this process, so certificates with shorter life cycles are safer in practice.

(5) Unless there are special circumstances, every time a new certificate is obtained, a corresponding new private key should be generated.

Make sure the certificate covers the website used

Make sure that your certificate covers the website you use to avoid invalid certificate warnings.

Even if you only have one domain name, you should ensure that the certificate is related to the www prefix, for example, example.com and www.example.com. Each DNS name of the secure web server should be configured with a valid certificate. Also, the fewer people who access the private key, the better.

Reliable CA to obtain certificate

When choosing CA, please pay attention to the following 5 aspects:

(1) The safety status of all CAs is subject to regular review;

(2) Choose an organization that mainly focuses on CA and provides various functional support;

(3) The CA you choose should provide support for certificate revocation list (CRL) and online certificate status agreement (OCSP) revocation;

Use a powerful certificate signature algorithm

Certificate security depends on the strength of the private key used to sign the certificate and the strength of the hash function used in the signature. It turns out that most certificates rely on the SHA1 hash function, but it has now been proven to be insecure. Therefore, the current trend is to transition to SHA256. As of the end of 2016, SHA1 certificates will no longer be supported by the website.

TLS server configuration

Use a complete certificate chain

Invalid certificate chains invalidate server certificates and cause browsers to issue security warnings. In most SSL and TLS deployments, only server certificates require two or more certificates to establish a complete chain of trust.

Use security protocols

There are five protocols in the SSL / TLS series: SSL 2, SSL 3, TLS 1.0, TLS 1.1 and TLS 1.2.

SSL2 and SSL3 are very outdated, it is recommended not to use. In theory, TLS 1.0 should not be used, but it is often used in practice. As of now, neither TLS 1.1 nor 1.2 has any security issues, but only 1.2 provides modern encryption algorithms.

So TLS 1.2 should be the main protocol used because it is the only version that provides modern authentication encryption (also known as AEAD).

Choose the best cipher suite

The cipher suite is a combination of algorithms used to negotiate security settings during the SSL / TLS handshake. After the exchange of ClientHello and ServerHello messages, the client sends a password support suite for the priority list. The server then responds with the cipher suite selected from the list. The cipher suite is the following combination:

Key exchange algorithm (RSA, DH, ECDH, PSK);

Authentication algorithm (RSA, DSA);

Batch encryption algorithm (AES, Camellia, ARIA);

Message authentication code algorithm (SHA-256);

However, several obsolete encryption primitives must be banned:

(1) The anonymous Diffie-Hellman (ADH) suite does not provide authentication.

(2) NULL encryption suite does not provide encryption.

(3) The export encryption suite is not secure during connection negotiation, but it can also be used against servers with more powerful suites (FREAK attacks).

(4) The use of weak passwords (usually 40 and 56 digits) can be easily attacked.

(5) RC4 is not safe.

(6) 3DES is slow and vulnerable to attack.

In the protocol version of SSL 3 and later, the client will first submit a series of supported cipher suites, and the server selects a suite for connection from the list. However, not all servers can perform this operation, and some will always choose the first supported suite from the client list, so the server actively chooses the best available encryption suite to achieve the best security.

Forward secrecy

Forward security or forward secrecy (English: Forward Secrecy, abbreviation: FS), sometimes referred to as perfect forward security [1] (English: Perfect Forward Secrecy, abbreviation: PFS), is the security of communication protocols in cryptography Attribute refers to the long-term use of master key leakage will not lead to the past session key leakage. [2] Forward security can protect past communications from being threatened by passwords or keys in the future. If the system has forward security, it can guarantee the security of historical communication when the master key is leaked, even if the system is actively attacked.

Use a powerful key exchange algorithm

To ensure the safety of data transmission and storage, the transmitted data is usually encrypted and stored or transmitted. After receiving the data, the receiver decrypts the ciphertext and restores the plaintext. The commonly used encryption algorithms mainly include symmetric key encryption algorithm and asymmetric key encryption algorithm. In-secure data communication, both parties must have an encrypted key and a decrypted key. Once the communication key is leaked or cracked, the information encrypted by it will be leaked. Therefore, how to exchange or negotiate communication keys securely becomes a crucial issue, so how to ensure the security of the keys, especially the secure password exchange, has become the core issue of secure information exchange in e-commerce.

In 2015, researchers discovered an SSL encryption security vulnerability LogJam. The LogJam vulnerability will affect any server and all browsers that support DHE_EXPORT passwords, including the latest versions of IE, Chrome, Firefox, Safari, etc. Then they evaluated that academic hackers can crack 768-bit keys, while state-supported hackers can break through 1024-bit keys. For security reasons, if DHE is deployed, at least a 2048-bit key must be configured.

Verification before proper deployment

Maybe when deploying according to the method of this article, many software and hardware configurations have new versions. It is recommended that you first make a comprehensive assessment of your SSL / TLS to ensure the safety of operation. It is recommended that you use this link to carry out test.

Precautions during practice deployment

Avoid blind pursuit of excessive safety

Using a password that is too short is certainly insecure, but using a password that is too long is not necessarily safe, for example, it will lead to complicated operations. For most websites, using an RSA key stronger than 2048 bits and an ECDSA key stronger than 256 bits will waste CPU power and may damage the user experience. Similarly, increasing the strength of temporary key exchange has little benefit for DHE of 2048 bits and ECDHE of 256 bits, and there is no obvious benefit of using encryption higher than 128 bits.

Use session reuse mechanism

Because the asymmetric operation of the SSL handshake, whether it is RSA or ECDHE, consumes performance, to improve performance, for SSL connections that have previously been handshake, reduce the handshake round time trip and operations as much as possible.

SSL provides 2 different session multiplexing mechanisms.

(1) session id session multiplexing;

(2) Session ticket session multiplexing, Session id session multiplexing has two shortcomings, one is that the server will accumulate a large number of sessions, especially in actual use, the session aging time is configured to several hours, this situation is very heavy high.

Use WAN optimization

WAN optimization, also commonly referred to as WAN acceleration, is to provide high-performance remote data access through some optimization techniques, thereby improving the performance of applications on the WAN.

Cache public content

When communicating via TLS, the browser may treat all traffic as sensitive data. In this way, they usually use memory to cache certain resources, but once the browser is closed, all content may be lost. To achieve performance improvements and achieve long-term caching of certain resources, public resources (such as images) can be marked as public.

Enable OCSP Stapling

OCSP (Online Certificate Status Protocol) is usually provided by the CA and is used to verify whether the certificate is legal and valid online in real time, so that the client can send a query request to the verification address of the CA according to the OCSP information in the certificate to check whether the certificate is valid.

And OCSP Stapling, as the name implies, is to entrust the server to query the OCSP interface. In addition to directly querying the OCSP information, the server can only perform a few queries and cache the response. When a client initiates a TLS handshake request to the server, the server sends the OCSP information of the certificate to the client along with the certificate chain, thereby avoiding the blocking problem that would arise from client authentication. Since the OCSP response cannot be forged, this process will not create additional security issues.

Use fast encryption primitives

Use a CPU that supports hardware-accelerated AES whenever possible. If you want to further improve performance, consider using ECDSA keys.

HTTP encryption

Encrypt the entire website. The problem of encryption may be one of the biggest security problems today, such as:

(1) Website without TLS

(2) Sites with TLS but not TLS

(3) Sites that mix TLS and non-TLS content, sometimes even on the same page

(4) Wrong programming will break TLS

Delete mixed content

Even if you encrypt the entire website, some unencrypted resources may still be retrieved from third-party websites. Mixed content pages are pages that are transmitted through TLS but contain resources (eg, JavaScript files, images, CSS files) that are not transmitted through TLS. Such pages are very insecure, and these unprotected JavaScript resources will be used by man-in-the-middle attacks, such as hijacking the entire user session.

Understand third-party services

Most websites are third-party services such as Google Analytics that are activated by JavaScript code downloaded from another server. Websites that contain third-party code will create an implicit trust connection, effectively allowing the other party to fully control your website. Although third-party connections may not be malicious, the vendors behind these services may be attacked. For example, if a server is attacked, the attacker will automatically visit all sites that depend on the server.

Security Setting Cookies

To achieve security while maintaining performance, the website requires TLS, and all cookies are marked as safe when they are created. Otherwise, it may be used by MITM attackers. It is recommended that you add encryption integrity verification for your cookies.

Secure HTTP compression

The CRIME attack can decrypt some secure connections by exploiting vulnerabilities in the compression process. Disabling TLS compression can prevent such attacks. Also note that HTTP compression may be used by TIME and BREACH attacks. Unlike TLS compression, HTTP compression is required and cannot be turned off. Therefore, to solve these attacks, the application code needs to be changed.

Configure to use HTTP Strict Transport Security (HSTS)

To activate HSTS protection, you can add a new response header to your website. After that, browsers that support HSTS will execute it. This goal is achieved by automatically converting all plaintext links to secure links.

It is recommended that you add support for HSTS, which is the most important guarantee for TLS security. For best security, please consider using HSTS pre-loading and embedding the HSTS configuration in the browser. As long as it is within the validity period, the browser will directly initiate the HTTPS request forcibly.

Deploy content security strategy (CSP)

Handling of sensitive content

Since the use of cloud-based application platforms is increasing, to let all sensitive content be received only by the receiver, you must be careful to handle sensitive content.

LEAVE A REPLY

Please enter your comment!
Please enter your name here