This paper mainly expounds

  • HTTPS principle and SSL/TLS establishment process
  • Android7.0 HTTPS packet capture problem
  • Charles Packet capture principle

If some students don’t understand, welcome to ridicule, I will correct!

HTTPS: Http over SSL/TLS

HTTPS adds a security layer, or SSL/TLS layer, between the application layer and transport layer compared to HTTP.

The purpose of SSL/TLS is to negotiate a symmetric encryption algorithm that cannot be stolen by a third party

Symmetric encryption, asymmetric encryption, and Hash algorithms are used in the SSL/TLS layer

Asymmetric encryption algorithms: RSA, DSA/DSS Symmetric encryption algorithms: AES, RC4, 3DES HASH algorithms: MD5, SHA1, SHA256Copy the code

The following diagram hardly depicts the process of an SSL handshake in a graphic, concrete, or vivid way

HTTPS request process:

Contents of the certificate:

  • Object (server address, server public key)
  • Digital signature algorithm
  • Certificate Expiration Time
  • Certificate issuer
  • Digital signature of the certificate

Additional:

  1. How to verify the certificate validity: The system pre-installs the root certificates of all trusted certificate authorities. If the issuer of the certificate is not in the pre-installed trust certificate, the system considers the certificate invalid and displays a warning ⚠️

  2. How to verify is the trust certificate of the server we want to connect to: We know that the trust certificate not only awarded to the same person/organization, there may be other institutions with trusted certificates to hijack our request, in order to avoid the problem, is a digital signature is added in the digital certificate, when the client to obtain a certificate after the first will check whether we request the certificate of domain name, then according to in the certificate The content and certificate signature algorithm computes the signature and compares the calculated digital signature with the signature in the current certificate. If the verification succeeds, it fails otherwise. In this way, the following situation is avoided:

    • The domain name in the certificate is the domain name we requested, and the signature is inconsistent

The PRINCIPLE of HTTPS is commonly understood

HTTPS works and TCP handshake mechanism

Diagram of SSL/TLS protocol

Android7.0 uses Charles to capture Https packets and its principle

Have you ever grabbed HTTPS data on Android7.0?

I prefer to use the packet capture tool in the development, if there is a problem, can be more accurate positioning, but in Android7.0 above grab HTTPS, there is a problem

Charles is the request not to capture HTTPS packets by default. If you want to capture HTTPS packets, you need the following Settings:

Using Android7.0 mobile phone find crawl results become..

I’m not happy about that…

Then, after research (after changing the phone test, changing the system version test), it turns out that Google has adjusted for the network on Android 7.0:

By default, secure connections from all applications (using protocols such as TLS and HTTPS) trust the pre-installed system CA, while applications for Android 6.0 (API level 23) and below also trust the user-added CA store by default. Applications can customize their connections using Base-config (application-wide customization) or domain-config (domain-specific customization).Copy the code

It suddenly dawned on me that I hadn’t paid attention to this in 7.0 features

Then I configured it according to the documents on the official website, and finally I got it.

The familiar picture came back.

At that time, IN the process of configuration according to the document, I also had a little thought, that is, since the root certificate configured is Charles, should the domain name also be matched with the IP of the computer? Now I think about this problem, it really is… I did not understand the principle of HTTPS

Because today I looked at the principle of HTTPS and thought about it, what was the process of Charles grabbing HTTPS?

The premise of understanding the next picture is to understand the PRINCIPLE of HTTPS first, as described above:

  1. Install Charles root certificate first, and trust,Android6.0 and below the default trust,Android7.0 must add configuration, see the official website
  2. Initiating a request, this part is unchanged, see HTTPS request procedure above
  3. The server sends the certificate to the client and does not change
  4. At this stage, Charles judged that it was the target domain name. Charles himself generated a certificate and signed it according to the target domain name and the public key of the target server. At this time, the issuer of the certificate changed from a trusted CA institution to Charles
  5. The client gets the certificate, verifies the “real certificate” against Charles’s previously installed root certificate, finds no problem, and proceeds with the normal process
  6. Generate random numbers, send, the client thinks they are really sent to the target server, but it is not
  7. Charles decrypts the message using his private key, encrypts it using the target server’s public key, and sends it to the target server
  8. Charles sent it to the target server
  9. The target server is decrypted and authenticated successfully
  10. The SSL/TLS handshake succeeds, and the client, Charles, and real server all have the key for encrypting transmission information. Charles can parse the following transmitted information through this key and show it to us.