Big front-end encyclopedia, front-end encyclopedia, record the front-end related field knowledge, convenient follow-up access and interview preparation

keywords
  • certificate
  • CA
  • SSL/TLS
  • Algorithm/symmetric encryption/asymmetric encryption
  • HTTPS handshake process, how to establish a secure channel, HTTPS encryption process?
  • How to deal with HTTPS of 301 and 302 being hijacked?
  • How do I recover an SSL connection?
  • What do you understand about HTTPS man-in-the-middle attacks?

The risks of traditional HTTP

HTTP communication without SSL/TLS is unencrypted communication. With all information in plain text, there are three main risks.

(1) Eavesdropping: The contents of communications may be known to a third party.

(2) Tampering risks: Third parties may modify communications.

(3) Impersonation risk (pretending) : a third party may impersonate the identity of others to participate in communication.

The SSL/TLS protocol is designed to address these three risks, hoping to achieve:

(1) All information is encrypted and cannot be wiretapped by a third party.

(2) With verification mechanism, once tampered, communication parties will immediately discover.

(3) Equipped with identity certificate to prevent identity from being impersonated.

The Internet is an open environment, and the communication parties are unknown, which brings great difficulty to the design of the protocol. Also, the protocol must be able to withstand all sorts of mind-boggling attacks, which makes SSL/TLS extremely complex.

Algorithm, symmetric encryption, asymmetric encryption

The algorithm

  • The common ones are MD5, SHA1, and SHA256. This type of function is characterized by one-way irreversible function, very sensitive to input, and fixed output length. Any modification of data will change the result of the hash function to prevent information tampering and verify the integrity of data.
  • In the process of information transmission, the hash function cannot independently achieve information tamper-proof, because in plaintext transmission, the middleman can modify the information and recalculate the information summary, so the transmitted information and the information summary need to be encrypted.

Symmetric encryption

  • Common encryption keys include AES-CBC, DES, 3DES, and AES-GCM. The same key can be used to encrypt and decrypt information. Information can be obtained only after the key is mastered, preventing information eavesdropping.
  • Symmetric encryption requires the same password to be shared. Password security is the basis for ensuring information security. When a server communicates with multiple clients, multiple password records need to be maintained, and there is no mechanism for changing passwords.
  • 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

  • The common RSA algorithm, including ECC and DH algorithms, is characterized by a pair of keys, commonly called public key (public) and private key (private). The information encrypted by the public key can be unencrypted only by the private key, and the information encrypted by the private key can be unencrypted only by the public key. Therefore, clients with public keys cannot decrypt information with each other, but can only communicate with the server with the private key. The server can communicate with one to many, and the client can also be used to verify the identity of the server with the private key.
  • Asymmetric encryption is characterized by one-to-many information transmission. The server only needs to maintain a private key to encrypt communication with multiple clients, but the information sent by the server can be decrypted by all clients. In addition, the algorithm has complex calculation and slow encryption speed.

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

Process for applying for and issuing certificates

  • The Server submits the public key, organization information, and personal information (domain name) to the third-party CA and applies for authentication.
  • 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.
  • If the information is approved, CA will issue a certification document to the applicantcertificate. 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. Signature generation algorithm:Firstly, hash function is used to calculate the summary of the public plaintext information. Then, CA's private key is used to encrypt the summary, ciphertext is signature.
  • When the Client sends a request to the Server, the Server returns a certificate file.
  • 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.
  • 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

  • Server certificateserver.pemIssued by inter intermediate certificate authority, inter according to the certificateinter.pemVerify that server.pem really issued a valid certificate for itself
  • The intermediate certificate inter. Pem is issued by the CA root, which is based on the certificateroot.pemVerify the valid certificate issued by Inter. Pem;
  • 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.

HTTPS handshake process, how to establish a secure channel, HTTPS encryption process?

SSL/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. HTTPS is HTTP + SSL

The HTTPS protocol basically relies on TLS/SSL, and TLS/SSL relies on three basic algorithms: Hash function, symmetric encryption and asymmetric encryption, which uses asymmetric encryption to realize identity authentication and key negotiation, symmetric encryption algorithm uses the negotiated key to encrypt data, based on the hash function to verify the integrity of information.

HTTPS Establishes a secure channel, encrypts HTTPS, and obtains the encryption key. Secure channels are established when HTTPS uses the symmetric key to send packets

  • The client initiates an HTTPS(for example, www.baidu.com/) request until it needs to connect to port 443(default) of the Server according to RFC2818
  • The Server returns the pre-configured public key certificate to the client
  • Client authenticates the public key certificate: For example, whether the certificate is within the validity period, whether the certificate is used to match the site requested by the Client, whether the certificate is in the CRL revocation list, and whether its upper certificate is valid is a recursive process until the Root certificate (the Root certificate built into the operating system or the Root certificate built into the Client) is verified. If the verification passes, continue; if the verification fails, a warning message is displayed
  • The Client uses the pseudo-random number generator to generate a symmetric key for encryption, encrypts the symmetric key with the public key of the certificate, and sends the symmetric key to the Server
  • The Server decrypts the message using its own private key to get the symmetric key. At this point, both the Client and Server have the same symmetric key
  • The Server encrypts’ plaintext A’ using the symmetric key and sends it to the Client
  • The Client decrypts the ciphertext of the response using the symmetric key to get ‘plaintext A’.
  • The Client initiates an HTTPS request again, encrypts the plaintext B using the symmetric key, and the Server decrypts the ciphertext using the symmetric key to obtain the plaintext B.

How to deal with HTTPS of 301 and 302 being hijacked?

Use HSTS wisely

What are HSTS? HTTP Strict Transport Security (HSTS) indicates that a website has implemented TLS, requiring the browser to rewrite the plaintext URL to HTTPS, avoiding the delay cost of forcing 302 redirects all the time.

Implementation principle of HSTS

When the browser makes its first HTTP request to the server, it adds Strict- transport-security to the response header that tells the browser that the site must be accessed through HTTPS for a specified period of time. That is, for the HTTP address of the site, the browser needs to now replace it with HTTPS locally before sending the request.

How do I recover an SSL connection?

You can use the session ID or session ticket to restore the disconnected SSL connection.

  • In the form of session ID, each session has a number. When the conversation is interrupted and the next time the connection is reconnected, as long as the client gives this number and the server has the record of this number, the two parties can continue to use the previous key without generating a new one.

    • All browsers currently support this approach.
    • One drawback of this approach is that the session ID can only be stored on one server if our request passesLoad balancingIt was moved to another server, and the conversation could not be resumed.

  • Session ticket is sent by the server to the client in the last session. The session ticket is encrypted and can only be decrypted by the server. The ticket contains the session information, such as the key and encryption method.

    • In this way, regardless of whether our request is transferred to another server, when the server decrypts the ticket, it will be able to retrieve the information of the last conversation without regenerating the conversation secret key

What do you understand about HTTPS man-in-the-middle attacks?

https

You’ve probably heard that THE HTTPS protocol is secure because it encrypts the transmitted data using asymmetric encryption. However, IN fact, HTTPS uses symmetric encryption for content transmission. Asymmetric encryption only applies to certificate verification.

The HTTPS process consists of certificate authentication and data transmission. The interaction process is as follows:

① Certificate verification phase

  1. The browser initiates an HTTPS request

  2. Server returns HTTPS certificate (including public key)

  3. The client verifies whether the certificate is valid. If the certificate is invalid, an alarm is generated

② Data transmission stage

  1. When the certificate is valid, a random number is generated locally

  2. The public key encrypts the random number and transmits the encrypted random number to the server

  3. The server decrypts random numbers using private keys

  4. The server uses the random number from the client to construct a symmetric encryption algorithm, encrypts the returned result and transmits it

Why is data transmitted symmetrically encrypted?

First of all, the efficiency of asymmetric encryption is very low, and there is usually a lot of end-to-end interaction in HTTP application scenarios, so the efficiency of asymmetric encryption is unacceptable.

In the HTTPS scenario, only the server saves the private key, and a pair of public and private keys can only realize one-way encryption and decryption. Therefore, the content transmission encryption in HTTPS adopts symmetric encryption instead of asymmetric encryption.

Why do I need a CA to issue a certificate?

HTTP is considered insecure because the transmission process is easy to be tapped by listeners and forged servers, while HTTPS mainly solves the security problem of network transmission.

First, we assume that there is no certification authority and that anyone can create a certificate, which presents a security risk known as the classic “man-in-the-middle” problem.

Process principle:

  1. Local requests are hijacked (e.g., DNS hijacking) and all requests are sent to the middleman’s server

  2. The middleman server returns the middleman’s own certificate

  3. The client creates a random number, encrypts the random number using the public key of the middleman certificate, and sends the random number to the middleman. Symmetric encryption is constructed based on the random number to encrypt and transmit the transmitted content

  4. Because the middleman has the random number of the client, it can decrypt the content through the symmetric encryption algorithm

  5. The middleman sends a request to the official website with the content requested by the client

  6. Because the process of communication between the middleman and the server is legal, the legitimate website returns encrypted data through a secure channel established

  7. Middlemen decrypt content using symmetric encryption algorithms established with legitimate websites

  8. The middleman encrypts and transmits the data returned by the regular content through the symmetric encryption algorithm established with the client

  9. The client decrypts the returned result data through a symmetric encryption algorithm established with the middleman

Due to the lack of certificate verification, although the client initiates an HTTPS request, the client is completely unaware that its network has been intercepted and the transmitted content is stolen by a middleman.

How does the browser ensure that the CA certificate is valid?

  1. What information does the certificate contain?
  • Information of issuing Authority
  • The public key
  • Your company information
  • The domain name
  • The period of validity
  • The fingerprint
  • .
  1. What is the validity of the certificate?

Above all, authoritative orgnaization should have attestation, not just an orgnaization is qualified to issue a certificate, otherwise also not be called authoritative orgnaization.

In addition, the credibility of the certificate is based on the trust system, and the authority needs to endorse the certificate issued by the authority. As long as the certificate generated by the authority, we consider it legitimate. Therefore, the authority will review the information of the applicant, and the requirements of the authority of different levels are not the same, so the certificate is also divided into free, cheap and expensive.

  1. How does the browser verify the validity of the certificate?

When the browser initiates an HTTPS request, the server returns the website’s SSL certificate. The browser needs to verify the certificate as follows:

  1. Verify that the domain name and validity period are correct. All certificates contain these information, which is easier to complete verification;
  2. Determine whether the certificate source is valid. Each issued certificate can be found according to the verification chainRoot certificate, the operating system (OS) and browser store the root certificate of the local authority. The local root certificate can be used to authenticate the source of the certificate issued by the corresponding authority.

  1. Determine whether the certificate has been tampered with. Verification with the CA server is required.

  2. Determine whether the certificate has been revoked. Through Certificate Revocation List (CRL) and Online Certificate Status Protocol (OCSP), OCSP can be used in step 3 to reduce interaction with the CA server and improve verification efficiency

The browser considers the certificate valid only if any of the preceding steps are met.

Here’s a question I’ve been thinking about for a long time with a simple answer:

  • Since the certificate is public, if I want to launch a man-in-the-middle attack, I download a certificate from the official website as my server certificate, and the client will definitely agree that the certificate is legitimate. How can I avoid the situation of fake certificate?

In fact, this is the use of public and private keys in unencrypted symmetry. Although the middleman can get the certificate, the private key cannot be obtained. It is impossible to calculate the corresponding private key of a public key.

  1. Can only certification authorities generate certificates?

If you want the browser to avoid security risks, you can only use the certificate issued by the certification authority. However, browsers usually just warn of security risks and do not restrict access to websites, so technically anyone can generate a certificate that can complete HTTPS transfer of a website. For example, early 12306 uses the form of manually installing private certificates to implement HTTPS access.

What if local random numbers are stolen?

Asymmetric encryption is used for certificate authentication, but symmetric encryption is used for transmission. Important random numbers in the symmetric encryption algorithm are generated and stored locally. How does HTTPS prevent random numbers from being stolen?

In fact, HTTPS does not guarantee the security of random numbers. HTTPS only guarantees the security of transmission, and random numbers are stored locally. Local security belongs to another security category.

Can I get caught using HTTPS?

HTTPS data is encrypted. Generally, packets captured by the packet capture tool are in the encrypted state and cannot be viewed.

HTTPS only prevents communication from being monitored without the user’s knowledge. If the user initiates the communication, a “man in the middle” network can be constructed, and proxy software can decrypt the content of the transmission.

Methods to prevent

After the server adds a CA certificate to the public key of the browser, the browser can verify the validity of the CA certificate. (Existing HTTPS is hard to hijack unless the hijacker’s CA certificate is trusted).