How to Set HTTPS policies for old browsers

How to Set HTTPS policies for old browsers

A few days ago, a friend asked me: we all said we recommend using the Qualys SSL Labs tool to test SSL security. Why are some of the most powerful Security manufacturers having low scores? I think this problem should be resolved in two aspects:

1. The situation of domestic user terminals is complex. In many cases, the SSL security configuration is reduced to be compatible with more users;
2. Some major manufacturers do not have very professional SSL configurations, especially those that are clearly unavailable.

I previously wrote "experience sharing on enabling HTTPS (I)", which mainly introduced how to Use HTTPS in combination with some new security specifications, targeting modern browsers. In this article, we will introduce the problems that may occur in old browsers during HTTPS activation and how to choose between them.

 

Select an SSL version

Transport Layer Security (Transport Layer Security), formerly known as SSL (Secure Socket Layer )), its original versions (SSL 1.0, SSL 2.0, and SSL 3.0) were developed by Netscape and have been standardized and renamed by IETF since 3.1, up to now, three versions are available: TLS 1.0, TLS 1.1, and TLS 1.2. TLS 1.3 changes will be relatively large and are still in the draft phase.

SSL 1.0 has never been made public, and SSL 2.0 and SSL 3.0 both have security issues, which are not recommended. Nginx supports only three TLS versions starting from 1.9.1.ssl_protocolsConfiguration description:

Syntax: ssl_protocols [SSLv2] [SSLv3] [TLSv1] [TLSv1.1] [TLSv1.2];
Default: ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Context: http, server
Enables the specified protocols. The TLSv1.1 and TLSv1.2 parameters work only when the OpenSSL library of version 1.0.1 or higher is used.

However, unfortunately, IE 6 only supports SSLv2 and SSLv3 (Source). That is to say, to support Internet Explorer 6, you must enable SSLv3. This option only causes the score given by SSL Labs to be reduced to C.

 

Cipher Suite Selection

The cipher suite (CipherSuite) is an important parameter to be negotiated in the SSL handshake. The client willClient HelloWith the list of supported CipherSuite, the server selects one from and passesServer Hello. If the CipherSuite list supported by the client does not overlap with the CipherSuite list configured by the server, negotiation cannot be completed and the handshake fails.

CipherSuite includes multiple technologies, such as Authentication algorithm, Encryption algorithm, Message Authentication Code (MAC), and Key Exchange algorithm) and Key Derivation Function ).

The SSL CipherSuite negotiation mechanism has good scalability. Each CipherSuite needs to be registered in IANA and is assigned two byte signs. You can view all CipherSuite on the TLS Cipher Suite Registry page of IANA.

You can run the following command to view all the CipherSuite supported by the OpenSSL Library:

1. openssl ciphers -V | column -t
2. 0xCC,0x14- ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2Kx=ECDH Au=ECDSA Enc=ChaCha20-Poly1305Mac=AEAD
3. ......

0xCC,0x14Is the number of the CipherSuite, which is used in the SSL handshake.ECDHE-ECDSA-CHACHA20-POLY1305Is its name, after several parts are expressed: For TLSv1.2, using ECDH for key exchange, using ECDSA for authentication, using ChaCha20-Poly1305 for symmetric encryption, because the ChaCha20-Poly1305 is a AEAD mode, MAC algorithms are not required, so the MAC column is displayed as AEAD.

To learn more about CipherSuite, read the long article "TLS protocol analysis and modern encrypted communication protocol design". In short, when configuring CipherSuite, you must refer to the authoritative documentation, such as the recommended configuration of Mozilla and the configuration used by CloudFlare.

The "Old backward compatibility" configuration and CloudFlare configuration in the above Mozilla documents are compatible with Old browsers, including Windows XP/IE6.

I have seen a large manufacturer support includeEXPORTCipherSuite, which was weakened in the last century due to U.S. export restrictions and has been cracked. There is no reason to use it again.

 

SNI Extension

We know that in Nginx, you can specify differentserver_nameTo configure multiple sites. In the HTTP/1.1 request headerHostThe field identifies the site to which the current request belongs. However, for an HTTPS website, to send HTTP data, you must wait for the SSL handshake to complete. In the handshake phase, the server must provide the website certificate. How does the server know which certificate to send when different HTTPS sites are deployed on the same IP address and different certificates are used?

Server Name Indication (SNI) is an extension of TLS. With SNI, the server can useClient HelloThe SNI extension in receives the Server Name that the user wants to access the website, and then sends the matching certificate to complete the SSL handshake smoothly.

Nginx supports SNI a long time ago.nginx -VTo verify. Here are my verification results:

1. ./nginx -V
2. nginx version: nginx/1.9.9
3. built by gcc4.8.4(Ubuntu4.8.4-2ubuntu1~14.04)
4. built withOpenSSL1.0.2e-dev xx XXX xxxx
5. TLS SNI support enabled
6. configure arguments:--with-openssl=../openssl --with-http_ssl_module --with-http_v2_module

However, not all browsers support SNI. Below are the lowest versions of common browsers that support SNI:

Browser	Lowest version
Chrome	Vista + full support; XP requires Chrome 6 +; OSX 10.5.7 + and Chrome 5 +
Firefox	2.0 +
Internet Explorer	7 + (Vista + required)
Safari	3 + (OS X 10.5.6 + is required)
Mobile Safari	IOS 4.0 +
Android Webview	3.0 +

As you can see, there are still a certain number of users in Windows XP IE6 ~ 8. Android 2.x Webview does not support SNI. To avoid Certificate Errors in these browsers, you can only deploy HTTPS sites with different certificates on different IP addresses. The simplest way is to deploy them separately on different machines.

 

Certificate Selection

The HTTPS website must obtain a valid certificate through the CA, and the certificate cannot be forged by a third party through digital signature technology. The simple principle of the certificate is as follows:

• Generate TBSCertificate based on the version number, serial number, signature algorithm ID, issuer name, validity period, certificate subject name, certificate subject public key information, unique issuer ID, unique subject ID, and extension be Signed Certificate )) information;
• Digital signature issuing: Use the HASH function to calculate the TBSCertificate to obtain the message digest. Use the private key of the CA to encrypt the message digest and obtain the signature;
• Verify Digital Signature: use the same HASH function to calculate the message digest for TBSCertificate, and compare it with the content obtained by decrypting the signature using the CA Public Key;

The certificate that uses SHA-1 as the HASH function is called the SHA-1 certificate. Because the SHA-1 collision condition has been found, replacing a certificate with a SHA-2 certificate that uses a safer SHA-2 as a HASH function is on the agenda.

In fact, Microsoft has declared that its support for SHA-1 certificates will be completely suspended from January 1, January 1, 2017. The SHA-1 certificate will not be trusted in the latest version of Windows.

According to the official Chrome blog, websites that use the SHA-1 certificate and the certificate is valid from January 1, January 1-20, 2016 to January 1, December 31 will be given a "secure but vulnerable" prompt, that is, the lock in the address bar is no longer green, and there will be a small yellow triangle. If you use a SHA-1 certificate and the certificate is valid for more than January 1, 2017, the website will be given a red warning of "insecure". A Red Cross is directly displayed on the lock.

However, not all terminals support SHA-2 certificates, the server does not support good, the browser can only rely on the user upgrade. Below are the lowest versions of common browsers that support SHA-2 certificates:

Browser	Supports the minimum version of SHA-2 certificates
Chrome	26 +
Firefox	1.5 +
Internet Explorer	6 + (XP SP3 + required)
Safari	3 + (OS X 10.5 + is required)
Android Webview	2.3 +

We can see that if you want to take care of IE6 users who have not installed the XP SP3 Patch, you can only continue to use the SHA-1 certificate.

In my previous articles, I also mentioned ECC certificates. This new type of certificate has a poor support level, which is not mentioned here. If you are interested, click here to view them.

Can I enable different certificates for different browsers? Theoretically, the server canClient HelloIn the Cipher Suites feature and whether to support SNI features to assign different certificates, but I have not actually verified it.

This article has written so much that many policies need to be determined by the users on their own websites. For example, my blog basically does not have IE8-users, and SSLv3 can be disabled. If your product has many users who use old browsers, you must provide compatibility solutions for these users. One solution is to only downgrade the primary domain security level, and redirect the HTTPS requests of IE users on XP to the HTTP Version, so that other domain names can use the high security level configuration, easy to operate and maintain.

This article permanently updates the link address: