1.TLS/SSL handshake process
2. Case sharing
2.1 History Of the CFCA Certificate
2.1.1 background
A customer applied for a CERTIFICATE issued by CFCA for a site in their production environment. After the relevant domain correctly configured the certificate and enabled HTTPS, the test found that their client App could not connect to the relevant site on earlier versions of mobile phones (iOS < 10.0, Android < 6.0).
Client debugging found that the console will see an Invalid Certificate error message (Invalid Certificate or Certificate Unknown).
2.1.2 screening
At first, the engineer did not know by which agency the customer’s certificate was issued and what the problem was. For this kind of problem, the client network package is generally needed to do further analysis and judgment. Therefore, arrange the customer to perform problem reoccurrence and client packet capture on the affected device.
After obtaining the network package, it is confirmed that the direct cause of client connection failure is abnormal termination of TLS handshake, as shown below:
Check the contents of Encrypted Alert. The error message is 0x02 0x2E. According to TLS 1.2 protocol (RFC5246), the error is because of certificate_unknown.
According to the certificate information in the Server Hello frame, the certificate is issued by China Financial Certification Authority(CFCA). Confirm the Intermediate CA and Root CA certificates based on the Authority Information Access (AIA) Information in the certificate Information. Verify that the ROOT certificate of the certificate issuing authority is CFCA EV ROOT.
Return to the mobile device with the problem (Android 5.1), check the system built-in trusted CA ROOT certificate list, failed to find the CFCA EV ROOT CA certificate. On a properly connected mobile phone, you can find the CA root certificate and set it to Trust by default.
Check the CFCA certificate. The CFCA certificate is connected to the root system only on iOS 10.1 or Android 6.0 or later.
2.1.3 summary
As shown in the preceding analysis, the root cause of this problem is that the client device of earlier version does not have the CA root certificate with built-in CFCA. Therefore, the basic solutions include:
- Replace the certificate issued by another CA authority to ensure that the CA root certificate is trusted by default on a specific device.
- Manually install the CA root certificate and intermediate certificate on the affected device and set the CA root certificate and intermediate certificate to the trusted state.
- The CA root certificate is preset by the client App and trusted by the client code.
A proper solution must be selected based on different service scenarios.
2.2 Problems caused by the certificate Chain trust mode
2.2.1 background
A customer added a standby Dr Access address, enabled a new domain name, and configured a new certificate. The test found that when switching to the standby address, the Android client could not connect properly and reported a Certificate Unknown error. The iOS client works properly.
2.2.2 screening
Similar to the problem in 2.1, the problem is rectified on the affected devices and packets are captured by clients.
After obtaining the network package, it is confirmed that the direct cause of the client connection failure is the abnormal termination of TLS handshake process, which is the same as the problem in 2.1, Certificate Unknown:
Check the CA root certificate of the certificate and the trust status of the root certificate.
The certificate is issued by the Secure Site Pro CA G2, and the Root CA is DigiCert Global Root CA:
DigiCert Global Root CA is a widely supported certificate issuing authority, and its Root CA certificate is trusted on the vast majority of devices, which is also confirmed on the affected devices. If the root CA’s certificate is in a trusted state, why does certificate validation still fail? This becomes the focus of the next phase of the investigation.
When the device is switched to the normal environment, the packet capture operation is completed. After obtaining the new network package, I made a comparative analysis and found that the differences in the network package in the two cases were as follows:
Under normal circumstances, the certificate returned by the server contains a complete CA certificate chain.
If an exception occurs, the certificate returned by the server contains only the CA certificate of the leaf node.
According to the above clues, we found that: unlike other platforms, Android clients do not verify the certificate chain through AIA Extension by default.
Therefore, when the intermediate CA certificate is not installed or cached, the client App will not take the initiative to pull the intermediate CA certificate and perform further trust chain verification. As a result, certificate verification fails.
2.2.3 summary
Based on the above analysis, the problem is related to the certificate verification mechanism and certificate packaging method of the Android platform. Solutions include:
Manually customize the TrustManager at the code level to customize the verification process;
Alternatively, pack the intermediate CA certificate and root CA certificate into the server certificate.
The customer chose to repackage the certificate based on development costs and environmental realities. After the new certificate is configured, the problem is resolved.
2.3 Encryption Suite Negotiation Problems
2.3.1 background
A customer reported that their iOS App users could not open certain service sites (HTTPS sites) on a specific carrier network. The client is in the white screen waiting state and finally reports an error. In the same network environment, the system browser can open the site; If the same device is switched to another network carrier, you can also access this site.
2.3.2 screening
Because this problem is directly expressed in the Web layer, we first try to capture the HTTP layer package through Charles for analysis. The HTTP log found that the related HTTP request was not sent.
Therefore, the problem is suspected to occur at the TCP layer, and the problem is rectified and packet capture is performed on the affected device.
After obtaining the network package, first confirm the problem:
- Search DNS resolution result in network packet by page domain name;
- Locate the site IP address based on the DNS resolution result and filter out the access between the client and this IP address.
- Observe the network activity between the client and the server. It is found that the TLS handshake fails:
Handshake Failure = Handshake Failure = Handshake Failure = Handshake Failure = Handshake Failure = Handshake Failure = Handshake Failure = Handshake Failure = Handshake Failure On the client side, you can further narrow down the suspects.
Reconsider the customer problem conditions: under the same network conditions, the system browser can open the page; The same device is switched over to another carrier (the site is accessed by the server in equipment room Q) and can be accessed normally. Packet capture and further analysis are carried out for these two normal situations.
Through network observation of three situations, it is found that:
- The Client Hello display issued by the App in question supports 17 types of encryption suites:
- The Client Hello display issued by a normal App supports 26 types of encryption suites:
- The encryption suite negotiated between the App and the P server in the equipment room is as follows: TLS_RAS_WITH_3DES_EDE_CBC_SHA (0x000A) (not within the range of the encryption suite supported by the App in question).
- The encryption suite negotiated between the troubled App and the Q server in the equipment room is as follows: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xC030) (within the range of the encryption suite supported by the troubled App).
According to the above situation, the basic situation of the problem can be inferred as follows:
- The handshake request sent by the problem App supports 17 kinds of encryption suite (A set);
- Normal App sent to the handshake request, support 26 encryption suite (B set);
- The access server in THE equipment room P supports at least one encryption suite in set B, but does not support all encryption suites in set A.
- The access server in equipment room Q supports at least one encryption suite in set A and at least one encryption suite in set B.
As a result, the App cannot access the site through the server in the machine room P.
2.3.3 summary
As can be seen from the above analysis, the handshake fails in certain cases because the client and server encryption suites do not match. Further solutions to the problem include:
Adjust the client encryption suite to support Cipher Suites (involving the upgrade of the underlying TLS/SSL library on the client);
Add Cipher Suites (involving TLS/SSL access configurations on the server) to the server encryption suite.
The client eventually chose to adjust the server-side encryption suite and the problem was resolved.
3. Summary
From the sharing and practice of the above cases, it can be seen that the symptoms of tlS-level problems on the client side are similar, but the root cause of the problem is very different. Although the problems listed here cannot cover all problem scenarios, the basic troubleshooting ideas are as follows:
Check whether the fault occurs at the TLS/SSL layer.
Network packet capture; If conditions are available, two network packets can be captured for normal and abnormal conditions for subsequent comparative analysis.
According to the network package to explore the direct cause of the problem, and then further explore the root cause of the problem.
Choose an appropriate solution based on the analysis results and business scenarios.
You need to understand the HTTPS and TLS/SSL protocols and analysis tools to troubleshoot these problems. In the mobile space, these kinds of problems are common, and knowing the results and analysis directly can help developers get out of the hole quickly.
reference
- How to grab network packages, help.aliyun.com/document_de…
- The Security with the HTTPS and SSL, developer.android.com/training/ar…
- Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile Tools.ietf.org/html/rfc528…
Colored eggs (Canton)
In view of various security risks such as cracking, tampering, piracy, phishing fraud, memory debugging, and data theft commonly existing in mobile applications on the market, mPaaS “Mobile security Reinforcement” relies on the mobile security reinforcement technology of Ali Cloud Group, and has experienced the security test of tao system and other hundred-million-level applications.
It can effectively provide stable, simple and effective security protection for mobile applications, improve the overall security level of App, and protect the application from reverse cracking. It has a very reliable security guarantee.
✨ Immediate Access security hardening ✨
Follow the public account “mPaaS” and reply to “Security Reinforcement” to get the complete handout “New Direction of APP Reinforcement — Confusion and Slimming”