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:

The situation of domestic user terminals is complex. In many cases, the SSL security configuration is reduced to be compatible with more users. There are indeed some large manufacturers whose SSL configurations are not professional, 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

TLS (Transport Layer SecurityTransport Layer Security) Is the predecessor of SSL (Secure Socket LayerSecure Sockets Layer), Its first 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 by default starting from 1.9.1. The following describes the ssl_protocols configuration in the Nginx official documentation:

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

Cipher SuiteCipherSuiteIs an important parameter to be negotiated in the SSL handshake. The Client will include the list of supported CipherSuite in Client Hello, and the Server will select one from it and return it through Server 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, suchAuthentication AlgorithmAuthentication,Encryption AlgorithmEncryption,Message Authentication Code AlgorithmMessage Authentication Code(MAC ),Key Exchange AlgorithmKey ExchangeAndKey derivative algorithmKey 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:

openssl ciphers -V | column -t0xCC,0x14  -  ECDHE-ECDSA-CHACHA20-POLY1305  TLSv1.2  Kx=ECDHAu=ECDSA   Enc=ChaCha20-Poly1305  Mac=AEAD... ...

0xCC, 0x14 is the number of CipherSuite, which is used in SSL handshake. ECDHE-ECDSA-CHACHA20-POLY1305 is 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 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 the EXPORT-containing CipherSuite, 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 you can configure multiple sites by specifying different server_name in Nginx. The Host field in the HTTP/1.1 Request Header 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 use the SNI extension in Client Hello to obtain the Server Name of the website to be accessed by the user, and then send the certificate that matches it to complete the SSL handshake smoothly.

Nginx supports SNI a long time ago and can be verified by nginx-V. Here are my verification results:

./nginx -Vnginx version: nginx/1.9.9built by gcc 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04)built with OpenSSL 1.0.2e-dev xx XXX xxxxTLS SNI support enabledconfigure 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:

BrowserLowest versionChrome Vista + full support; XP requires Chrome 6 +; OSX 10.5.7 + and Chrome 5 + Firefox 2.0 + Internet Explorer 7 + (requires Vista +) safari 3 + (OS X 10.5.6 + 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 ( Certificate to be signedTo Be Signed Certificate) Information; digital signature issuance: Use the HASH function to calculate the message digest from TBSCertificate, encrypt the message digest with the private key of the CA to obtain the signature, and verify the digital signature: use the same HASH function to calculate the message digest for TBSCertificate, and compare it with the content obtained by using the CA Public Key to decrypt the signature;

The certificate that uses SHA-1 as the HASH function is called the SHA-1 certificate. Because the Collision Condition of SHA-1 has been found, replacing the certificate with the SHA-2 certificate that uses a safer SHA-2 as the HASH function is put 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:

BrowserSupports the minimum version of SHA-2 certificatesChrome 26 + Firefox 1.5 + Internet Explorer 6 + (requires XP SP3 +) Safari 3 + (requires OS X 10.5 +) 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 can allocate different certificates based on the characteristics of Cipher Suites in Client Hello and whether SNI is supported, 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.