Detailed explanation of HTTPS connection process and man-in-the-middle attack and hijacking

https protocol is http+ssl protocol. The connection process is shown in the figure below:

The client sends an https request to the server;

After receiving the request, the server generates the public key and private key. The public key is equivalent to a lock, and the private key is equivalent to a key. Only the private key can open the content locked by the public key;

The server returns the public key (certificate) to the client. The public key contains a lot of information, such as the issuing authority of the certificate, expiration time, etc.;

After the client receives the public key, it will first verify whether it is valid, such as the issuing authority or expiration time, etc. If any problem is found, an exception will be thrown, prompting that there is a problem with the certificate. If there is no problem, then generate a random value as the client's key, and then encrypt it with the server's public key;

The client encrypts the key with the server's public key and then sends it to the server.

The server receives the encrypted key, and then decrypts it with the private key to obtain the client's key. Then the server symmetrically encrypts the content to be transmitted and the client's key, so that unless the key is known, Otherwise there is no way to know what was transmitted.

The server transmits the encrypted content to the client.

After the client obtains the encrypted content, it uses the previously generated key to decrypt it and obtain the content.

https is not absolutely safe. As shown in the figure below, it is a man-in-the-middle hijacking attack. The man-in-the-middle can obtain all communication content between the client and the server.

The middleman intercepts the request sent by the client to the server, and then pretends to be the client to communicate with the server; sends the content returned by the server to the client to the client, and pretends to be the server to communicate with the client.
In this way, all content of the communication between the client and the server can be obtained.
To use a man-in-the-middle attack, the client must trust the certificate of the middleman. If the client does not trust it, this attack method will not work.

The reason for man-in-the-middle hijacking is that the server certificate and domain name are not verified or the verification is incomplete. For convenience, the default verification method of the open source framework is directly used for https requests

Such as volley

OKhttp3.0

Prevention methods:

There are two ways to prevent it

1. For apps with relatively high security requirements, the certificate can be locked by pre-embedding the certificate on the client side. Communication is only allowed when the client certificate and the server certificate are completely consistent, such as some banks. app, but this method faces a problem, the problem of certificate expiration. Because the certificate has a certain validity period, when the pre-embedded certificate expires, it can only be solved by forcing the update or requiring the user to download the certificate.

Take volley as an example: the verification is implemented as follows

Create SSLSocketFactory through pre-embedded certificate;

private static SSLSocketFactory buildSSLSocketFactory(Context context,
                                                      int certRawResId) {
    KeyStore keyStore = null;
    try {
        keyStore = buildKeyStore(context, certRawResId);
    } catch (KeyStoreException e) {
        e.printStackTrace();
    } catch (CertificateException e) {
        e.printStackTrace();
    } catch (NoSuchAlgorithmException e) {
        e.printStackTrace();
    } catch (IOException e) {
        e.printStackTrace();
    }

    String tmfAlgorithm = TrustManagerFactory.getDefaultAlgorithm();
    TrustManagerFactory tmf = null;
    try {
        tmf = TrustManagerFactory.getInstance(tmfAlgorithm);
        tmf.init(keyStore);

    } catch (NoSuchAlgorithmException e) {
        e.printStackTrace();
    } catch (KeyStoreException e) {
        e.printStackTrace();
    }

    SSLContext sslContext = null;
    try {
        sslContext = SSLContext.getInstance("TLS");
    } catch (NoSuchAlgorithmException e) {
        e.printStackTrace();
    }
    try {
        sslContext.init(null, tmf.getTrustManagers(), null);
    } catch (KeyManagementException e) {
        e.printStackTrace();
    }

    return sslContext.getSocketFactory();

Generate a connection that has been verified by SSL and domain name

2 For apps with general security requirements, you can use the method of verifying the domain name, certificate validity, certificate key information and certificate chain

Take volley as an example, rewrite the checkServerTrusted method in HTTPSTrustManager, and enable strong domain name verification

Many applications currently use webview to load H5 pages. If the server uses a certificate issued by a trusted CA, overload WebViewClient's onReceivedSslError() when webView.setWebViewClient(webviewClient). If a certificate error occurs, call the handler directly. .proceed() will ignore the error and continue to load the page with the certificate problem. If handler.cancel() is called, it can terminate the loading of the page with the certificate problem. If there is a problem with the certificate, the user can be prompted for risks and let the user choose whether to load or not. If so, If the security level is relatively high, the page loading can be terminated directly, prompting the user that the network environment is risky:

It is not recommended to use handler.proceed() directly. If the webview needs to strongly verify the server certificate when loading https, you can use HttpsURLConnection to strongly verify the certificate in onPageStarted() to verify the server certificate. If the verification does not pass, stop loading the web page. Of course, this will slow down the loading speed of the web page and requires further optimization. The specific optimization methods are beyond the scope of this discussion and will not be explained in detail here.

The above is the detailed content of Detailed explanation of HTTPS connection process and man-in-the-middle attack and hijacking. For more information, please follow other related articles on the PHP Chinese website!