Origin: Why do we need HTTPS

HTTP: a double-edged sword

  • Simple and flexible (advantage)

If you think about the Request we see in development, it’s pretty simple: Header + Body, then Request and Response again, and even plaintext transmission, this is all HTTP protocol, even the Header field is not specified, ready to be extended and interpreted by developers. Of course, this reliability is also demonstrated in the fact that HTTP doesn’t care what the underlying protocol is. In any case, as long as you keep the semantics of the upper HTTP protocol stable, it is theoretically possible to transmit over any of the underlying protocols.

  • Wide application (advantage)

With the development of the Internet, the maturity of various hardware and software facilities and the acceleration of network speed, HTTP has become ubiquitous. When we open Douyin, we are using HTTP, when we click B station, we are using HTTP, when we start a game of glory, HTTP is also operating behind, HTTP can be said to be everywhere.

  • Stateless (advantages/disadvantages)

First we should know what stateful protocols are: Most network protocols, such as SMTP commonly used for mail, need to go through a series of handshakes (HELO → AUTH) to SEND and QUIT step by step. In essence, it is a state machine. Both sides of communication need to know the current connection status clearly. The data transmitted by the previous command should also be clear, which will affect subsequent requests. This protocol is a stateful protocol, and our HTTP (strictly HTTP 1.x), each request is completely independent, each request contains the complete data required to process the request, sending the request does not involve state change. Even with HTTP/1.1, where the same connection allows multiple HTTP requests to be sent, subsequent requests can generally continue to be processed if the first request fails. This statelessness eliminates the need for the server to pay attention to additional state information, which in other words, takes the strain off the server, and thanks to this, there is virtually no difference between any other machine handling HTTP requests, we can simply achieve high concurrency through load balancing and heap machines. However, this can also bring additional burden, such as our background management page, without user status maintenance, we can not connect user operations. Hence the J solution for cookie and Token headers.

  • Plaintext transmission and insecurity (pros/cons)

Different from binary transmission protocols such as TCP and UDP, HTTP packets, namely the HEADER part, are all simple and readable text formats, which brings us convenience of development but also increases insecurity because of stateless. HTTP protocol also can not be authentication and integrity verification, anyone in the middle of the request to hijack, tamper with your request, save your user information for other purposes.

By reviewing the advantages and disadvantages of HTTP protocol, we can quickly find that HTTP protocol has huge security problems. Anyone can intercept your request in any network environment (think Charles capture) and tamper with it, which is in many online scenarios with high security requirements: E-commerce and banking are totally unacceptable, so HTTPS came into being.

Safety: HTTPS

What is security

We need to know that a transport protocol is secure only if it has the following characteristics:

Confidentiality: The communication between users must be secure from the details of the middleman. This is the kind of information that can be classified if the spy intercepts the cable but has no code book and can only watch the message pass.

Integrity: communication between the user must be able to verify whether the message is complete has not been tampered with, that we can use some unscrupulous media reports, for example, because the reader can’t verify the integrity of the news, so can only see some news media, and are guided to produce the completely wrong cognition and views, this report is not have integrity.

Identity authentication: the user must be clear communication between the communication object is really each other or step in, the place we can still use old resistance plays a speak, advance the plot to password by the spy to hand, cracked the telegraph even forged false news, the consequences of all this.

Non-repudiation: communication between users must ensure that every exchange is non-repudiation, there should not be a situation in which the data receiving party denies receiving the information.

What’s the difference between HTTPS and HTTP?

There is no difference between HTTP and HTTP in terms of the top-level protocol. HTTP inherits all the advantages of HTTP and improves its security thanks to the emergence of SSL/TLS. Only the protocol name is changed to HTTPS (HTTP + SSL/TLS) and the default port number is changed to 443. The simple protocol layering is as follows:

You can see that HTTPS transmits packets through a dedicated secure interface instead of invoking the Socket API through TCP/IP.

What is the SSL/TLS

SSL is the Security interface Layer. After years of development, it was renamed TLS (Transport Layer Security). It consists of several different sub-protocols:

  • Log protocol: Sends all subprotocols
  • Handshake protocol: the browser and server exchange password suite, TLS version number, random number and other information required for subsequent encryption
  • Warning protocol: Alerts users when there is a problem with their protocol version or certificate
  • Change password protocol: Notifies the other party that subsequent requests will be encrypted and sent using the previously exchanged information
  • Extended protocol: Extends TLS through this protocol

