HTTPS Vulnerability in Android program

HTTPS requires a handshake between the client (browser) and the server (Web site) before transmitting the data, which establishes the password information for both parties to encrypt the transmitted data during the handshake. A brief description of the handshake process is as follows:
1. The browser sends a set of encryption rules that it supports to the Web site.
2. The website selects a set of cryptographic algorithms and hash algorithms, and sends its own identity information back to the browser in the form of a certificate. The certificate contains information such as the website address, the encrypted public key, and the issuing authority of the certificate.
3. after obtaining the website certificate, the browser will do the following tasks:
A) Verify the legality of the certificate (the issuing authority is legal, the certificate contains the address of the website is consistent with the address being accessed, etc.), if the certificate is trusted, the browser bar will display a small lock, otherwise the certificate is not trusted to prompt.
b) If the certificate is trusted, or if the user accepts an untrusted certificate, the browser generates a random number of passwords and encrypts them with the public key provided in the certificate.
c) Use the agreed hash to calculate the handshake message, encrypt the message with the generated random number, and then send all previously generated information to the Web site.
4. After the Web site receives the data from the browser, do the following:
A) Use your own private key to decrypt the information to remove the password, use the password to decrypt the browser's handshake message, and verify that the hash is consistent with the browser.
b) Encrypt a handshake message with a password and send it to the browser.
5. The browser decrypts and calculates the hash of the handshake message, if it is consistent with the hash of the server, at which point the handshake process ends, and all the communication data will be encrypted by the random password generated by the previous browser and using the symmetric encryption algorithm.
Here the browser and the Web site to send encrypted handshake message and verify, the purpose is to ensure that both sides have obtained a consistent password, and can be normal encryption and decryption of data, for the subsequent transmission of real data to do a test.

The attack on HTTPS is more of a fake certificate method to spoof the client. In the browser and web site handshake process, the browser will need to verify the legality of the certificate after obtaining the website certificate, in the Android program, Google's API will check the validity of the certificate, check includes the following aspects: whether the signature CA is legal, whether the domain name matches, is not a self-signed certificate, whether the certificate expires. When an exception is found, the request is terminated and an exception is thrown. So developer usually covers Google's certificate checking mechanism (X509trustmanager) to pass the test at the time of Android app development. In the covered detection mechanism, ignoring the security check of the certificate, accepting the exception of the HTTPS certificate, continue the dangerous link.

Exploit this vulnerability to use fake certificates for traffic hijacking (forged fake WiFi, DNS hijacking, etc.).

HTTPS Vulnerability in Android program