Preface – What do you get from reading this article

1. Understand the basic principles and process of HTTPS encryption and why HTTPS is secure

2. Understand what man-in-the-middle attack is and the basic principle of it

3. Know how to prevent man-in-the-middle attacks

Basic principles of HTTPS encryption

What HTTPS is supposed to accomplish

1. The Client must be sure that the Server it accesses is the correct one

2. The information exchanged between the Client and Server cannot be eavesdropped by any third party

3. The Server can also request that it be sure that the Client is the correct one it wants to communicate with

The above requirements are met by establishing an encrypted channel through an HTTPS handshake

HTTPS three handshakes

The three-way handshake process is as follows:

Handshake Main tasks:

1. The client communicates with the server to negotiate the encryption mode

2. The Client and Server identify each other

3. The two parties securely exchange the Session Key used for HTTPS communication.

Phase 1: C&S negotiation encryption

The client sends ClientHello information to the server, including the encryption mode and SSL version supported by the client. After the server receives the ClientHello message, it sends a ServerHello message to the client, telling the client what encryption method and SSL version it will use.

Stage 2: Identity verification

In phase 2, the client and server verify each other’s identity

Authentication between client and server is done through certificates

1. Certificates:

The server issues its own certificate, usually a CA certificate, to the client. A certificate contains a lot of information, including public key information, signature, organization region information, certificate authority, medium certificate, root certificate, and so on.

X.509 should be a popular STANDARD for SSL digital certificates and contains (but is not limited to) the following fields:

field The value that
Object Name Information used to identify the digital certificate
Common Name For customer certificates, this is usually the corresponding domain name
Issuer Name Information about the entity that publishes and signs the certificate
Signature Algorithm The algorithm used for the signature
Serial Number The Certificate Authority (CA) assigns a unique integer to a Certificate. Each digital Certificate has a serial number
Not Valid Before (‘ ω · ´)
Not Valid After (╯ ° °) ╯ (┴ – ┴
Public Key A public key
Signature The data obtained after the certificate content is calculated using the signature algorithm is used to verify whether the certificate is tampered

It’s basically a signature to verify that it’s not tampered with

2. How does the client use the certificate to identify the server?

Prove the following two points (before you can use the public key on the certificate to encrypt and generate a random Session key)

  1. Prove the certificate of Baidu.com is indeed baidu
  2. Prove that Baidu.com this certificate has not been seized by others

Certificates are organized in the form of a certificate chain. During certificate issuance, a root certificate issued by the root CA authority, an intermediate CERTIFICATE issued by the root CA authority, and an SSL certificate issued by the intermediate CA authority are required.

Digital certificates are authenticated by trust chain. The trust anchor (the starting point of trust) for digital certificates is the root certificate Authority. A root certificate is an unsigned or self-signed certificate. Is a public key certificate used to identify the root certificate Authority (CA).

The specific implementation of verification is shown in the figure below:

  1. From left to right, the user certificate points to the intermediate certificate that signed it, and the summary of the user certificate is encrypted by the private key of the intermediate certificate, and the ciphertext is recorded on the user certificate as the certificate signature of the user.
  2. The intermediate certificate correspondingly points to the root certificate that signed it. At the same time, the abstract of the intermediate certificate is encrypted by the private key of the root certificate, and ciphertext is recorded on the intermediate certificate as the signature of the intermediate certificate
  3. When signing a root certificate, the private key of the issuing authority is used to encrypt the summary of the certificate. The ciphertext is recorded on the root certificate as the signature of the root certificate.

How to Verify certificates

1. How do I verify that the certificate is not tampered with

For example, to verify user certificate A, we need to use the public key B of the intermediate certificate to decrypt the former’s signature and get Digest1. Our client also calculates the content of certificate A to get Digest2. Comparing the two summaries shows whether the former has been tampered with. The latter, similarly, is authenticated using the public key provided by his certificate issuer. When you validate to a trusted root certificate, you can determine that the certificate is trusted.

2. Why is the root certificate trusted

The CA root certificates signed and managed by the Certificate Authority (CA) are included in the trusted certificates list of your browser and operating system. This list determines whether the root Certificate is trusted. So don’t import weird root certificates into your operating system.

Stage 3: Generate the communication key

As mentioned earlier, in stage 1, the server informs the client of the encryption method to be used later (symmetric encryption is generally used because asymmetric encryption is expensive and slow).

In phase 2, the client verifies that the server certificate is correct. That is, the public key marked on the certificate is used to encrypt information. After encryption, only the server can decrypt the information, but no third party can decrypt the information. Then in the third stage, the client generates a third random number called PMSc (a premaster secret, 46 bytes), encrypts the PMSc with the public key of the server, and sends it to the server. After obtaining the ciphertext, the server decrypts it with its own private key to obtain PMSc.

Well, the next most important step is coming: according to the encryption method negotiated before, and three random numbers, the client and the server generate communication Key respectively, which is called Master Secret, MS for short, also known as Session Key. Although the keys are generated separately, they are the same after being generated.

Stage 4: The encrypted channel has been established

After the client and server each generate a communication key, they use the same MS to encrypt all subsequent communication information. And this key, the third party doesn’t know, the third party can snoop, but they can’t read the message, so the effect is that the client and the server are communicating in an encrypted channel.

As can be seen from the above, HTTPS communication process is a mixture of symmetric and asymmetric encryption

Man-in-the-middle attack and HTTPS packet capture

A man-in-the-middle attack on SSL goes like this:

In fact, the middleman is a stealthily changing of the post, the core is how to deceive the client, so that the client can be assured of data interaction with the middleman without any awareness. There are many tutorials on how fiddlers can do this in a few steps. The most important is:

Install a digital certificate issued by a private CA into the mobile phone and save it as a trusted certificate

After the private CA certificate is added to the system trust certificate, the certificate chain verification process can be completed

Fiddler caught process, details: www.cnblogs.com/afeng2010/p…

User CA restrictions after android7.0

Android no longer trusts user CA certificates as of 7.0 (targetSdkVersion >= 24, targetSdkVersion < 24 will be trusted even if the system is 7.0+). This means that even if the user CA certificate is installed, on Android 7.0+ machines, the HTTPS package of the application targetSdkVersion >= 24 will not be caught.

The default network security configuration for Android 6.0 (API 23) and below is as follows:

<! - the default allows all clear communication -- -- > < base - config cleartextTrafficPermitted ="true"> <trust-anchors> <! -- Trusted systems pre-install CA certificates --> <certificates SRC ="system"/ > <! -- Trust user-added CA certificates, such as those installed by Charles and Fiddler tools --> <certificates SRC ="user" />
    </trust-anchors>
</base-config>
Copy the code

The default network security configuration for Android 7.0 (API 24) through Android 8.1 (API 27) is as follows:

<! - the default allows all clear communication -- -- > < base - config cleartextTrafficPermitted ="true"> <trust-anchors> <! -- Trusted systems pre-install CA certificates --> <certificates SRC ="system" />
    </trust-anchors>
</base-config>
Copy the code

The default network security configuration for Android 9.0 (API 28) and later is as follows:

<! - the default ban all clear communication -- -- > < base - config cleartextTrafficPermitted ="false"> <trust-anchors> <! -- Trusted systems pre-install CA certificates --> <certificates SRC ="system" />
    </trust-anchors>
</base-config>
Copy the code

If we want to grab our own APP package, we can do this by using the following network security configuration of Android 6.0: add res/ XML /network_security_config.xml:

<? xml version="1.0" encoding="utf-8"? > <network-security-config> <base-config cleartextTrafficPermitted="true">
        <trust-anchors>
            <certificates src="system" />
            <certificates src="user" />
        </trust-anchors>
    </base-config>
</network-security-config>
Copy the code

Then point to the file in the manifest file:

<? xml version="1.0" encoding="utf-8"? > <manifest ... > <application android:networkSecurityConfig="@xml/network_security_config". >... </application> </manifest>Copy the code

How do I prevent man-in-the-middle attacks

From the above explanation, you can see

Assuming you don’t have a trusted certificate installed on your device, HTTPS communication is generally safe in any WIFI or network environment

And on android7.0 and above, even if the phone installation trusts the certificate, it is generally safe, because android7.0 and above does not trust the user certificate by default

So in general, we don’t need to do anything special to prevent man-in-the-middle attacks, right

However, some financial apps need extra verification to ensure HTTPS security

You can download the public key certificate on the server and compile it into an Android application. Generally, the public key certificate is saved in the Assets folder. The application verifies the validity of the certificate during interaction.

    // Use the built-in certificate
    public static SSLSocketFactory getSSLSocketFactory_Certificate(Context context) {
        try {
            // Get the built-in certificate in X.509 format
            CertificateFactory certificateFactory = CertificateFactory.getInstance("X.509");
            KeyStore keyStore = KeyStore.getInstance(KeyStore.getDefaultType());
            keyStore.load(null);
            Collection<? extends Certificate> cers = certificateFactory.generateCertificates(context.getAssets().open("CACertificate.cer"));
            int index = 0;
            for (Certificate certificate : cers) {
                String certificateAlias = Integer.toString(index++);
                keyStore.setCertificateEntry(certificateAlias, certificate);
            }
            // Use this KeyStore to boot the generated TrustManager to provide validation
            final TrustManagerFactory trustManagerFactory = TrustManagerFactory.getInstance(TrustManagerFactory.getDefaultAlgorithm());
            trustManagerFactory.init(keyStore);
            // Generate SSLContext with TrustManager
            SSLContext sslContext = SSLContext.getInstance("TLS");
            sslContext.init(null, trustManagerFactory.getTrustManagers(), new SecureRandom());
            / / return to SSLSocketFactory SSLContext
            return sslContext.getSocketFactory();
        } catch (Exception e) {
            throw newRuntimeException(e); }}Copy the code

conclusion

This article mainly introduces the basic process and principle of HTTPS, and introduces the principle and prevention of man-in-the-middle attack, hoping to help you.

The resources

HTTPS Series 1 — HTTPS three-way handshake

Authentication of HTTPS certificate chain in iOS

Android platform HTTPS packet capture solution and problem analysis

HTTPS principle and OKHTTP support for HTTPS

How to prevent man-in-the-middle attack and Charles packet capture in Https requests on Android

HTTPS, certificates, and Charles packet capture

Android 7.0 + Charles and Fiddler can’t grab HTTPS packets