preface

Before we get to HTTPS, let’s review the HTTP protocol. HTTP is a hypertext transfer protocol, it is stateless, simple and fast, based on TCP reliable transfer protocol.

If HTTP is such a good protocol, why is HTTPS popping up? This is mainly because HTTP is transmitted in plaintext, which poses a significant security risk. When packets are hijacked on the Internet, you are exposed to others naked, with no privacy at all. Imagine if you were connected to an untrusted WIFI and used a payment software to make a payment, your password could end up in someone else’s hands.

Such is the network environment, bring you convenience at the same time, also full of challenges and risks. For white users, you can not expect him to have a high awareness of network security, the product should be more secure through technical means, to control the risk from the source. This gave birth to the HTTPS protocol.

HTTPS

Simply put, HTTP is a security risk because of plaintext transmission. That eliminates the risk by encrypting data transmission.

From the seven-layer model of the network, the original four-layer TCP to seven-layer HTTP is plaintext transmission, between which a transport layer responsible for data encryption and decryption (SSL/TLS), to ensure that in the process of network transmission data is encrypted, and HTTP received is still plaintext data, there is no impact.

[image upload failed…(image-1f4AD-1513224051213)]

SSL was developed by Netscape specifically for user protection of Web communications, currently version 3.0. The latest version of TLS 1.0 is a new protocol developed by IETF(Engineering Task Force), which is based on the SSL 3.0 protocol specification and is the subsequent version of SSL 3.0. The difference is minimal and can be understood as SSL 3.1, which is written to the RFC.

advantage

This section referenceRuan yifeng SSL/TLS protocol operation mechanism overview.

Before looking at the implementation details, let’s take a look at HTTP’s specific security risks and HTTPS’s solution.

Three major risks of HTTP:

  1. Eavesdropping: A third party may learn the contents of communications.
  2. Tampering risks: Third parties may modify communications.
  3. Impersonation risk (pretending) : Third parties can impersonate others to participate in communications.

HTTPS Solution

  1. All messages are encrypted, so third parties can’t eavesdrop.
  2. With a verification mechanism, once tampered, communication parties will immediately discover.
  3. Equipped with an identity certificate to prevent false identity.

implementation

Based on the above introduction, you have a general understanding of HTTPS. How does HTTPS encrypt data? I’m not going to give you a complicated algorithm here, but I’m going to give you my understanding in the most general terms.

First of all, to understand the encryption algorithm, there are two commonly used: symmetric encryption and asymmetric encryption.

  • Symmetric encryption: The communication parties use the same key to encrypt and decrypt information. Encryption and decryption speed is fast, but the security is poor, if one party discloses the key, the encryption process will be broken.

  • Asymmetric encryption: Compared to symmetric encryption, it generally has public and private keys. The public key encrypts information and the private key decrypts information. The two keys are kept by the sender and sender respectively. The encryption and decryption process requires the two keys together. Higher security, but at the same time much more computation than symmetric encryption.

For the network communication process, under the premise of security, it is necessary to ensure the response speed. How to perform asymmetric computation every time is bound to affect the communication process. As a result, the hope for secure transmission must ultimately be symmetric encryption. As shown in figure:

[image upload failed…(image-4364d7-1513224051213)]

First, how is the Session Key obtained, and all transfers prior to the Session Key are in clear text. Session keys cannot be securely transmitted over the network, so they must be encrypted separately. Therefore, before this, both sides should communicate with each other, confirm the encryption algorithm, and add random numbers to improve security. As shown in figure:

[image upload failed…(image-1655F-1513224051213)]

In this way, both parties confirm the SSL/TLS version used and the encryption algorithm used to generate the Session Key. And both sides have two random numbers (the client and the server generate one respectively). However, if the Session Key is generated according to the current random parameters and encryption algorithm, there are still risks. The encryption algorithm is limited and fixed, and random numbers are transmitted in plaintext, which may be intercepted.

Making encryption algorithms unpredictable is unlikely. Then can we transmit an encrypted random number, which, even if intercepted, cannot be deciphered? This uses an asymmetric encryption algorithm, and we transfer the public key to the client in step two. In this way, the third random number of the client is encrypted with the public key, and only the server with the private key can decipher the third parameter. Thus, the generated Session is secure. As shown in figure:

