目录

Network Connection Security Configuration

Overview

Data transmitted between apps and servers must be secure to protect data confidentiality and integrity and prevent sensitive data from being stolen or tampered with. The Transport Layer Security (TLS) protocol is recommended for security purposes.

When an app accesses a cloud server via HTTPS, if the app trusts a user-installed CA certificate, the user can use network proxy tools (such as Fiddler or Charles) to perform man-in-the-middle attacks (such as viewing, tampering with requests and responses) on HTTPS messages, which may pose security risks to the app or the cloud server. Therefore, a CA certificate should be configured for legitimacy verification for the access to a cloud server via HTTPS.

This topic describes how to configure a CA certificate for an app to prevent security risks to the app or cloud server.

Configuring the CA Certificate to Verify the Server Validity

When an app attempts to connect to a server using TLS, the server provides a certificate chain to prove its identity. The app needs to use a trusted CA certificate to verify the validity of the server's certificate chain.

The certificate chain used by a server varies, depending on the scenarios.

  1. Authoritative CA certificates, such as root CA certificates from CFCA and GlobalSign, comply with industry management standards and have passed audit certification. These CA certificates are highly credible.
  2. CA certificates created by enterprises are used for certificate chains of internal servers. Internal apps of enterprises trust these CA certificates.

The CA certificates in the system can be classified into the following types:

  1. Prebuilt CA certificates: The system is prebuilt with industry's mainstream authoritative CA certificates.
  2. App-managed CA certificates: Trusted CA certificates can be prebuilt in an app's HAP, for example, CA certificates created by an enterprise.
  3. User-installed CA certificates: These certificates are private CA certificates installed on the system settings page. This type of certificate has low trustworthiness and can be exploited for man-in-the-middle attacks.

You should properly configure the trusted CA certificates based on service requirements.

Network Connection Security Configuration

[h2]Configuring the System Prebuilt CA Certificates as Trusted Certificates

The apps that provide services for Internet users only need to trust the system's prebuilt CA certificates. By default, the HTTPS connections of Network Kit and Remote Communication Kit trust the CA certificate preset in the system.

By default, HTTPS connections established using Network Kit and Remote Communication Kit trust both system-preinstalled CA certificates and user-installed CA certificates. You can configure HTTPS connections not to trust user-installed CA certificates to enhance security.

If the app uses a third-party library for network connection, you need to set the system's prebuilt CA certificate path /etc/security/certificates.

Example

Use the third-party library curl to establish an HTTPS connection, and set the path of the trusted CA certificate as follows:

curl_easy_setopt(curl, CURLOPT_CATH, "/etc/security/certificates");

[h2]Configuring HTTPS Connections Not to Trust User-Installed CA Certificates

To configure Network Kit and Remote Communication Kit not to trust user-installed CA certificates, configure the network_config.json file in src/main/resources/base/profile as follows:

{
  "network-security-config": {
  },
  "trust-global-user-ca": false,
  "trust-current-user-ca": false
}

[h2]Configuring the Application-Managed CA Certificates as Trusted Certificates

If the app server uses the CA certificates created by an enterprise, you can prebuild the CA certificates in the HAP and configure the app to trust these CA certificates.

After the preceding configurations are complete, the system Network Kit and Remote Communication Kit still trust the prebuilt CA certificates and CA certificates installed by the user. To enhance security, you can configure HTTPS connections not to trust user-installed CA certificate.

[h2]Configuring the User-Installed CA Certificates as Trusted Certificates

The CA certificates installed by users pose security risks. Avoid setting this type of certificates as trusted CA certificates except in the following scenarios:

  1. You need to capture network packets to locate problems and perform tests in app development and debugging process. The user-installed CA certificates are saved in the /data/certificates/user_cacerts/{userid} directory. The value of userid starts from 100.

    The officially released app version should not trust the CA certificates installed by users by default.

  2. The enterprise apps need to access to app servers through the enterprise's proxy server. The CA certificates manually installed by the MDM system or device administrator are saved in the /data/certificates/user_cacerts/0 directory.

[h2]Configuring SSL Pinning

By default, an app trusts the CA certificates prebuilt in the system. If the prebuilt CA issues an untrusted certificate, apps are exposed to attacks. For security-critical apps, such as payment and banking apps, you can use SSL pinning to trust only the public key of the specified server certificate.

SSL pinning can be configured in either of the following ways: If the server domain name is fixed, static SSL pinning is recommended. Otherwise, dynamic SSL pinning is recommended.

SSL pinning requires that the public key of the app cloud server certificate does not change. If the public key changes, you need to modify the certificate public key configured in the app. Otherwise, the network connection of the app will fail. Therefore, it is recommended that the SSL pinning configuration always contain at least one backup public key.

You can also set the expiration time of SSL pinning. After the certificate expires, the certificate is no longer locked. This helps prevent connectivity issues for apps that have not updated their public keys after the public key of the server certificate changes. However, setting the expiration time of SSL pinning may allow attackers to bypass certificate pinning.

You need to evaluate and determine whether to configure SSL pinning. If sensitive information is encrypted or signed at the app layer, the security risk is low.

  1. Configure static SSL pinning in the network_config.json file.

    {
  "network-security-config": {
    "domain-config": [
      {
        "domains": [
          {
            "include-subdomains": true,
            "name": "server.com"
          }
        ],
        "pin-set": {
          "expiration": "2024-11-08",
          "pin": [
            {
              "digest-algorithm": "sha256",
              "digest": "g8CsdcpyAKxmLoWFvMd2hC7ZDUy7L4E2NYOi1i8qEtE="
            }
          ]
        }
      }
    ]
  }
}

    For details, see Certificate Pinning.

  2. Set the following parameters in the code to configure dynamic SSL pinning:

    • Configure dynamic SSL pinning using Network Kit:

      certificatePinning: [
   {
     publicKeyHash: 'g8CsdcpyAKxmLoWFvMd2hC7ZDUy7L4E2NYOi1i8qEtE=',
     hashAlgorithm: 'SHA-256'
   }, {
     publicKeyHash: 'MGFiY2UyMDk5ZjEyMzI3MWQ4MDMyY2E4ODEzMmY3EtE=',
     hashAlgorithm: 'SHA-256'
   }
 ]

      For details, see certificatePinning.

    • Configure dynamic SSL pinning using Remote Communication Kit:

      const keyHash: string = 'g8CsdcpyAKxmLoWFvMd2hC7ZDUy7L4E2NYOi1i8qEtE=';
const session = rcp.createSession();
const request = new rcp.Request(HTTP_SERVER);
const pin: rcp.CertificatePinning = {
  kind: 'public-key',
  publicKeyHash: keyHash,
  hashAlgorithm: 'SHA-256'
};
request.configuration = {
  security: {
    certificatePinning: pin,
  }
};
const resp = await session.fetch(request);

      For details, see certificatePinning in the configuration guide.