How does SSL/TLS guarantee security?

TLS1.2 How to Establish a connection

The key nodes are as follows:

  • ClientHello: Notifies the server that the connection is about to start, passing a random number CR generated by the client, the TLS version number and its supported cipher suite (key exchange algorithm + signature algorithm + symmetric encryption algorithm + digest algorithm), and an extended list for the server to select.
Handshake Protocol: Client Hello Version: TLS 1.2 (0x0303) Random: 1CBF803321FD2623408Dfe... Cipher Suites (17 suites) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)Copy the code
  • ServerHello: The Server detects the TLS version number, selects the appropriate password suite if it is supported, generates a Server Random on the Server side, and determines whether additional Server Params (via Server Key Exchange) need to be transmitted according to the selection of the password suite. And the certificate it uses to facilitate the server to perform the checksum following encrypted communication (note: the server’s public key is exchanged here to the client).
Handshake Protocol: Server Hello Version: TLS 1.2 (0x0303) Random: 0E6320F21Bae50842E96... Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)Copy the code
Handshake Protocol: Server Key Exchange
    EC Diffie-Hellman Server Params
        Curve Type: named_curve (0x03)
        Named Curve: x25519 (0x001d)
        Pubkey: 3b39deaf00217894e...
        Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
        Signature: 37141adac38ea4...
Copy the code
  • ClientKeyExchange: After receiving the server’s certificate, the client will look up layer by layer until it finds the system’s or browser’s built-in root certificate. (Charles can grab HTTPS requests because it provides a root certificate that you can build into the system or browser.) After confirming that it is secure, the connection is initiated and a Client Params encrypted by the key exchange algorithm is exchanged (which varies under different symmetric encryption algorithms). Since both parties share Client Params/Server Params/ClientRandom, the pre-master (non-RSA) is calculated directly from Client Params and Server Params. After that, both parties will calculate the real Master key and session key based on Server Random, Client Random and pre-master.
Handshake Protocol: Client Key Exchange EC Diffie-Hellman Client Params Pubkey: 8C674D0E08DC27b5EAA... // If this is an RSA algorithm, it swaps the pre-master directlyCopy the code

  • ClientChangeCipherSpec: When the primary key and session key in place, the client will inform the service side after all messages will be in agreement with the session key encryption algorithm to encrypt, and before all the news of the passing through the algorithm calculated in the request to the server, let the server-side validation is a client sends a message before, And whether the encryption is correct (integrity, confidentiality, identity authentication).

  • ServerChangeCipher: After receiving a message and verifying the message, the server calculates and transfers the previous message like the client. After verifying the message, the two parties shake hands and start communication.

It looks like TLS1.2 has solved the security problem well by mixing three random numbers and encrypting them again, so the question comes, is it easy to use? The answer, of course, is no: a TLS1.2 handshake requires two round trips of messages (2-RTT), almost as many as TCP/IP, which adds extra connection time, especially when the network environment deteriorates.

The better the TLS

In order to solve the security problems of some algorithms in TLS, in the new version of TLS, the insecure encryption suite is removed, and for better compatibility, the upgrade to the new version of TLS uses the extended protocol to store the updated information, and to reduce the handshake process. It brings the password suite and params corresponding to the password suite to the server in the first Hello. When the server receives the password suite, it has acquired the ClientParams and completely removes the KeyExchange step of the Client. There is only one message round trip (1-RTT) per handshake. For the specific process, please refer to the following figure:

conclusion

Now, the TLS1.3 of HTTPS has been in 2018. With the development of the network, users have increased their demands on the network. Although TLS1.3 has done quite well, it is still based on HTTP 1.x. It inherits the advantages of HTTP 1.x, but also inherits some disadvantages of HTTP 1.x, such as large packet information, such as queue header blocking, hence HTTP/2. HTTP/2 still didn’t solve TCP’s queue header blocking, so QUIC came along. The protocol will only be updated in endless iterations, but the choice is still up to you: it depends on your needs. Good as the New Deal is, don’t drink.