[Image upload failed…(image-eaf419-1513224051213)]

It wasn’t easy. Looks like it’s done. Session keys generated are now unpredictable (even if they are intercepted) and we can safely communicate privately. Is it really so? We seem to trust the public key given by the server. If your current communication itself is not trusted, or hijacked by a middleman, who sends you a forged public key, the consequences can be imagined. This is the legendary “man-in-the-middle attack”.

So, we have to wrap the public key to make it secure. This leads to the concept of digital certificates, which are issued by a trusted certificate authority and contain a certificate file and a certificate private key file. The private key file is saved by the server, and the certificate file, which contains the domain name information, public key, and corresponding verification code, is sent to the requesting client. The customer can check whether the certificate is trusted according to the obtained certificate file. As shown in figure:

[image upload failed…(image-abda42-1513224051213)]

The following calculation simply describes the whole communication process. First, after the TCP three-way handshake, the asymmetric algorithm encryption (certificate verification) is carried out, and the obtained parameters are encrypted to generate the Session Key required by the Session. In the subsequent data transmission, the symmetric password is transmitted through the Session Key. Session information is completed over a private channel.

Of course, the actual process is much more complicated than this, including complex algorithms and details, if you are interested, you can refer to the relevant materials for understanding.

certificate

With regard to digital certificates, here is a brief introduction to some types of certificates:

Classified by level of verification

  • Domain Validation (DV) : the most basic authentication method that only ensures that the Domain name being accessed is secure. However, no company/organization information is mentioned in the certificate, so this is the lowest level of verification.

Example: robowhois.com

[image upload failed…(image-3b3829-1513224051213)]

  • Organization Validation (OV) : This level of certificate resolves the problem that the above domain name does not correspond to the company and describes information about the company/Organization. This ensures the domain name security and the binding relationship between the domain name and the company.

Example: www.baidu.com

[image upload failed…(image-e2ecb1-1513224051213)]

  • Extended Validation (EV) : This level of certificate has the highest security and is the most trusted. In addition to giving more detailed company/organization information, it also gives the company name directly in the browser address bar.

Example: www.github.com

[image-b7eb74-1513224051213] [image-b7eb74-1513224051213]

Classified by coverage level

  • Single domain SSL Certificates: This type of certificate can only be used for one domain, for example, when the certificate is paired with yourdomain.com, it cannot be used for sub.yourdomain.com.
  • Wildcard domain name SSL certificates: These certificates can cover all subdomain names of a domain name. For example, when a certificate is paired with yourdomain.com, sub.yourdomain.com and other subdomains are authenticated by default.
  • Multiple domain SSL certificates: These certificates can be used on multiple different domain names. For example, the domain name a.com and b.com can be paired with the same certificate.

Considerations for migration from HTTP

  • First of all, you need to apply for the required certificate from the relevant website;
  • Openssl port 443 on the server and set the corresponding certificate address.
server { listen 443; server_name localhost; ssl on; root html; index index.html index.htm; Ssl_certificate cert/ certificate file. Ssl_certificate_key Cert/certificate private key. ssl_session_timeout 5m; ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE:ECDH:AES:HIGH:! NULL:! aNULL:! MD5:! ADH:! RC4; Ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_prefer_server_ciphers on; location / { root html; index index.html index.htm; }}Copy the code

  • Redirection is required for port 80. The original HTTP user is automatically redirected to HTTPS.

  • For performance reasons, Session Key generation consumes CPU resources, so the number of Key generation times is minimized. There are two options:

    • Using long connection mode;
    • Caches generated Session keys during call creation (again using nginx as an example);
    http {
    Configure the shared session cache size
    ssl_session_cache   shared:SSL:10m;
    Configure the session timeout periodssl_session_timeout 10m; .Copy the code

conclusion

This article does not involve any advanced concepts, are some of their own understanding to tell, I hope to be useful to you!

Finally, recommend a good HTTP packet capture tool (including HTTPS).

  • Charles 4.0 Cracked for Mac
  • Use Charles to get HTTPS data

Original: https://github.com/jasonGeng88/blog