Https is introduced

What is the Https

Hypertext Transfer Protocol Over Secure Socket Layer (HTTPS) is a Secure HTTP channel. In short, IT is the Secure version of HTTP. That is, add SSL layer to HTTP, and SECURE Sockets Layer (SSL) is the basis of HTTPS security. Therefore, SSL is required for details of encryption

The role of the Https

  • Content encryption establishes an information security channel to ensure the security of data transmission;
  • Authentication verifies the authenticity of a website
  • Data integrity Prevents content from being impersonated or tampered with by third parties

Https disadvantage

  • Encrypting and decrypting data makes it slower than HTTP

    Asymmetric encryption and decryption are required, and three handshakes are required. The first connection was a bit slower, but of course there are a lot of optimizations now.

For security reasons, browsers do not store the HTTPS cache locally. In fact, HTTPS can be cached as long as specific commands are used in the HTTP header. Firefox caches HTTPS only in memory by default. However, as long as the header command has cache-control: Public, the Cache is written to the hard disk. Internet Explorer can cache HTTPS content as long as HTTP headers allow. The cache policy is independent of whether HTTPS is used.

The difference between HTTPS and HTTP

  • For HTTPS, you need to apply for a certificate from the CA.
  • HTTP is hypertext transmission protocol, information is plaintext transmission; HTTPS is a secure SSL encrypted transport protocol.
  • HTTP and HTTPS use completely different connections and use different ports, the former 80 and the latter 443.
  • HTTP connections are simple and stateless; HTTPS is a network protocol that uses SSL and HTTP to encrypt transmission and authenticate identity. It is more secure than HTTP.

By default, HTTP uses port 80 and HTTPS uses port 443

The following is the entire ARCHITECTURE of HTTPS. Nowadays, MOST HTTPS uses TLS, so SSL should be changed to SSL/TLS.

Here is a general introduction to the knowledge points in the figure above.

Knowledge of encryption and decryption

Symmetric encryption

Symmetric encryption (also known as private key encryption) is an encryption algorithm that uses the same key for encryption and decryption. Sometimes called traditional cryptographic algorithm, the encryption key can be calculated from the decryption key, and the decryption key can also be calculated from the encryption key. In most symmetric algorithms, the encryption key and decryption key are the same, so this encryption algorithm is also called secret key algorithm or single key algorithm. Common symmetric Encryption modes include Data Encryption Standard (DES), Advanced Encryption Standard (AES), RC4, and IDEA

Asymmetric encryption

Different from symmetric encryption algorithms, asymmetric encryption algorithms require two keys: publickey and privatekey. And the encryption key and decryption key come in pairs. Asymmetric encryption algorithms use different keys for encryption and decryption. Asymmetric encryption is also called public key encryption. In a key pair, one key is public key, which is available to all, and one key is private key.

Asymmetric encryption algorithms have a limit on the length of the encrypted content, which cannot exceed the length of the public key. For example, the common public key length is 2048 bits, which means that the content to be encrypted cannot exceed 256 bytes.

The algorithm

Digital digest is to digest the plaintext to be encrypted into a string of fixed length (128 bits) using a single Hash function. This string of ciphertext is also called digital fingerprint. It has a fixed length. “Digital digest” is the fundamental reason HTTPS ensures data integrity and tamper-proof.

A digital signature

Digital signature technology is the application of “asymmetric key encryption and decryption” and “digital digest”, which encrypts the abstract information with the sender’s private key and transmits the original text to the receiver. The receiver can decrypt the encrypted digest only with the sender’s public key, and then use the HASH function to generate a digest of the received text and compare it with the decrypted digest. If they are the same, the received information is complete and has not been modified during transmission. Otherwise, the received information has been modified. Therefore, the digital signature can verify the integrity of the information. The process of digital signature is as follows: plaintext > Hash > Digest > private key encryption > digital signature

Digital signatures can be used in two ways: first, they can be sure that the message is actually signed and sent by the sender, since no one can impersonate the sender’s signature. Second, digital signature can determine the integrity of the message.

Note: A digital signature can only verify the integrity of data. Whether data is encrypted is not controlled by a digital signature

The digital certificate

Why a digital certificate?

How can the requester be sure that the public key it has obtained has been published from the target host and has not been tampered with? Or is the target host inherently guilty of stealing user information? In this case, an authoritative and trusted third-party organization (generally an organization audited and authorized by the government) is required to uniformly distribute the public key of the host organization. As long as the requesting organization obtains the public key, the above problems can be avoided.

Process of issuing digital certificates

The user first generates his own key pair, and transmits the public key and part of his personal identity information to the authentication center. Certification center after the identity verification, will perform the necessary steps to make sure the request is sent by the user, and then, the certification center will be sent to the user a digital certificate, the certificate is contained within the user’s personal information and his public key information, at the same time also with the signature of the certification center information (root certificate private key signature). Users can use their digital certificates for all kinds of related activities. Digital certificates are issued by independent certificate issuers. Digital certificates are different, and each certificate provides different levels of confidence.

What does a certificate contain

  • The name of the certificate authority
  • Digital signature of the certificate itself
  • Certificate Holder public Key
  • Hash algorithm used to sign the certificate

Verify the validity of the certificate

By default, all browsers have a built-in CA root certificate, which contains the PUBLIC key of the CA

  1. The certificate authority is forged: the browser does not recognize the certificate and considers it a dangerous certificate
  2. The certificate authority does exist. Locate the built-in CA root certificate and the CA public key based on the CA name. The CA public key is used to decrypt the summary of the forged certificate. If the certificate cannot be decrypted, it is considered as a dangerous certificate.
  3. For the tampered certificate, the CA’s public key is used to decrypt the digital signature to obtain the digest A, and then the digest B of the certificate is calculated based on the Hash algorithm of the signature. If A is equal to B, it is normal; if not, it is tampered.
  4. Certificates can be revoked before they expire, usually if the private key of the certificate has been compromised. Newer browsers such as Chrome, Firefox, Opera, and Internet Explorer have implemented the Online Certificate Status Protocol (OCSP) to eliminate this situation: the browser sends the serial number of the certificate provided by the site to the certificate authority via OCSP, which tells the browser whether the certificate is still valid.

1, 2 are for forged certificates, 3 is for tampered certificate verification, 4 is for expired validation.

The SSL and TLS

Secure Socket Layer (SSL)

SSL was developed by Netscape to secure data transmission over the Internet. Using Encryption technology, SSL ensures that data cannot be intercepted during transmission over the network. The current version is 3.0.

The SSL Protocol is divided into two layers: SSL Record Protocol (SSL Record Protocol) : Based on reliable transport protocols (such as TCP), it supports basic functions such as data encapsulation, compression, and encryption for high-level protocols. SSL Handshake Protocol: Based on the SSL recording Protocol, it is used for identity authentication, encryption algorithm negotiation, and encryption key exchange between communication parties before data transmission.

TLS (Transport Layer Security)

Used to provide confidentiality and data integrity between two applications. TLS 1.0 is a new protocol developed by the Internet Engineering Task Force (IETF). It is based on the SSL 3.0 protocol specification and is the subsequent version of SSL 3.0, which can be understood as SSL 3.1. It’s written to the RFC. This protocol consists of two layers: TLS Record and TLS Handshake. The lower layer is the TLS recording protocol, which sits on top of some reliable transport protocol, such as TCP.

SSL/TLS protocol functions:

  • Authenticate users and servers to ensure that data is sent to the correct clients and servers;
  • Encrypt data to prevent it from being stolen;
  • Maintain data integrity and ensure that data is not changed during transmission.

Advantages of TLS over SSL

  1. Use key hashing for message authentication: TLS uses key hashing for Message Authentication Code (HMAC), which ensures that records cannot be changed when they are transmitted over an open network such as the Internet. SSLv3.0 also provides keyed message authentication, but HMAC is more secure than the (message authentication code) MAC functionality used by SSLv3.0.
  2. Enhanced pseudo-random capability (PRF) : PRF generates key data. In TLS, HMAC defines PRF. PRF uses two hash algorithms to ensure its security. If either algorithm is exposed, the data remains safe as long as the second algorithm is not.
  3. Improved completed message validation: BOTH TLS and SSLv3.0 provide completed messages to both endpoints that authenticate the messages exchanged without being changed. However, TLS bases this completed message on PRF and HMAC values, which is also more secure than SSLv3.0.
  4. Consistent certificate handling: Unlike SSLv3.0, TLS attempts to specify the type of certificate that must be exchanged between TLS.
  5. Specific alert messages: TLS provides additional specific and additional alerts to indicate problems detected by either session endpoint. TLS also logs when certain alerts should be sent.

Handshake process of SSL and TLS

The entire SSL/TLS handshake process is shown in the following figure. Details of each step are described below:

The client makes the first request

Clients (such as browsers) support different encryption and decryption algorithms. However, the same encryption and decryption algorithm must be used during TLS protocol transmission to ensure normal encryption and decryption of data. During the TLS handshake phase, the client first informs the server of the encryption algorithms it supports. Therefore, the client needs to send the list of locally supported Cipher Suites to the server. In addition, the client also needs to generate a random number, which on the one hand needs to be saved in the client, and on the other hand needs to be transmitted to the server. The random number of the client needs to be combined with the random number generated by the server to generate Master Secret.

The client must provide the following information:

  • Supported protocol versions, such as TLS 1.0
  • A client-generated random number that is later used to generate the “conversation key”
  • Supported encryption methods, such as RSA public key encryption
  • Supported compression methods

First response from the server

After receiving Client Hello from the Client, the server needs to determine the version of the encryption protocol and the encryption algorithm, and then generate a random number and send its certificate to the Client. The random number here is the second random number in the whole process.

Information the server needs to provide:

The client responds again

The client first authenticates the certificate issued by the server. Once the certificate is authenticated, the client generates a random number (the third random number), encrypts it using the public key in the server certificate, and places a ChangeCipherSpec message that changes the encoding. And the hash value of all the previous messages, for server authentication, and then encrypt a piece of data with the new secret key and send it to the server to ensure that it is correct before formal communication. The client generates a Session Secret using the previous two random numbers and the newly generated new random number, using the encryption algorithm determined with the server.

ChangeCipherSpec ChangeCipherSpec is an independent protocol, which is a byte of data in a packet. It is used to inform the server that the client has switched to the previously negotiated Cipher Suite. Ready to encrypt data using the previously negotiated encryption suite and transmit.

The server responds again

After receiving the encrypted data of the third random number from the client, the server uses the private key to decrypt the encrypted data and verify the data. It also generates the secret key in the same way as the client. When everything is ready, it also sends a ChangeCipherSpec to the client. Tell the client that it has switched to the negotiated ciphersuite state and is ready to use ciphersuite and Session Secret to encrypt data. The server then uses Session Secret to encrypt a Finish message to the client to verify that the encryption and decryption channel established by the handshake was successful.

Follow-up Communication between the client and the server

Once the secret key is determined, messages are encrypted and communicated between the server and client using the agreed secret key. The whole handshake process is almost complete.

It is worth mentioning that SSL uses asymmetric encryption in the handshake phase and symmetric encryption in the transmission phase, which means that data transmitted over SSL is encrypted with symmetric keys! Asymmetric encryption is slow and resource-consuming. In fact, when the client and the host use asymmetric encryption to establish a connection, the client and the host have already decided the symmetric encryption algorithm and the key symmetric encryption key to be used in the transmission process. Because the process itself is safe and reliable, that is, the symmetric encryption key cannot be stolen. Therefore, It is safe and reliable to encrypt data symmetrically in the transmission process, because in addition to the client and host, there is no third party to steal and decrypt the symmetric encryption key! If someone eavesdrops on the communication, he can know the encryption method chosen by both parties, as well as two of the three random numbers. The security of the entire call depends only on whether the third random number (Premaster secret) can be decrypted.

Other supplementary

For very important confidential data, the server also needs to validate the client to ensure that the data is transmitted to a secure and legitimate client. The server can send a Cerficate Request message to the client to Request the client to send a certificate to verify the client’s validity. For example, financial institutions tend to allow only authenticated customers to connect to their networks, and will provide a USB key containing a client certificate to a regular customer.

PreMaster secret The first two bytes are TLS version numbers. This is an important version number for checking the handshake data, because during the Client Hello phase, the Client sends a list of encryption suites and currently supported SSL/TLS versions to the server, and it is sent in clear text. If the handshake packet is cracked, the attacker is likely to change the packet and select a less secure encryption suite and version to the server to crack the data. Therefore, the server needs to compare the version number of the PreMaster decrypted pair in the ciphertext with the version number of the previous Client Hello phase. If the version number becomes lower, it indicates that the PreMaster version is changed in a string and stops sending any messages immediately.

The recovery of the session

There are two ways to restore the original session: one is called session ID and the other is called Session ticket.

session ID

The idea of a session ID is simple: Each session has a session ID. If the conversation is interrupted, the next time the client gives this number and the server has a record of this number, both parties can reuse the existing “conversation key” instead of generating a new one.

Session ID is currently supported by all browsers, but it has the disadvantage that session IDS tend to be reserved for only one server. So, if a client request goes to another server, the conversation cannot be resumed

session ticket

The client sends a session ticket sent by the server during the previous session. The session ticket is encrypted and can only be decrypted by the server. It contains the main information about the session, such as the session key and encryption method. After the server receives a session ticket, it does not need to regenerate the session key after decryption.

It is currently only supported by Firefox and Chrome.

conclusion

HTTPS actually adds SSL/TLS between the TCP and HTTP layers to ensure upper-layer security. It mainly uses technologies such as symmetric encryption, asymmetric encryption, and certificates to encrypt data between the client and server, ensuring the security of the entire communication.

OpenSSL and SSL digital Certificates are based on OpenSSL’s self-built CA and issued SSL certificates The SSL/TLS protocol allows you to exploit the OSI model, TLS/SSL, and HTTPS OpenSSL HeartBleed vulnerabilities