7 pictures to help you understand the difference between HTTP and HTTPS!

1. Introduction to HTTP Protocol

👨‍🏫 Interviewer: Please briefly introduce the HTTP protocol!

👨‍💻 Dabai: HTTP protocol, full name Hypertext Transfer Protocol. As the name implies, HTTP protocol is used to regulate the transmission of hypertext, which is a variety of messages including text on the Internet. Specifically, it is mainly used to regulate the behavior of browsers and servers. In addition, HTTP is a stateless protocol.

👨‍🏫 Interviewer: How do you understand the stateless protocol?

👨‍💻 Dabai: That is to say, the server does not maintain any information about the client's past requests. This is actually a lazy policy. Stateful protocols are more complicated and require state maintenance (historical information). Moreover, if the client or server fails, state inconsistencies will occur, and the cost of resolving such inconsistencies is higher.

👨‍🏫 Interviewer: What are the advantages of the HTTP protocol?

👨‍💻 Dabai: The main advantages of HTTP are: strong scalability, fast speed, and good cross-platform support.

👨‍🏫 Interviewer: Which protocol layer does HTTP belong to?

👨‍💻 Dabai: HTTP is an application layer protocol. It uses TCP (transport layer) as the underlying protocol and the default port is 80.

👨‍🏫 Interviewer: Can you briefly introduce the HTTP communication process?

👨‍💻 Dabai: The HTTP communication process is mainly as follows:

• The server is waiting for client requests on port 80
• The browser initiates a TCP connection to the server (creates a socket)
• The server receives a TCP connection from the browser
• The browser (HTTP client) exchanges HTTP messages with the web server (HTTP server)
• Closing a TCP Connection

2. Introduction to HTTPS Protocol

👨‍🏫 Interviewer: Please briefly introduce the HTTPS protocol!

👨‍💻 Dabai: HTTPS (Hyper Text Transfer Protocol Secure) is a more secure version of HTTP. HTTPS is based on HTTP and uses TCP as the underlying protocol, and additionally uses SSL/TLS for encryption and security authentication. The default port number is 443. In the HTTPS protocol, the SSL channel usually uses a key-based encryption algorithm, and the key length is usually 40 bits or 128 bits.

👨‍🏫 Interviewer: What are the advantages of the HTTPS protocol?

👨‍💻 Dabai: The main advantages of HTTPS are: good confidentiality and high trust. Because HTTP and HTTPS have their own advantages in different demand scenarios, even though HTTPS makes up for the poor confidentiality of its predecessor HTTP, HTTP still occupies the mainstream of the Internet and performs its own duties with HTTPS. In fact, some sites with better robustness now have both HTTP and HTTPS. When visiting a website with an http prefix, it will automatically jump to https, which has achieved the requirements of high confidentiality and high trust.

3. HTTPS Core Protocol - SSL/TLS

The reason why HTTPS can meet high security requirements is that it combines SSL/TLS and TCP protocols to encrypt communication data and solve the problem of HTTP data transparency. Next, we will focus on the working principle of SSL/TLS.

👨‍🏫 Interviewer: What is the difference between SSL and TLS?

👨‍💻 Dabai: There is not much difference between SSL and TLS. SSL refers to the Secure Sockets Layer, which was first released in 1996. The first release of SSL was actually its 3.0 version. SSL 1.0 has never been released, and SSL 2.0 has a major flaw (DROWN flaw - Decrypting RSA with Obsolete and Weakened eNcryption). Soon, in 1999, SSL 3.0 was further upgraded and the new version was named TLS 1.0. Therefore, TLS is based on SSL, but due to customary naming, the core encryption protocol in HTTPS is usually confused as SSL/TLS.

Asymmetric encryption

👨‍🏫 Interviewer: The core element of SSL/TLS is asymmetric encryption. Can you briefly introduce it?

👨‍💻 Dabai: Asymmetric encryption uses two keys - a public key and a private key. During communication, the private key is only kept by the decryptor, and the public key is known to any sender (encryptor) who wants to communicate with the decryptor. You can imagine a scenario,

In a certain self-service post office, each communication channel is a mailbox, and each mailbox owner has a sign next to it with a key hanging on it: This is my public key. Please put the letter in my mailbox and lock it with the public key.

But the public key can only lock, not unlock. Unlocking can only be done by the owner of the mailbox - because only he keeps the private key.

In this way, the communication information cannot be intercepted by others, which relies on the confidentiality of the private key.

The public and private keys of asymmetric encryption need to be generated using a complex mathematical mechanism (cryptography believes that for higher security, it is best not to create your own encryption scheme). The algorithm for generating the public and private key pairs relies on a one-way trapdoor function.

One-way function: Given a one-way function f, it is easy to calculate the output y=f(x) given any input x; however, given an output y, assuming that f(x)=y exists, it is difficult to calculate x based on f.

One-way trapdoor function: A weak one-way function. Given a one-way trapdoor function f and a trapdoor h, it is easy to calculate the output y=f(x;h) given an arbitrary input x; and given an output y, assuming that there exists f(x;h)=y, it is difficult to calculate x based on f, but x can be derived based on f and h.

One-way function

The above picture is a one-way function (not a one-way trapdoor function). Suppose there is a secret book that anyone who knows it can squeeze apple juice into apples. Then this secret book is a "trapdoor".

Here, the calculation method of function f is equivalent to the public key, and the trapdoor h is equivalent to the private key. The public key f is public, and anyone can use f to encrypt existing input. However, in order to restore the original information based on the encrypted information, the private key is required.

Symmetric encryption

👨‍🏫 Interviewer: The two parties using SSL/TLS for communication need to use an asymmetric encryption scheme to communicate. However, asymmetric encryption designs relatively complex mathematical algorithms. In the actual communication process, the calculation cost is high and the efficiency is too low. Therefore, SSL/TLS actually uses symmetric encryption to encrypt messages.

👨‍🏫 Interviewer: Please briefly introduce symmetric encryption!

👨‍💻 Dabai: In symmetric encryption, the communicating parties share a unique key k. The encryption and decryption algorithms are known. The encrypting party uses key k to encrypt, and the decrypting party uses key k to decrypt. Confidentiality depends on the confidentiality of key k.

The cost of generating a symmetric encryption key is much lower than that of generating a public-private key pair. So some people may ask, why does SSL/TLS still need to use asymmetric encryption? Because the confidentiality of symmetric encryption depends entirely on the confidentiality of the key. Before the two parties communicate, they need to discuss a key for symmetric encryption. We know that the channel of network communication is insecure, and the transmission message is visible to anyone. The exchange of keys cannot be directly transmitted in the network channel. Therefore, asymmetric encryption is used to encrypt the symmetric encryption key to protect the key from being eavesdropped in the network channel. In this way, the communicating parties only need to perform asymmetric encryption once to exchange the symmetric encryption key. In the subsequent information communication, they use an absolutely secure key to symmetrically encrypt the information to ensure the confidentiality of the transmitted message.

Trustworthiness of public key transmission

👨‍🏫 Interviewer: Will this pose any safety risks?

👨‍💻 Dabai: Of course! Imagine the following scenario:

Client C and server S want to use SSL/TLS to communicate. According to the above SSL/TLS communication principle, C needs to know S's public key first, and the only way to obtain S's public key is to transmit S's public key in the network channel. It should be noted that there are several prerequisites for network channel communication:

Anyone can capture traffic packets

The confidentiality of the communication packets is designed by the sender

The design of confidentiality algorithms is public by default, and the (decryption) keys are secure by default.

Therefore, assuming that the public key of S is not encrypted and transmitted in the channel, there is a high possibility that there is an attacker A who sends a fraudulent packet to C, pretending to be the public key of S, but in fact it is the public key of the decoy server AS. When C obtains the public key of AS (but thinks it is the public key of S), C will subsequently use the public key of AS to encrypt the data and transmit it in the open channel. Then A will capture these encrypted packets and decrypt them with the private key of AS, thus intercepting the content that C was going to send to S, and C and S are completely unaware of it.

Similarly, even if S's public key is encrypted, it is difficult to avoid this trust problem. C is abducted by AS!

In order to solve the trust issue of public key transmission, a third-party organization came into being - Certificate Authority (CA). CA is a trusted third party by default. CA will issue certificates to each server. The certificates are stored on the server and are accompanied by the electronic signature of CA (see the next section).

When the client (browser) sends an HTTPS request to the server, it must first obtain the certificate of the target server and verify the legitimacy of the certificate based on the information on the certificate. Once the client detects that the certificate is illegal, an error will occur. After the client obtains the server's certificate, since the trustworthiness of the certificate is certified by a third-party trust agency and the certificate contains the server's public key information, the client can rest assured that the public key on the certificate is the public key of the target server.

Digital Signature

👨‍🏫 Interviewer: Digital signatures were mentioned above. Can you briefly introduce the problems that digital signatures solve?

👨‍💻 Dabai: The problem that digital signatures need to solve is to prevent certificates from being forged. The reason why third-party trusted institutions CA can be trusted is due to digital signature technology.

Digital signature is a combination of hashing and encryption technology used by CA to stamp a certificate when issuing it to the server, in order to provide a verification function. The specific behavior is as follows:

The CA knows the server's public key and generates a summary using hashing technology. The CA encrypts the summary using the CA private key, attaches it to the certificate, and sends it to the server.

Now the server sends the certificate to the client, and the client needs to verify the identity of the certificate. The client finds the third-party CA, obtains the CA's public key, and uses the CA's public key to decrypt the signature of the certificate and obtain the summary generated by the CA.

The client performs the same hashing process on the certificate data (that is, the server's public key) to obtain a digest, and compares the digest with the digest previously decoded from the signature. If they are the same, the identity authentication succeeds; otherwise, the verification fails.

Note that the certificate used to verify identity must be signed by the CA's public key, and cannot be signed by the sender himself. This is to resist the following attack scenarios:

The attacker uses some means to deceive the client and replace the server's public key with the attacker's bait public key.

If the certificate is signed with the server's private key, the client will use the fake server public key (actually a decoy public key) when decoding it. Then, if the certificate is actually issued by the attacker (signed with his own private key), the client will successfully verify the (attacker's) identity and thus trust the public key in the certificate.

If the CA's private key and public key are used to sign, the above problem will not occur.

In summary, the mechanism of transferring a public key with a certificate is as follows:

• Suppose there is a server S, a client C, and a third-party trusted authority CA.
• S trusts CA, and CA knows S's public key. S issues a certificate to CA and attaches the encrypted signature of the message digest using CA's private key.
• S obtains a certificate issued by CA and passes the certificate to C.
• C obtains S's certificate, trusts CA and knows CA's public key, uses CA's public key to decrypt the signature of S's certificate, and hashes the message to get a digest. Compare the digests to verify the authenticity of S's certificate.
• If C verifies that S's certificate is authentic, it trusts S's public key (in S's certificate).

4Differences between HTTP and HTTPS

👨‍🏫 Interviewer: Finally, let’s summarize the difference between HTTP and HTTPS!

👨‍💻 Dabai: To help distinguish the difference between HTTP and HTTPS, I have compiled a table: