Build a secure app! iOS security series: HTTPS advanced

[[149556]]

This article is divided into the following four sections:

1. Man-in-the-middle attack: introduces common methods of man-in-the-middle attack and simulates a simple man-in-the-middle attack;

2. The correct way to verify certificates: introduces some misunderstandings about verifying certificates and discusses the correct way to verify certificates;

3. ATS: Let’s discuss App Transport Security, a new feature released in iOS 9.0.

4. Debugging SSL/TLS: Discusses methods for SSL/TLS debugging using Wireshark;

The first section, "Man-in-the-Middle", contains some common and basic knowledge. You can also find relevant information online. If you already have enough knowledge about man-in-the-middle attacks, you can skip it. The following sections are my personal practice summary in iOS. Except for some system-related features, most of them are general knowledge that is not related to the system. It is quite informative.

1. Man-in-the-middle attack

Regarding HTTPS, I often mention the man-in-the-middle attack. So what exactly is a man-in-the-middle attack? A man-in-the-middle attack, also known as a Main-in-the-middle attack (MITM), is a technique in which an attacker inserts himself into the communication between two parties, making them think they are still communicating directly with each other. However, in fact, the other party has become the middleman, and the information has been obtained or tampered with by the middleman.

Of course, this article is not a popular science article. This section analyzes and discusses HTTPS attacks, especially the common attack methods of HTTPS in the application scenario of App.

As we know from the previous article, after HTTPS establishes a TCP connection, it will perform an SSL handshake to verify the certificate, negotiate the encryption protocol and the key for symmetric encryption, and then use the negotiated key for transmission. Therefore, HTTPS attacks are generally divided into attacks before the SSL connection is established and attacks during the HTTPS transmission process;

Common HTTPS man-in-the-middle attacks first require combining ARP, DNS spoofing and other technologies to intercept the session.

1.1 SSL Certificate Spoofing Attack

This type of attack is relatively simple and common. First, through ARP spoofing, DNS hijacking, or even gateway hijacking, the client's access is redirected to the attacker's machine, so that the client machine establishes an HTTPS connection with the attacker's machine (using a forged certificate), and the attacker's machine then connects to the server. In this way, the user sees a website with the same domain name on the client, but the browser will prompt that the certificate is untrustworthy. The user can avoid being hijacked by not clicking to continue browsing. Therefore, this is the simplest attack method and the easiest to identify attack method.

There is a classic tool for this type of attack: SSLSniff. SSLSniff was developed by the great Moxie Marlinspike. The tool was originally designed to be used for the Basic Constaints vulnerability mentioned in the previous article. This type of system-level vulnerability can basically make you unaware; current operating systems and browsers have basically fixed this vulnerability. However, SSLSniff can also be used to forge certificates to implement phishing attacks.

Precautions:

In case of phishing attacks, HTTPS connections (NSURLConnection) created by apps directly calling system APIs are generally not affected. Only the default system verification is used. As long as the system has not trusted the related forged certificates before, the verification will fail directly and the SSL handshake will not succeed. However, if you use WebView to browse the web, you need to add stronger authorization verification to UIWebView to prohibit users from continuing to access the web if the verification fails.

1.2 SSL Stripping Attack ( SSLStrip )

SSL stripping is the process of downgrading an HTTPS connection to an HTTP connection. If the client directly accesses an HTTPS URL, the attacker cannot directly downgrade it because although both HTTPS and HTTP are TCP connections, HTTPS needs to perform an SSL handshake before transmitting HTTP data and negotiate the transmission key for subsequent encrypted transmission. If the client performs an SSL handshake with the attacker, and the attacker cannot provide a trusted certificate for the client to verify and connect, the client's system will determine that the SSL handshake has failed and disconnect.

This attack method mainly exploits the vulnerability that users do not always directly enter https://xxx.xxx.com on the browser to visit the website, or that some websites are not fully HTTPS, but only use HTTPS when sensitive data needs to be transmitted. After hijacking the HTTP session between the client and the server, the man-in-the-middle attacker replaces all https:// hyperlinks in the HTTP page with http://. When the user clicks the corresponding link, the HTTP protocol is used to access it; in this way, even if the server only supports HTTPS links for the corresponding URL, the man-in-the-middle can still establish an HTTPS connection with the service and forward the data to the client using the HTTP protocol, thus achieving session hijacking.

This attack method is more difficult to guard against because it uses HTTP, which will not cause the browser to display a warning that the HTTPS certificate is unreliable, and users rarely check whether the URL on the browser is https:// or http://. Especially in the App's WebView, the application generally hides the URL, and users cannot directly check if there is an abnormality in the URL.

Precautions:

This attack method also cannot hijack the HTTPS connection session within the App, because the URL parameter of the incoming request in the App is fixed with https://; but you also need to be careful when opening a web page in WebView. For websites that are not fully HTTPS, it is recommended to check the URL opened in WebView to check whether the URL that should use https:// has been tampered with to http://; it is also recommended that the server add the "HTTP Strict Transport Security" configuration item when configuring the HTTPS service.

Reference: [Traffic hijacking] Avoid HTTPS hijacking of HSTS

1.3 Attacks on SSL Algorithms

The above two methods have low technical content and generally can only affect WebApp, but it is difficult to attack Native App. Therefore, advanced hackers will directly attack SSL algorithm-related vulnerabilities and use a lot of cryptography-related methods. Since I am not a professional security-related person and do not have much relevant practical experience, I will not go into detail about the relevant attack principles and methods in this section. Interested students can check the following extended reading:

• OpenSSL Vulnerabilities

• Common HTTPS attack methods

Precautions:

This type of attack exploits vulnerabilities in the SSL algorithm, so the best preventive measure is to upgrade the server-side SSL/TLS configuration:

• Only support the highest possible version of TLS (minimum TLS1);

• Disable some encryption methods that have exposed security risks;

• Use 2048-bit digital certificates;

1.4 Simulating the simplest attack

After explaining the above attack methods, let's simulate the simplest man-in-the-middle attack.

The steps of man-in-the-middle attack have been mentioned above. Traffic hijacking related operations are not the focus of this article. You can refer to How does traffic hijacking occur? In this example, Charles is used as a proxy to hijack traffic. SSL proxy is used to simulate a man-in-the-middle attack on HTTPS requests of iPhone devices, so that everyone can understand how to prevent similar attacks during development while thinking about and understanding the man-in-the-middle attack method.

1) Charles proxy settings

Enable and set HTTP proxy and SSL proxy in Charles, Menu -> Proxy -> Proxy Setting, and set as shown:

HTTP proxy settings, remember the port number: 8888

SSL proxy settings, you can set the domain name you want to use for SSL proxy in Locations. Here, Baidu's Baifubao*.baifubao.com is used as the simulation object.

2) Set up HTTP proxy on iPhone

Get the current machine's IP address on a Mac:

ifconfig en0:

There is also a simple way, hold down option + click the WiFi network icon in the top menu bar:

You can see that the current computer's IP address is: 192.168.199.249.

Connect your iPhone to the same WiFi as your computer. In iPhone settings: Wireless LAN -> Info details icon on the right of connected WiFi -> HTTP Proxy -> Manual -> Set HTTP Proxy:

After the settings are completed, open Safari and visit any web page. If you are setting up a proxy for the first time, Charles will pop up a confirmation box for iPhone requesting the proxy. Click Allow. Then you can see the HTTP requests on the iPhone in Charles. In order to avoid too many requests on the Mac affecting the viewing and debugging of HTTP requests on the proxied iPhone, you can cancel the Mac proxy in Charles: Menu -> Proxy -> Uncheck Mac OS X Proxy.

If you visit the proxied target URL http://www.baifubao.com, you will not be able to open the webpage because the iPhone's HTTPS request has been intercepted by Charles, but the iPhone cannot trust Charles' certificate, so the SSL Handshake fails and the HTTPS connection cannot be established.

3) Forged certificate fraud

Open Safari on the proxied iPhone and visit http://www.charlesproxy.com/getssl. The installation descriptor file interface will pop up. The descriptor file contains the Charles root certificate:

Note: This Charles certificate is built into Charles. You can save and install the certificate directly in the menu Help -> SSL Proxying. The installed description file can be viewed and managed in the iPhone device's Settings -> General -> Description File.

After the "installation" is completed, the Charles root certificate will be added to the system's trusted certificate list, and the sub-certificates issued using this certificate will also be trusted by the system. Charles will generate the corresponding SSL certificate for the domain name configured in the previous SSL proxy settings, so that the forged certificate can achieve deception. You can use Mac SSL proxy to check:

4) Result verification

Download the Baidu App, log in to your account, and then go to Me -> My Wallet to access Baidu Pay:

We can see that the content of the HTTPS request package has been successfully obtained. From this, we can guess that the App uses the system's default verification method: the system trusts the SSL certificate returned by the middleman server, and the App trusts this verification, and the SSL handshake succeeds; but no local comparison verification is performed on the server certificate. This is a security risk that many apps currently have.

This simple SSL proxy simulates a simple phishing-style man-in-the-middle attack. Everyone should have a basic understanding of the vulnerabilities targeted by this attack method and the measures to prevent this attack method:

• Do not connect to public WiFi or use unknown proxy servers

• Do not install untrusted or unexpected profiles, or trust forged certificates;

• The app needs to perform a separate comparison and verification of the server certificate to confirm that the certificate is not forged;

#p#

2. The correct way to check the certificate

The previous section briefly introduced man-in-the-middle attacks. This section discusses how to verify the SSL certificate returned by the server in the App to ensure the security of HTTPS communication based on the security risks we encountered in the previous section. The previous article "iOS Security Series 1: HTTPS" explained the code related to the basic verification process. This article will not go into these details, but will mainly discuss several important points in verifying the certificate:

2.1 Domain Name Verification

Not long ago, AFNetworking, the most well-known open source network library on iOS, exposed an HTTPS verification vulnerability. The vulnerability is because the parameter validatesDomainName in its verification policy module AFSecurityPolicy defaults to NO, which will result in the domain name corresponding to the certificate not being verified when verifying the certificate. That is, the server certificate returned by the request will pass the verification as long as it is issued by a trusted CA organization. This is a very serious vulnerability. The vulnerability has been fixed in version v2.5.2, corresponding to the Git version number 3e631b203dd95bb82dfbcc2c47a2d84b59d1eeb4.

This vulnerability and the related source code of AFNetworking will make many people think that the system's default verification does not verify the domain name corresponding to the certificate, but this is not the case. AFNetworking is indeed superfluous here. First, let's check the system's default verification strategy:

- ( void )connection:(NSURLConnection *)connection willSendRequestForAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
 //1) Get the trust object  
    SecTrustRef trust = challenge.protectionSpace.serverTrust;
 //Get the default validation strategy  
    CFArrayRef defaultPolicies = NULL;
    SecTrustCopyPolicies(serverTrust, &defaultPolicies);
    NSLog(@ "Default Trust Policies: %@" , (__bridge id)defaultPolicies);
 //...  
 }

Print the default validation strategy information:

5 :{contents = "ValidRoot" } ={value = true }
 6 :{contents = "SSLHostname" } ={contents = "xxx.xxx.com" }
 8 :{contents = "ValidLeaf" } ={value = true }

From the printed information, we can see that the default verification strategy of the system already includes domain name verification. Then look at the relevant source code in AFSecurityPolicy:

- (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust
                  forDomain:(NSString *)domain
 {
    NSMutableArray *policies = [NSMutableArray array];
 if (self.validatesDomainName) {
        [policies addObject:(__bridge_transfer id)SecPolicyCreateSSL( true , (__bridge CFStringRef)domain)];
 } else {
        [policies addObject:(__bridge_transfer id)SecPolicyCreateBasicX509()];
 }
    SecTrustSetPolicies(serverTrust, (__bridge CFArrayRef)policies);
 //...  
 }

This is actually a mistake that many developers make when dealing with exceptions and default logic branches. The recommended implementation of this logic is:

//Replace validatesDomainName, default is NO, which is the system default behavior  
 @property (nonatomic, assign) BOOL skipDomainNameValidation;
 //check  
 - (BOOL)evaluateServerTrust:(SecTrustRef)serverTrust
                  forDomain:(NSString *)domain
 {
 if (self.skipDomainNameValidation) {
        NSMutableArray *policies = [NSMutableArray array];
        [policies addObject:(__bridge_transfer id)SecPolicyCreateBasicX509()];
        SecTrustSetPolicies(serverTrust, (__bridge CFArrayRef)policies);
 }
 //...  
 }

From the code, does the logic become clearer? And it also shows that the system's default verification method is to verify the domain name. In fact, SecTrustSetPolicies resets the verification policy for scenarios where IP is used for HTTPS requests, or one certificate is used for multiple domain names; in these scenarios, the domain name on the server certificate and the requested domain name will be inconsistent, resulting in verification failure; this requires resetting the verification policy and setting the domain name corresponding to this certificate. For detailed instructions, please refer to the official document: "Overriding TLS Chain Validation Correctly"

2.2 Verify certificate chain?

In the previous article, when introducing the method and process of system verification of SSL certificates, didn't it already explain that the certificate chain will be verified layer by layer to ensure the credibility of the certificate? Why do we still need to discuss this issue? In fact, this section is going to discuss the issue of validatesCertificateChain in AFNetworking.

First, let me explain the result: In the latest release of AFNetworking V2.6.0, this feature has been removed. Related discussion: SSL Pinning: What Should Be Certificate Chain Validation Expected Behavior?#2744

The verification certificate chain implemented in AFNetworking is to compare the data of the certificate packaged locally in the App with the certificate chain returned by the server. Only when the certificate packaged locally contains all the certificates in the certificate chain returned by the server, the verification will pass. For example, Google's SSL certificate:

If you enable validatesCertificateChain to request https://google.com, you need to import the GeoTrust Global CA, Google Internet Authority G2, and google.com certificates into the App for verification to pass. Please recall the previous article about the trust mechanism of the certificate chain, and you will find that this is completely unnecessary; the verification of the certificate chain mainly consists of three parts to ensure the credibility of the certificate: the leaf certificate is the certificate corresponding to the HTTPS request domain name, the root certificate is the certificate trusted by the system, and the certificates in this chain are issued layer by layer; these are the steps of system verification, that is, the system confirms that the server using the certificate is the server corresponding to the requested domain name. After the certificate chain is verified by the system, both ends are confirmed to be credible, and any node in the middle is also credible, and there is no need to compare and verify the intermediate nodes one by one.

2.3 Package Certificate Verification

So is it not necessary to package the certificate locally in the App for verification? At this point, we need to think about why forged certificates can be used to implement man-in-the-middle attacks? The answer is that the user lets the system trust a certificate that should not be trusted. The certificate that the user sets up for the system to trust will be used as an anchor certificate to verify other certificates. When the returned server certificate is an anchor certificate or a certificate issued based on this certificate (can be multiple levels), it will be trusted. Therefore, we cannot completely trust the system's verification, because the source of the system's verification comparison is likely to be contaminated.

Therefore, the App still needs to package the certificate locally and use SecTrustSetAnchorCertificates(SecTrustRef trust, CFArrayRef anchorCertificates) to set the Anchor Certificate for verification. It should be noted that the official document "Certificate, Key, and Trust Services Reference" has a description of the incoming Anchor Certificates:

IMPORTANT
Calling this function without also calling SecTrustSetAnchorCertificatesOnly disables the trusting of any anchors other than the ones specified by this function call.

In other words, if you simply call the SecTrustSetAnchorCertificates method without calling SecTrustSetAnchorCertificatesOnly to verify the certificate, only the certificate passed in by SecTrustSetAnchorCertificates will be trusted, and other anchor certificates will not be trusted. This is also explained in the explanation of the SecTrustSetAnchorCertificatesOnly method parameters:

anchorCertificatesOnly:
If true, disables trusting any anchors other than the ones passed in with the SecTrustSetAnchorCertificates function. If false, the built-in anchor certificates are also trusted. If SecTrustSetAnchorCertificates is called and SecTrustSetAnchorCertificatesOnly is not called, only the anchors explicitly passed in are trusted.

Only trusting the incoming anchor certificates will only verify the certificates issued by these anchor certificates. In this way, even if the certificate being verified is issued by an anchor certificate trusted by the system, it will not be verified.

The last question is: Which node of the certificate chain should be selected as the anchor certificate to be packaged into the App? Many developers will directly choose the leaf certificate. In fact, for self-built certificates, it is feasible to choose any node. For certificates issued by CA, it is recommended to import the CA certificate that issued the certificate or the certificate of the higher-level CA institution, or even the root certificate. This is because:

1) Generally, the validity period of leaf certificates is relatively short. The validity period of the official certificates of Google and Baidu is only a few months. Since App is a client, it requires a certain degree of backward compatibility. If you neglect to check, the certificate will expire in two days after it is released today.

2) The closer you get to the end of the certificate chain, the more likely it is that the certificate will change; for example, a leaf certificate changes from a specific domain name (aaa.bbb.com) to a wildcard domain name (*.bbb.com), etc. Short-term changes and redeployment may cause the old version of the App to be inaccessible due to untimely updates.

Therefore, it is more appropriate to use a CA certificate. As for which level of CA certificate to use, there is no conclusion yet.

3. ATS

At the time of this article's publication (2015-09-03), most iOS developers should have upgraded to iOS9. When making HTTP/HTTPS requests under iOS9, you may encounter the following error:

Request failed: Error Domain=NSURLErrorDomain Code=-1022 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." UserInfo=0x7fbb4a158f00 {NSUnderlyingError=0x7fbb4a1141c0 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.", NSErrorFailingURLStringKey=http://api.xxx.com/mobile, NSErrorFailingURLKey=http://api.xxx.com/mobile, NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.}

This is a major update in iOS9: App Transport Security, or ATS for short. ATS imposes a series of mandatory requirements on the use of APIs such as NSURLConnection, CFURL, or NSURLSession for network requests, forcing the server to configure in order to improve the security of network data transmission:

These are the App Transport Security requirements:
1) The server must support at least Transport Layer Security (TLS) protocol version 1.2.
2) Connection ciphers are limited to those that provide forward secrecy (see the list of ciphers below.)
3) Certificates must be signed using a SHA256 or better signature hash algorithm, with either a 2048 bit or greater RSA key or a 256 bit or greater Elliptic-Curve (ECC) key. Invalid certificates result in a hard failure and no connection.

ATS requires apps running on iOS9 to upgrade HTTP connections to HTTPS, and the TLS version must not be lower than v1.2. It also specifies the supported cipher suites and hash algorithms for certificate signatures. If you want forward compatibility, you can lower the verification strength by setting Info.plist. For details, see this article: Configuring App Transport Security Exceptions in iOS 9 and OSX 10.11.

The increasingly complex and fragile network makes it difficult to ensure the security of user data. Therefore, Apple has strongly promoted ATS on iOS9, forcing the server to upgrade the HTTPS configuration to provide a more secure network environment. It is recommended that developers do not simply disable ATS, but upgrade the server configuration to support ATS to provide users with more secure services.

4. Debugging SSL/TLS

When developing a new App, the terminal and the backend usually negotiate the communication protocol of the specific business logic first. After the backend and the terminal implement the logic according to the protocol, they enter the joint debugging stage. The first joint debugging often returns many problems, including incorrect data format, missing basic fields, etc. If it is an HTTPS-based network request, it is very likely that due to background configuration problems, it will cause handshake failure errors such as CFNetwork SSLHandshake failed (-9824). How to solve this kind of SSL error? According to my experience, it is mainly divided into two steps:

4.1 Error Codes

Isn't this too simple? In fact, the simplest is often the most effective. SSL related error codes can be found in The error -9824 above corresponds to errSSLPeerHandshakeFail = -9824, /* handshake failure */. Other common error codes include:

//...  
 /* fatal errors detected by peer */  
    errSSLPeerUnexpectedMsg = - 9819 , /* unexpected message received */  
    errSSLPeerBadRecordMac = - 9820 , /* bad MAC */  
    errSSLPeerDecryptionFail = - 9821 , /* decryption failed */  
    errSSLPeerRecordOverflow = - 9822 , /* record overflow */  
    errSSLPeerDecompressFail = - 9823 , /* decompression failure */  
    errSSLPeerHandshakeFail = - 9824 , /* handshake failure */  
    errSSLPeerBadCert = - 9825 , /* misc. bad certificate */  
    errSSLPeerUnsupportedCert = - 9826 , /* bad unsupported cert format */  
    errSSLPeerCertRevoked = - 9827 , /* certificate revoked */  
    errSSLPeerCertExpired = - 9828 , /* certificate expired */  
    errSSLPeerCertUnknown = - 9829 , /* unknown certificate */  
    errSSLIllegalParam = - 9830 , /* illegal parameter */  
    errSSLPeerUnknownCA = - 9831 , /* unknown Cert Authority */  
    errSSLPeerAccessDenied = - 9832 , /* access denied */  
 /* more errors detected by us */  
    errSSLHostNameMismatch = - 9843 , /* peer host name mismatch */  
    errSSLConnectionRefused = - 9844 , /* peer dropped connection before responding */  
    errSSLDecryptionFail = - 9845 , /* decryption failure */  
    errSSLBadRecordMac = - 9846 , /* bad MAC */  
    errSSLRecordOverflow = - 9847 , /* record overflow */  
    errSSLBadConfiguration = - 9848 , /* configuration error */  
 //...  

However, error codes can only be used to determine the approximate situation. In many cases, we cannot clearly know the exact cause of the error. Therefore, the most intuitive method is to capture the packet for analysis.

4.2 Packet capture analysis

At this stage, it is useless to use Charles to capture packets, because Charles works as an HTTP proxy, it will capture the proxy's network packets, and then combine the packets into HTTP/HTTPS protocol packets, which is very convenient for HTTP debugging, but due to the lack of details, it cannot be used to analyze SSL related errors. So we need to use the ancient artifact Wireshark.

I won't introduce Wireshark in detail. There are many related introductions and packet capture tutorials on the Internet, such as "Using Wireshark to Capture Packets on Mac OS X", which can basically be used quickly. Next, we will take ATS adapted to iOS9 as an example to explain how to perform packet capture analysis and find out the SSL handshake failure caused by unsupported ATS.

Do you remember the SSL handshake process? If you don't remember, you can review this article: SSL/TLS Protocol Diagram. Let's also take a look at the packets captured on Wireshark to intuitively learn the normal SSL handshake process:

The above picture is a standard HTTPS request capture package:

1) After the TCP three-way handshake is successful, the client initiates the SSL Client Hello (No.68 frame), passing the random number (Random), and the cipher suites (Cipher Suites) supported by the client, compression method, signature algorithm and other information; As shown in the figure below, this is the information carried by the Client Hello, which can be expanded to see the relevant details:

2) The server matches the supported cipher suites, compression algorithms, and signature algorithms from the Client Hello, and returns a newly generated random number to the client. This is the Server Hello (No. 70 frame). The following figure is the response to the Client Hello in 1). As can be seen from the figure, the Cipher Suite matched by the server is TLS_DHE_RSA_WITH_AES_256_CBC_SHA256:

3) The server will also send the certificate to the client (frame No.73);

4) When the client confirms that the certificate is valid, it will generate the last random number (Premaster secret), encrypt the random number using the certificate's public key RSA, and send it back to the server. For higher security, it will be changed to the Diffie-Hellman algorithm (DH algorithm for short); using the DH algorithm, the last random number (Premaster secret) does not need to be transmitted, and can be calculated after the client and server exchange parameters. Client Key Exchange (No. 75 frames);

5) Next, both parties will send a Change Cipher Spec to notify each other, and all subsequent messages will be encrypted using the key agreed upon by the signature.

6) Finally, both parties send a Finished Message (Encrypted Handshake Message, frames 77 and 79). This message is the final verification and contains information such as the Session Key during the handshake process. If the other party can decrypt this message, it means that the handshake is successful, and the entire SSL Handshake process ends.

For more information about SSL/TLS interfaces, see: rfc5246 and SSL/TLS in Detail.aspx)

Taking the captured HTTPS request as an example, the handshake process of SSL/TLS is briefly introduced. The following are the main problems encountered during the debugging and adaptation of ATS:

1) Cipher Suite and other parameters do not match: Cipher Suite mismatch is the most common example of handshake failure.

In ATS, acceptable cipher suites include:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA

However, the HTTPS configuration of many servers has not been upgraded for a long time and cannot support these Cipher Suites. The client sends Client Hello to the server with the supported Cipher Suite parameters. The server checks these parameters and finds that none of them are supported, and directly returns the Handshake Failure information. As shown in the following figure:

Generally, Handshake Failure is returned after receiving the Client Hello sent by the client because the server cannot match the client's SSL handshake parameters. As for whether it is a problem with the cipher suite parameter matching, it is recommended to capture a normal HTTPS request packet with ATS canceled for comparison to find out the specific mismatched parameters.

2) The SSL/TLS version is too low. This is also very common, but it is usually covered by the previous parameter mismatch error. Because most servers with low SSL/TLS versions have low cipher suites and other parameter versions supported by the HTTPS configuration, and the SSL/TLS version is verified after the client receives the Server Hello, but this step cannot be reached if the previous handshake fails. Therefore, the Cipher Suite and other parameters cannot be matched and supported, which generally means that the server SSL/TLS version is too low.

3) Certificate chain configuration error: During the development process, I encountered the problem that the certificate chain was not configured in order, and I also encountered the problem that only the leaf certificate was configured. For these problems, you can directly check the Certificate package returned by the server during the SSL handshake:

In the figure above, you can see that there is only one certificate chain, which is a typical configuration error.

PS: When using Wireshark to capture packets, sometimes because the SSL/TLS version number of some HTTPS requests is too low, Wireshark cannot identify it as an SSL packet, but displays it as TCP; in this case, you can manually Decode it: select the corresponding TCP data frame, right-click -> Decode As -> Transport, select SSL -> Apply.