What’s wrong with HTTP communication

1. Possible wiretapping

  • HTTP does not provide encryption. HTTP packets are sent in plain text
  • Because the Internet is made up of network facilities that connect all parts of the world, all data sent and received through some device can be intercepted or accessed. (For example, Wireshark, a well-known packet capture tool, is used to capture packets.) Even if the packets are encrypted, the packets can be detected. However, it is difficult or impossible to crack the packets

2. Certification issues

  • Unable to confirm that the server you are sending to is the real target server (probably disguised)
  • It is not possible to determine whether the client returned is the one received with true intent (possibly a disguised client)
  • You cannot determine whether the other party you are communicating with has access permission. Some important information on the Web server is sent only to specific users
  • Even meaningless requests will be accepted. Denial of Service (DoS) attacks on massive requests cannot be prevented.

3. It may be tampered with

A man-in-the-middle attack (MITM) in which an attacker intercepts and modifies a request or response in transit.

How does HTTPS solve the above three problems

HTTPS replaces the Transport Layer Security (TLS) protocol in the communication interface.

SSL and TLS:

Transport Layer Security (TLS), and its predecessor, Secure Sockets Layer (SSL), is a Security protocol designed to provide Security and data integrity for Internet communications. When Netscape introduced the first version of its web browser, Netscape Navigator, in 1994, it introduced the HTTPS protocol, which uses SSL for encryption, which is the origin of SSL. IETF standardized SSL and published the first version of TLS standard document in 1999. This was followed by RFC 5246 (August 2008) and RFC 6176 (March 2011). This is referred to as SSL

TLS is the standard for SSL. HTTPSisHTTP + SSL

The SSL protocol

The implementation of SSL protocol needs to use several kinds of algorithms

Symmetric encryption

Commonly used encryption algorithms:DES,AES ,RC2.RC4

Advantages: open algorithm, small amount of calculation, fast encryption speed, high encryption efficiency.

Disadvantages: Both sides of the transaction use the same key, security can not be guaranteed.

Asymmetric encryption

Common asymmetric encryption algorithms :RSA,DSA, and Diffie-Hellman Advantages: High security Disadvantages: low speed

Integrity verification algorithm

The HASH algorithm:MD5.SHA1.SHA256

Used to verify message integrity

SSL Protocol Structure

  1. The first layer is the Record Protocol, which defines the transport format.
  2. Layer 2 Handshake Protocol, which is based on SSL recording Protocol, is used for identity authentication, encryption algorithm negotiation, encryption key exchange, and so on before data transmission.

Working Mode:

  • The client communicates with the server using asymmetric encryption, authenticates and negotiates the keys used for symmetric encryption,
  • Then, the negotiated key is used to encrypt the information. Different nodes use different symmetric keys to ensure the security of symmetric keys.

The process of SSL key negotiation is as follows

Click for a larger version



source

Describe the process in detail, mainly divided into four steps (slightly complicated here, can be skipped if you don’t pay attention to details):

1. Client_hello process

The client initiates a request and transmits the request information in plaintext, including the version information, encryption suite candidate list, compression algorithm candidate list, random number, and extended fields. The related information is as follows:

  • Version: Indicates the highest TSL version, in descending order. SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2. The version later than TLSv1 is not used
  • Cipher Suite: Au (authentication), KeyExchange(key negotiation), Enc (information encryption), and Mac(integrity check).
  • Compression algorithm candidate list: a list of supported compression methods for subsequent information compression and transmission.
  • Random number: The random number is the RNc in the figure above, which is used to generate the negotiation key.
  • Negotiation data: supports parameters related to protocols and algorithms and other auxiliary information. Common SNI is an extended field. The functions of this field will be discussed separately in the future.
2. Server_hello process
  • The server returns the negotiation result, including the selected protocol version, the selected cipher Suite, the selected compression method, and the random number RNs. The random number is used for subsequent key negotiation.
  • Server certificate chain used for identity verification and key exchange
  • Notifies the client of the end of server-hello and requests the certificate and key of the client
3. Verify the certificate and negotiate the final communication key

A. The client verifies the validity of the server certificate. If the authentication succeeds, the client communicates with the server. Otherwise, the client prompts and performs operations based on the error situation.

  • Certificate chain Trusted Certificate Path
  • Whether the certificate is revocation
  • Whether the certificate is valid;
  • Domain name domain, check whether the certificate domain name matches the current access domain name, and analyze the matching rules later;

B. The client sends the client certificate and authenticates the public key server (the process is the same as the client authentication) c. The client hash all previous messages, sends hash values and abstracts, encrypts them with the client’s private key, and sends them to the server. The server decrypts them with the client’s public key, and verifies that the server obtains the client’s public key and algorithm correctly. D. The client generates the PMS, encrypts it with the public key of the server, and sends the PMS to the server. E. The client and server simultaneously calculate the final session key (MS)

4. Verify the negotiation key

A. Client sends a ChangeCipherSpec, which instructs the Server to send encrypted messages from now on. B. Client sends a Finishd, which contains the hash of all previous handshake messages, allowing the Server to verify whether the handshake process has been tampered with by a third party. The Server sends a ChangeCipherSpec, which instructs the Client to send encrypted messages from now on. D. The Server sends a Finishd, which contains the hash of all previous handshake messages, allowing the Client to verify that the handshake process has been tampered with by a third party. And prove that you are the owner of the Certificate key, that is, prove your identity

HTTPS complete connection establishment process is shown in the following figure

  1. The TCP handshake connection is established first
  2. Perform SSL Handshake Protocol exchange
  3. Communication then begins with a mutually agreed key

What is this certificate

What the certificate does is, I’m talking to the server, how do I know that this is the server that I’m actually talking to. An unfortunate analogy:

You are a treasure to shopping, to the checkout page, you consumed 1 million, enter payment card account number and password, but when you after the payment, you find account 1 million less, but not payment account page or display, are you going to play a treasure customer service, customer service said you were handing over 1 million others didn’t pay to me some treasure, note: there are two possibilities

  1. One is the possibility of a man-in-the-middle attack (user names and passwords intercepted by hackers)
  2. Some treasure took your money and pretended to deny it.

The procedure for applying for and issuing certificates is as follows:

  1. The Server submits the public key, organization information, and personal information (domain name) to the third-party CA and applies for authentication.

  2. CA verifies the authenticity of the information provided by the applicant through various online and offline means, such as whether the organization exists, whether the enterprise is legal, whether it has the ownership of the domain name, etc.

  3. If the information is approved, CA will issue a certificate to the applicant. The certificate contains the following information: the public key of the applicant, the organization information and personal information of the applicant, the information about the issuing authority (CA), the validity time, and the serial number of the certificate, and contains a signature. The algorithm of signature generation is as follows: first, hash function is used to calculate the summary of the plaintext information, then CA’s private key is used to encrypt the summary, ciphertext is signature;

  4. When the Client sends a request to the Server, the Server returns a certificate file.

  5. The Client reads the plaintext information in the certificate and uses the same hash function to calculate the summary of the information. Then, the Client decrypts the signature data using the public key of the CORRESPONDING CA and compares the summary of the information with that of the certificate. If the summary of the information is the same, the certificate is valid.

  6. The client also verifies the domain name and validity period of the certificate. The client has the certificate information (including the public key) of the trusted CA built in. If the CA is not trusted, the corresponding CA certificate cannot be found and the certificate is judged to be invalid.

The certificate chain

  1. Server certificate Server. pem is issued by inter, an intermediate certificate authority. Inter verifies that server.pem is a valid certificate for itself according to the certificate Inter
  2. The CA for issuing the inter. Pem intermediate certificate is root. Root verifies the valid certificate issued by inter.
  3. The client trusts the CA root. Pem certificate, so the server certificate server.pem is trusted.

The server certificate, intermediate certificate and root certificate are combined to form a legitimate certificate chain. The verification of the certificate chain is a process of bottom-up trust transfer.

For details about certificates, learn about the PKI system

The resources