Implementation of HTTPS communication in Android system
Preface recently, there is a problem related to HTTPS that needs to be solved. Therefore, I took the time to learn about the use of HTTPS on Android platform. At the same time, I also saw some HTTPS principles. Here I share my learning experience.
HTTPS principle HTTPS (Hyper Text Transfer Protocol Secure) is a kind of HTTP based on SSL / TLS. All HTTP data is transmitted on the SSL / TLS protocol encapsulation. HTTPS protocol is based on HTTP protocol and adds SSL / TLS handshake and data encryption transmission. It also belongs to application layer protocol. Therefore, to study the principle of HTTPS protocol is to study SSL / TLS protocol. The role of SSL / TLS protocol is HTTP communication without SSL / TLS, that is, unencrypted communication. All information is transmitted in clear text, which brings three risks: 1. Eavesdropping risk: a third party can know the communication content. 2. Tampering risk: a third party can modify the contents of the notice. 3. Risk of impersonation: a third party may participate in communication by impersonating others. SSL / TLS protocol is designed to solve these three risks, hoping to achieve: 1. All information is encrypted transmission, and the third party cannot eavesdrop. 2. It has a verification mechanism. Once it is tampered, both sides of the communication will find it immediately. 3. Provide identity certificate to prevent identity from being impersonated. The basic operation process the basic idea of SSL / TLS protocol is to use the public key encryption method, that is, the client first asks the server for the public key, and then encrypts the information with the public key. After the server receives the ciphertext, it decrypts it with its own private key. But here we need to understand the solutions to two problems. 1. How to ensure that the public key is not tampered with? Solution: put the public key in the digital certificate. As long as the certificate is trusted, the public key is trusted. 2. Public key encryption requires too much computation. How to reduce the time consumed? Solution: for each session, the client and server generate a "session key" to encrypt the information. Because the "conversation key" is symmetrically encrypted, the operation speed is very fast, and the server public key is only used to encrypt the "conversation key" itself, which reduces the consumption time of encryption operation. Therefore, the basic process of SSL / TLS protocol is as follows: 1. The client requests and verifies the public key from the server. 2. Both parties negotiate to generate "dialogue key". 3. Both parties use "dialogue key" for encrypted communication. The first two cloth of the above process are also called "handshake stage". Detailed process of handshake phase
The "handshake phase" involves four communications. It should be noted that all communications in the "handshake phase" are in clear text. The client sends a request (clienthello). First, the client (usually the browser) sends a request for encrypted communication to the server, which is called a clienthello request. In this step, the client mainly provides the server with the following information: 1. Supported protocol versions, such as TLS version 1.0. 2. A random number generated by the client, which is later used to generate a "conversation key". 3. Supported encryption methods, such as RSA public key encryption. 4. Supported compression methods. It should be noted that the information sent by the client does not include the domain name of the server. In other words, theoretically, the server can only contain one website, otherwise it will be difficult to distinguish which website's digital certificate the application provides to the client. This is why usually a server can only have one digital certificate. Server Hello: after receiving the client request, the server sends a response to the client, which is called server hello. The server's response includes the following contents: 1. Confirm the encrypted communication protocol version used, such as TLS version 1.0. If the browser is inconsistent with the version supported by the server, the server will turn off encrypted communication. 2. A random number generated by a server, which is later used to generate a "conversation key". 3. Confirm the encryption method used, such as RSA public key encryption. 4. Server certificate. In addition to the above information, if the server needs to confirm the identity of the client, it will include another request to ask the client to provide "client certificate". For example, financial institutions often only allow authenticated customers to connect to their own network, and will provide formal customers with USB key, which contains a client certificate. After receiving the server response, the client first verifies the server certificate. If the certificate is not issued by a trusted authority, or the domain name in the certificate is inconsistent with the actual domain name, or the certificate has expired, a warning will be displayed to the visitor to choose whether to continue communication. If there is no problem with the certificate, the client will take the server's public key from the certificate. Then, send the following three messages to the server. 1. A random number. The random number is encrypted with the server public key to prevent eavesdropping. 2. The code change notice indicates that the subsequent information will be sent with the encryption method and key agreed by both parties. 3. The client handshake end notification indicates that the handshake phase of the client has ended. This item is usually the hash value of all the contents sent earlier, which is used for server verification. The first random number above is the third random number in the whole handshake stage, also known as "pre master key". With it, the client and server will have three random numbers at the same time, and then both parties will use the encryption method agreed in advance to generate the same "session key" used in this session. The server's last response: after receiving the third random number pre master key from the client, the server calculates the "session key" used to generate this session. Then, send the following information to the client finally. 1. The code change notice indicates that the subsequent information will be sent with the encryption method and key agreed by both parties. 2. The server handshake end notification indicates that the handshake phase of the server has ended. This item is also the hash value of all the previous contents, which is used for client verification. At this point, the whole handshake phase is over. Next, the client and the server enter the encrypted communication, which completely uses the ordinary HTTP protocol, but encrypts the content with the "session key".
The server builds an HTTPS virtual site based on nginx. The previous article introduced in detail how to generate SSL certificates on the server side and build an HTTPS server based on nginx. Link: building an HTTPS server based on nginx
Android implements HTTPS communication for various reasons. Here we use the httpclicent class to explain how Android establishes HTTPS connection. The code demo is as follows. MainActivity.java
HttpUtils.java
activity_ main.xml
Android uses defaulthttpclient to establish HTTPS connection. The key is to add HTTPS support:
By adding support for HTTPS, you can effectively establish an HTTPS connection, such as“ https://www.google.com.hk ”However, you can't access your own HTTPS server based on nginx because it uses a custom certificate that is not recognized by the system. The following problems will be reported: no peer certificate. The way to solve the problem that the certificate is not recognized by the system is to skip the system verification by using the user-defined certificate and ignoring the HTTPS connection method of verification. To skip the system verification, you can no longer use the system standard SSL socketfactory. You need to customize one. Then, in order to skip verification in this custom SSL socketfactory, you need to customize a trustmanager to ignore all verifications, that is, trustall.
At the same time, you need to modify the register method of defaulthttpclient to sslsocket built by yourself:
In this way, you can successfully access your own HTTPS virtual site based on nginx. Defect: however, although HTTPS is used in this scheme, the communication content between the client and server is encrypted, and the sniffer cannot get the transmitted content, it cannot resist the "man in the middle attack". For example, configure a DNS in the intranet to resolve the domain name of the target server to a local address, and then use an intermediate server on this address as a proxy. It uses a fake certificate to communicate with the client, and then the proxy server as the client connects to the actual server and communicates with the server with a real certificate. In this way, all communication contents will pass through the proxy, and the client will not perceive it. This is because the client does not verify the server's public key certificate.
Use a custom certificate to establish an HTTPS connection. In order to prevent the "man in the middle attack" that may be caused by the above scheme, we can download the server-side public key certificate, then compile the public key certificate into the Android application, and the application will verify the certificate itself. Generate keystore
To verify the custom certificate, you must first compile the certificate into the application, which requires the keytool tool to produce the keystore file. The certificate here refers to the public key of the target server, which can be obtained from the. CRT file or. PEM file configured by the web server. At the same time, you need to configure bouncy castle. I downloaded bcprov-jdk16-145.jar. As for the configuration, just Google by yourself.
After running, the certificate content will be displayed and you will be prompted to confirm. Enter y and press enter.
After the keystore file is successfully produced, put it in the RES / raw directory of the app application. The idea of using a custom keystore to connect is similar to that of trustall. A custom sslsokcetfactory is also required. However, because the certificate needs to be verified, there is no need to customize the trustmanager.
At the same time, you need to modify the register method of defaulthttpclient to sslsocket built by yourself: