All about HTTPS SSL Encryption

Analysis of HTTPS SSL Encryption

SSL (Secure Socket Layer): Netscape company is designed for WEB security transmission protocol. From the name you can see it in the https protocol stack is responsible for the above-mentioned encryption layer.

Article Content

• HTTPS SSL certificate
• HTTPS work process
• One-way encryption
  • Nginx configuration unidirectional encryption
  • Browser certificate import
• Bidirectional encryption
  • Nginx configuration bidirectional authentication
  • Two-way authentication process
• Fileserver SSL
  • Nginx configuration
  • Server certificate
  • Client certificate

HTTPS SSL certificate

SSL (Secure Socket Layer) : Netscape company is designed for WEB security transmission protocol. From the name you can see it in the https protocol stack is responsible for the above-mentioned encryption layer. So, an https protocol stack is roughly like this, as shown in Figure 1:

SSL structure

Digital certificate : the name of a document, such as a body or person’s signature, to prove the authenticity of this institution or person. Which contains the information used to achieve the above functions.

Encryption and authentication : encryption means that both sides of the communication in order to prevent sensitive information in the channel by a third party eavesdropping and leakage, the plaintext through the encryption into a ciphertext, if the third party can not be decrypted, even if he received ciphertext can not do anything; The parties to the communication in order to confirm each other is a trusted message to send or accept the party, rather than the use of false identity of the illegal, to confirm the identity of the way. Only in the same time encryption and authentication to ensure the safety of communication, so in the SSL communication protocol, both of which should be. Early are generally symmetric encryption algorithm, and now are generally asymmetric encryption, the most common algorithm is RSA.

Message Summary: This technology is mainly to avoid the news was tampered with. The message digest is a piece of information, through a certain algorithm, to draw a string of strings. This string is a summary of the message. If the message is tampered with (changed), then the summary will change (if two different messages are generated the same, then this is called a collision). Message digest algorithm mainly MD5 and SHA, in the field of certification, are generally used SHA (security hash algorithm).

Digital certificate, encryption and authentication, message digest three technologies together, that is, widely used in HTTPS certificate (certificate), the certificate itself contains encrypted / decrypted information, and can identify their own identity, but also comes with a message digest.

HTTPS work process

1. The browser sends a connection request to the secure server
2. The server sends its own certificate, along with the certificate-related information, to the client’s browser
3. The client’s browser checks whether the certificate sent by the server is issued by the CA Center that it trusts. If so, to continue the implementation of the agreement; if not, the client browser gives the customer a warning message: warned the customer this certificate is not trustworthy, ask the customer whether to continue
4. Then the client browser compares the messages in the certificate, such as the domain name and the public key, and the server has just sent the relevant message is consistent, if it is consistent, the client browser recognized the legitimate identity of the server
5. The server asks the customer to send the customer’s own certificate. Upon receipt, the server verifies the customer’s certificate, if not verified, refused to connect; if verified, the server access to the user’s public key
6. The client browser tells the server that it can support the communication symmetric password scheme
7. Server from the customer sent over the password scheme, select a password level of the highest password program, with the client’s public key and then notify the browser
8. Browser for this password scheme, select a call key, and then use the server’s public key and then sent to the server
9. The server receives the message from the browser, decrypts it with its own private key, obtains the call key
10. Server, browser, the next communication is a symmetric password scheme, symmetric key is added too close

The above is a two-way authentication SSL protocol specific communication process, this situation requires both the server and the user have a certificate. One-way authentication SSL protocol does not require customers to have CA certificate, the specific process relative to the above steps, only the server side to verify the process of customer certificate removed, and in the negotiation of symmetric password scheme, symmetric call key, the server sent to the customer Is not added too close (this does not affect the SSL process security) password scheme.

In this way, the specific content of the two sides is to add too much data, if there is a third party attack, access to only encrypted data, third parties to get useful information, you need to decrypt the encrypted data, this time on the security Depends on the security of the cryptographic scheme. And fortunately, the current use of the password scheme, as long as the communication key length is long enough, is enough security. This is why we stress the need to use 128-bit encrypted communication.

One-way encryption

One-way authentication is mainly used to authenticate the information that the site visited is safe and reliable. Generally, the certificate of this website is issued by the authoritative third party.

Nginx configuration unidirectional encryption

Nginx default use 443 port to do SSL encryption, configuration shown in Figure 2:

Nginx configuration unidirectional encryption

Configuring and using one-way encryption requires:

1. Certificate : Use the root certificate of the authority to issue
2. Private key : own private key, used to decrypt the content sent by the user

Browser certificate import

If you are using a certificate issued by an authority, you do not need to manually import the certificate into the browser’s certificate. If you want to use a certificate issued by yourself, you need to:

1. Generate the root certificate: the certificate is equivalent to the authority of the issuing certificate, the certificate generally contains the agency information
2. Use the root certificate to issue your own website certificate: the certificate is used to send to the user
3. The client imports the root certificate to the trusted root certificate authority

The browser access process is as follows:

1. Send the request to the server
2. The server sends the site’s certificate
3. Browser calibration certificate found in the certificate of the site is a trusted certification authority , the certification by
4. Negotiation key communication

Bidirectional encryption

Work encountered a troublesome problem involving fileserver two-way encryption, resulting in a consequence is not using the browser debugging, if you want to debug the api above the browser, you need to import the certificate.

Two-way authentication is only one-way authentication on the basis of the client with the certification, one-way authentication is the essence of the test server side of the reliability, we all think that Alipay is safe, but any phishing sites can forge Alipay website, how Can we think that we visit the official website? The client needs to authenticate the web service provider at this time to make sure it is not forged.

And two-way authentication is based on the client to verify, such as some very important services need to use internal or small partners to use, through the API to provide these services, then only trusted customers can get the data.

Nginx configuration bidirectional authentication

Two-way authentication nginx configuration as shown in Figure 3:

Nginx bidirectional authentication configuration

In addition to configuring the server’s certificate, we see that the fileserver is configured with a client certificate that is used to issue the root certificate of the client certificate. In principle, the certificate should be generated by the service provider itself, rather than by other public agencies , The service provider to generate this certificate, used to issue a certificate to pay customers, customers get the certificate before they can use the appropriate service, the configuration completed the need to open ssl_verify_client switch to verify the identity of customers.

Two-way authentication process

Two-way authentication is the server and the client through mutual authentication each other’s certificate to ensure that the other’s credible, the certification process as shown in Figure 4:

SSL bidirectional authentication process

The premise of two-way authentication is to get the other side of the root certificate, that is, issue a certificate, and then use the certificate issued to verify the other party’s certificate is credible.

Fileserver SSL

Fileserver use two-way SSL encryption, the root certificate is generated by their own, the client’s root certificate is generated by their own, in which case, the client and the service root certificate can be the same, so more convenient.

From Figure 3 we see that the server sends the client certificate is server.cert, the server’s private key stored in the server.pkey, the client’s root certificate is CA.cert, the client’s certificate must be by this CA.cert Certificate issued.

Nginx configuration

As shown in Figure 3.

Server certificate

Server-side certificate is server.cert, in the fileserver_v2 svn there is a key directory, which saved the client side of the client’s certificate information, we can package the server’s root certificate server / CA.cert into their own browser’s trusted In the root certificate , to verify the server’s certificate.

Client certificate

Client certificate stored in the key /device/ directory below, we need to configure the client’s root certificate in nginx, used to verify the credibility of the customer, we also need to import the browser above the user’s personal certificate /device/device .cert, when we send the request to the server, we carry the certificate, so that the server to verify our identity.

Here because the fileserver key directory below the user’s personal certificate in the password, so when the importation of personal certificates is not allowed to pass, and the password we do not know, but also can be used, we can use the client’s root certificate issued a New certificate, so the password is dispensable, we still can through the server side of the verification.