Learn about https
The main idea of HTTPS is to create a secure channel on an insecure network, and when appropriate encryption packages and server certificates can be verified and trusted, provide reasonable protection for eavesdropping and man-in-the-middle attacks
HTTPS trust inheritance is based on the Certificate Authority pre-installed in the browser (that is, "I trust the Certificate Authority to tell me what I should trust "). Therefore, an HTTPS connection to a website can be trusted and the following conditions must be met:
1. Users believe that their browsers have correctly implemented HTTPS and installed the correct Certificate Authority;
2. You believe that the certificate authority only trusts valid websites;
3. The accessed website provides a valid certificate, meaning that it is issued by a trusted Certificate Authority (most browsers will warn of invalid certificates );
4. The certificate correctly verifies the website to be accessed (for example, the certificate sent to "example Inc." Instead of other organizations when accessing https: // example );
5. the nodes related to the Internet are trustworthy, or the user believes that the encryption layer (TLS or SSL) of this Protocol cannot be damaged by the listener.
HTTPS Workflow
(Data encryption and authentication)
1. Secure channels are divided into two parts: Data Encryption and identity authentication.
2. HTTPS uses SSL at the application layer to Encrypt HTTP data. How is it encrypted? I used the Bank web page for online credit card query as an example to describe the whole process of SSL over encrypted HTTP.
3. The first step is to verify the identity. Does it make sense if the identity is incorrect? There are many ways to authenticate your identity. The most popular method is to issue certificates from CA. Ca is a third-party institution trusted by both parties, so it guarantees that I am my account, and the bank is a bank! However, banks do not often use CA for individuals because it is difficult to set up ca. Banks often use another method, such as the password card of the Agricultural Bank and the mobile phone binding of the Bank of Communications, to determine the user's identity and prevent others from using your identity to log on to your account.
4. When the user opens the IE browser and enters https: // to access the bank's webpage, The first reason is that the user's IE will resolve the domain name into an IP address and request the remote server's corresponding port number through port 443, A listening process on the server is waiting for the user's access. After receiving the request, the server establishes a connection. The user will send the encryption methods and algorithms that the server can use (this is what the browser can recognize, different browsers will send different contents). The server will select an encryption method from the encryption method sent by the client and send it to the client, in this way, the client can know the algorithm used by the server to encrypt data. Now it's just a negotiation, and the data is still plain text.
5. Next, the server will send a certificate. The certificate is the ID card issued by the CA to prove its identity. The certificate contains the public key of the server. If the client does not trust the CA, an alarm message will pop up, the system prompts you to have a certificate sent by an untrusted Ca and asks you how to handle it. After you click "receive", the certificate is saved in the browser. At the same time, the server will require the client to verify its identity, such as entering the verification code sent from the mobile phone, or entering the numbers on the password card into the webpage. If you enter the correct information, the server will verify your identity.
6. Next, the client will generate a random password, which is used to encrypt data. However, if this password is known to hackers, It is very insecure, therefore, this password is encrypted with the public key of the server certificate, and the encrypted ciphertext is transmitted to the server, because only the server has its own private key, therefore, the server will be able to decrypt the password data encrypted by the public key, and the server will certainly use the private key to decrypt the data, so that both parties will know what key to use for encryption, then, the specific data is encrypted using the key and the encryption algorithm negotiated in the first phase.
For how HTTP works, see: http://www.guokr.com/post/114121/
Browser implementation
When you connect to a website that provides invalid certificates, the older browser will use a dialog box asking you if you want to continue, and the newer browser will display a warning throughout the window; newer browsers also highlight the Security Information of the website in the address bar (for example, the extended verification certificate will display the green lock mark in the address bar in Firefox ).
When browsers such as Internet Explorer and Firefox contain a mixture of Encrypted and unencrypted content, a warning is triggered.
Client implementation
Why is HTTPS slow?
TCP only requires three handshakes. However, in addition to the three handshakes, SSL/TLS Based on TCP also requires about ten handshakes for key exchange. For SSL-based https, you must use a handshake to encrypt the data based on the SSL/TLS connection.
Because the HTTPS connection process and data transmission process involve key exchange, key generation, data encryption, and other columns, it is normal to open an HTTPS page for about 10 seconds.
Notes for using HTTPS on mobile clients
1. Does the mobile phone support CA authentication? What should I do if it does not support or does not?
Check the security of mobile phones and set the trusted Ca (Certification Authority, Certification Center). CA authentication is generally supported by mobile phones. However, nowadays, Android mobile phones are rampant, and some systems are highly customized, I cannot guarantee that all mobile phones support CA authentication. Therefore, we need to provide relevant solutions during the demand review. What should I do if CA authentication is not supported on mobile phones? Our practice is to use our own certificate for authentication.
2. A downgrade plan should be available when the request times out or fails.
As mentioned above, https requests are slower than HTTP requests, and user scenarios are also different. Tests in scenarios with limited time alone are not enough. Therefore, timeout is a common phenomenon, what should I do when the request times out? Our practice is to switch to HTTP when the request times out once. In addition, the server adds a control switch. When we observe that the request times out too much data, we can turn it off and switch it to HTTP;
3. Mobile network adaptation
Wi-Fi, 2g, 3g of the three major carriers, and access points (cmwap \ cmnet \ uniwap \ uninet \ ctwap \ ctnet), including enabling some proxy software, which must be adapted, because the proxy gateways of different networks and access points are different, it is hard to say whether the HTTPS you use can penetrate these gateways. Therefore, you can only adapt them.
4. Tracking request failures
Tracking and log collection of HTTPS connection failures to facilitate troubleshooting and provide a better user experience