Prior to the start

As we all know, HTTP protocol is no secure encryption protocol, because the use of plaintext transmission, so the use of HTTP protocol site is easy to be wiretapped, tampered with, hijacked; With the development of the Internet, more and more important data are carried on the network, such as finance, business, payment, confidential data and so on. The importance of data security is becoming more and more prominent. More and more websites enable HTTPS to ensure the security of web data transmission. In addition, HTTP2.0 is a new generation of WEB protocols, with heavyweight new features to bring better, higher performance WEB services experience. This article based on the operation and maintenance perspective in the analysis of HTTP2.0 protocol compared to HTTP1.1 advantages at the same time about the principle of HTTPS protocol, and combined with the actual business scenarios as a case, the purpose is to master HTTP2.0 and HTTPS protocol through this article, understand the principle, with the ability to locate problems, tuning.

HTTP1.1 VS HTTP2

HTTP2.0 is not strictly related to HTTPS, but is used in conjunction with it. HTTP2 is the first update to HTTP1.1 since 1999. Yes, HTTP1.1, the protocol that is still in widespread use today, is 20 years old and, given the speed of technological change on the Internet, remarkably old. HTTP2 provides better efficiency and resource utilization, especially suitable for heavy pages, a large number of resources to load scenarios (companies business is a typical scenario), according to the network test data, in a large number of images, resources to load scenarios. HTTP2 solve HTTP1.1 thread blocking (a request interaction must wait before the completion of a request interaction) problem than HTTP1.1 can reach more than 5 times faster, at present, taobao, Tmall, jingdong platforms have enabled HTTP2, such as is if there are a lot of tc resources page needs to be loaded, With HTTP2.0 enabled, it’s worth every penny.

1. New features of HTTP2.0

Binary framing

  • HTTP/2 transmits data in binary format rather than HTTP 1.x’s text format, and binary protocols parse more efficiently. HTTP / 1 request and response packets consist of the start line, header, and (optional) entity body, which are separated by text newlines. HTTP/2 splits the request and response data into smaller frames, and they are binary encoded. Although HTTP1.1 plain text form looks at a glance, very intuitive, but this is only for the human experience, in fact, this way there is polysemy, such as case, white space characters, carriage return newline, more words less words, etc., procedures in the processing of time need complex processing. The efficiency is low and troublesome, while the binary method, only 0 and 1, can strictly define the field size, order, flag bit, etc., without ambiguity, small submission, but also improve the efficiency of data transmission in the network.

multiplexing

HTTP1.1 an interaction between a request and a response must wait for the previous interaction to complete, or the subsequent interaction must wait. If a resource takes a long time to load, it will slow down the loading speed of the entire site. In HTTP2.0, after a successful link, as long as the link is not broken, then the client can initiate multiple requests in a link concurrently, and each request response does not need to wait for other requests.

  • Multiplexing, replacing the original sequence and blocking mechanism. All requests are made concurrently over a TCP connection. In HTTP 1.x, multiple TCP links must be used if multiple requests are to be made concurrently, and the browser limits the number of TCP connection requests for a single domain name to 6-8 in order to control resources. A common situation is that if a page has too many static resources to load, the client browser will have a long wait time because there are only 6-8 concurrent resources, such as the main site of the political cloud. Opening a page requires dozens of requests for static resources. We spent a lot of time here.

Server push

  • In HTTP2, the server can actively push other resources while sending the page HTML, rather than waiting for the browser to parse to the appropriate location, initiate a request and then respond. For example, the server can actively push JS and CSS files to the client without having to send these requests while the client parses the HTML.

In HTTP2, the server can take the initiative to push, combined with the business scenario, the server can first push the key primary resources to the client first. For the user experience, it only takes one HTTP request for the browser to get the primary resource and the page performance is greatly improved. Of course, if you push too many resources at once, the browser will have to handle all of them. It’s a drag on performance. So you need to make trade-offs based on the business scenario.

The head of compression

  • HTTP 1.1 requests become larger and larger, sometimes larger than the initial size of the TCP window, because they need to wait for the ACK response to come back before they can continue to be sent. HTTP/2 uses HPACK (a compression format designed for HTTP/2 headers) to compress and transmit message headers, which can save the network traffic occupied by message headers. However, each HTTP/1.x request carries a large number of redundant headers, which wastes a lot of bandwidth resources. Information like cookies comes with every request, causing a lot of unnecessary resource consumption. To reduce resource consumption and improve performance, HTTP/2 uses a compression strategy for these headers:
    • HTTP/2 uses “header tables” on both the client and server sides to track and store previously sent key-value pairs, instead of sending the same data through each request and response;
    • The header table exists throughout the lifetime of the HTTP/2 connection and is gradually updated by both the client and the server.
    • Each new head key-value pair is either appended to the end of the current table or replaces the previous value in the table.

2. ALPN application protocol negotiation

  • During HTTPS handshake, the client first informs the server of its supported protocol, and the server selects a protocol supported by both the client and the server. If HTTP2 support is enabled on the server Nginx, the server will choose HTTP2; otherwise, the server will choose HTTP1.1 to communicate.

Second, SSL/TLS model

1. The TLS version

Historical TLS/SSL versions have gradually become the dust of history due to security vulnerabilities and performance problems. Currently, TLS1.2 is the most widely used version, and TLS 1.3 is an upgrade of TLS1.2, providing stronger security and higher performance.

2. Encryption suite

  • Encryption suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA Description
    • Based on TLS protocol, ECDHE and RSA are used as the secret key exchange algorithm, the encryption algorithm is AES GCM, the secret key length is 128 bits, and the hash algorithm is SHA256
    • Aes-gcm is a commonly used block encryption algorithm at present, but it has a disadvantage of large computation, resulting in high performance and power consumption. To solve this problem, Intel has introduced an extended set of x86 instructions called AES NI (Advanced Encryption Standard New Instructions) that provides hardware support for AES. Aes-gcm is the best choice for hosts that support the AES NI instruction. The advantage of AES-GCM is that multiple cores can be used to improve the performance of encryption and decryption.

3. Symmetric encryption and asymmetric encryption

Symmetric encryption algorithm

Symmetric encryption algorithm is a encryption method using single key decryption, encryption and decryption are all using this password.

  • AES is the encryption algorithm with the highest security level
    • The number of key digits of AES can be 128, 192, 256, and 512. The longer the key length, the higher the security, but the worse the encryption and decryption performance. The 128-bit key is safe enough for now.
  • Advantages of symmetric encryption algorithm: small computation, fast encryption speed, high encryption efficiency.
  • Disadvantages of symmetric encryption algorithms: before data transmission, the sender and receiver must agree on the secret key, so that the receiver can encrypt and decrypt data must be informed of the secret key. Will bring a lot of inconvenience on secret key management.

Asymmetric encryption algorithm

Asymmetric encryption algorithms have a public key and a private key. The public key is used for encryption and the private key is used for decryption. Of course, the private key can be used for encryption and the public key for decryption in different scenarios.

  • Widely used algorithm: RSA
  • Advantages of asymmetric encryption algorithms:
    • In contrast to symmetric encryption, encryption and decryption are separated. In a simple scenario, the private key is stored, the public key is disclosed, and only the private key can be decrypted. A typical scenario is SSH authentication.
    • Flexible. The secret key management is convenient.
  • Disadvantages of asymmetric encryption algorithms:
    • The computation is large and the encryption performance is lower than that of symmetric encryption. The execution efficiency of asymmetric encryption algorithm restricts the practical applications, most of which are used in authentication

Off-topic: The application scenarios of symmetric and asymmetric encryption in WannaCry ransomware are analyzed from a technical perspective

That year WannaCry ransomware destructive beyond doubt, overnight, the global government, banks, enterprises were too numerous to enumerate, in this kind of scene, why the industry’s technology leader failed to provide effective repair and recovery plan which?

  • Ransomware implementation principle: Despite zero-day vulnerabilities (the only associated with infection route of transmission, has nothing to do with the encryption technology) WannaCry after running on your computer, use symmetric encryption AES encryption suffix of the specified file, choose AES here because of the amount of calculation of the symmetric encryption is small, fast, think to wholesale suffix specified file encryption, the level is relatively large, So symmetric encryption is a more appropriate choice, but the problem is coming, symmetric encryption in encryption, decryption would expose the password, if the password is put in the client will be get then solve directly, using the smoke screen has not been challenging global technology a great god, and if you remove the password, leads to decrypt the encrypted file never, so you can’t achieve the goal of extortion. So WannaCry’s developers also use RSA asymmetric encryption to encrypt AES’s secret key and store it in the header of an encrypted file. In this case, WannaCry authors only need to master the RSA private key to decrypt the FILE using the AES secret key in the header and then using the AES secret key. So why not just encrypt files via RSA? In fact, some ransomware viruses do this. The disadvantage of this is that the encryption process takes a long time because asymmetric encryption requires a lot of calculation, and the encryption process consumes a lot of system resources and is easy to detect.
  • AES cracking difficulty: brute force cracking with every grain of sand on the earth to make storage operations, it is no exaggeration to say that before the expansion of the sun or the destruction of the earth you will not be able to work out. In short, there is no chance of it being blown up.

4. HTTPS handshake process

    1. Client – hello stage

      Client-hello is the first message sent by the Client after a TCP connection is established. The main purpose is to support the functions and options of the Client and high-speed server.

      • After the IP address is entered, the browser resolves the domain name to obtain the IP Host address. The browser establishes a TCP connection with 443 of the Host (by default, the port is connected to if another port is specified) three times, and then enters the TLS client-Hello protocol. In this step, the browser sends information about the encryption suite supported by the client and the target Host to the server, along with a randomly generated Session ticket1.

+ ALPN negotiation: The application layer can negotiate which protocol to use above the secure connection layer, avoiding additional round-trip communication, as shown in the figure aboveCopy the code

  • Server – hello stage

    • After receiving the TLS handshake request sent by the browser, the server stores the session ticket1 sent by the browser, searches for the corresponding server certificate according to the sent host, and sends the server certificate, The server selects a mutually supported encryption suite from the list provided by Client Hello according to its priority (if the intersection between the server supported suite and the Client supported suite is empty, the handshake fails) and returns a randomly generated session ticket2 to the browser.

Client-hello and server-hello steps are similar to buying things: Client: How much money do I have? Can I pay by Alipay or wechat? Server: XXX RMB is required.

  • Cipher – spec stage

    The encryption suite is negotiated between the Client Hello and Server Hello. The cipher-spec phase verifies the validity of the certificate

    • After receiving the certificate from the server, the browser verifies the validity of the certificate. The verification steps are as follows:
      • Verify certificate validity
      • Verify that the certificate domain name matches the actual host.
      • Verify certificate Revocation status (CRL+OCSP) Check whether a certificate is revoked.
      • Verify the certificate authority, if the authority is an intermediate certificate (almost all are), then verify the validity/issuer/revocation status of the intermediate certificate. Verify all the way to the last layer of certificate, midway any link does not pass will prompt distrust.
      • If the check passes, a session ticket 3 (the second ticket generated by the browser) is randomly generated. The public key in the certificate is returned, encrypted using the negotiated encryption algorithm, and the certificate is returned to the server. At the same time, the browser uses session ticket 1(browser), Session Ticket 2(server), and Session Ticket 3(browser) to form a session key.

  • Content transfer phase

    • After the TLS connection is established, the data exchanged between the browser and the server is symmetrically encrypted using the Session key before the connection is destroyed.
  • Packet capture during HTTPS handshake:

The first three conduct TCP three-way handshake, the Client initiates Client Hello in line 4, the Server replies in line 5, the Server replies in line 6, and the certificate verification in line 9 in cipher-spec stage. After the handshake is completed, the data interaction stage enters in line 13.

5. HSTS

Most of us don’t deliberately put HTTPS in front of a web site when we visit it, and we rarely pay attention to whether we’re browsing through HTTP or HTTPS. Sites that require HTTPS access mostly redirect users to HTTPS addresses through HTTP, and if I hijack user traffic, intercept HTTPS redirect requests, and then act as a proxy, forwarding the client requests and returning them, However, the client interacts with the middleman using the plaintext HTTP protocol. Since no SSL connection has been established, the information submitted by the client will be exposed. Based on this problem, the International Internet Engineering organization IETF issued a security policy mechanism for HSTS that forces browsers to use HTTPS to communicate with sites.

  • HTTP Strict Transport Security (HSTS) forces the client (such as the browser) to establish a connection with the server using HTTPS. HSTS controls browser operations primarily through the way the server sends response headers:

    • When a client makes a request over HTTPS, the server includes the strict-transport-Security field in the HTTP response header returned (the switch of HSTS is controlled by the server).

    • After the browser receives this information, any request to the site within a certain period of time will be initiated as HTTPS (307 redirect within the browser), rather than as HTTP and redirected to HTTPS by the server.

SSL certificate

SSL certificates refer specifically to digital certificates issued by a trusted digital certificate Authority (CA). The SSL certificate provides the functions of identity authentication (DV/OV/EV) and data transmission encryption.

1. CA’s credibility

  • Anyone can easily generate and issue a root certificate using the open source OpenSSL, and it costs almost nothing. You can even configure HTTPS on a Web server, just not trusted by the browser. Why do we need to pay a high cost to buy the certificate issued by CA? The root certificate of the CA certificate is very important in the certificate system. If a person has obtained the private key of the CA root certificate, it is theoretically possible to decrypt HTTPS data from the perspective of God, hijacking and tampering data through intermediaries. Therefore, the current CA root certificate has very high security requirements, a CA organization, want to pass the review, private key at least 365 days x 24 hours uninterrupted security patrol. Biometric security, such as access card + fingerprint iris, every record will be written into the unmodifiable log system. The CA private key itself is physically isolated, and the ENCRYPTION module of CA ensures that the private key cannot be copied physically and can only be used for issuing. It is conceivable that a personally generated CA would not have such a high level of security.
  • CA ultimately depends on credibility to survive. If it is not trusted, it is no different than a certificate issued by an individual. A sad case study: Votocom in China was originally a trusted root certificate authority with CA qualification, and the only CA in China. Because it issued the certificate of Github.com illegally (the risk of this behavior is that the person or organization holding the Github.com certificate can decrypt, eavesdrop and hijack Github.com), firefox browser, Google Chrome stopped trusting. They become junior agents.

2. Institutional role

  • The CA Certification Authority (CA) supports ROOT CA Level-1 CA, Level-2 CA… And so on. Multi-level CAS can be understood as the root CA issues certificates to lower-level cas for distribution. The root CA usually does not issue certificates directly.
  • A Registration Authority (RA) is equivalent to an agent, acting as an agent for CA to identify and authenticate certificate applicants, agree or reject certificate applications, actively revoke or suspend certificates in some circumstances, process subscribers’ requests to revoke or suspend their certificates, and agree or reject users’ requests to update their certificates or keys. But no certificate can be issued. Ali Cloud, for example, is an RA.
  • SRCA Untrusted CA certificates issued by private or untrusted organizations are of this type. Early 12306 used this type of certificate.

3. Certificate issuing process

3. Certificate type

DV (Domain validated)

  • A domain name authentication certificate verifies only the domain name and is issued the fastest because only the ownership of the domain name needs to be verified. Almost in real time, Let’s Encrypt’s free certificate is of this type.

OV (Organization validated)

  • The organization verification certificate will verify the organization in addition to the domain name. For example, if you want to purchase the OV certificate, it will verify not only the ownership of the domain name, but also whether the organization is correct when applying for the certificate. So the issue speed is slower, usually about 3 days, the price is also much more than DV certificate. This type of certificate is currently used by the cloud. Issuance is slow and takes 3-5 working days.

EV (Extended Validated)

  • Extended authentication certificate, browser-friendly, will directly display the organization name in the browser address bar, better brand building, also known as the highest level of security certificate, of course, it is the most expensive type of certificate. EV certificate application verification is very strict, requiring 5-7 working days, in addition to DV/OV certificate verification, the third party review, legal documents, etc., and THERE is no wild card version of EV certificate. Only single domain version can be purchased.

4. The certificate chain

When a Web server such as Nginx sends a certificate to the browser, it needs to send two certificates, an Intermediates certificate and a domain name certificate. The root certificate is not required because the root certificate is built-in to the operating system. The domain name certificate is sent first and then the Intermediates certificate is sent. The browser is responsible for verifying that the root certificate that issued the Intermediates certificate is valid and trusted.

Root Certificate (root)

  • Mainstream systems such as Windows, Android, and Linux update the root certificate library once a year or more. Most browsers use the root certificate library of the operating system, with some exceptions, such as Firefox. Google Chrome maintains its own CA certificate library. A new root certificate is hard to trust in a short period of time.

Certificate of Intermediates

  • Usually, CA organizations do not issue domain name certificates directly. Instead, they issue certificates by authorizing a secondary CA, which can sub-authorize a tertiary CA…. Such certificates that are not issued directly by CQ are called Intermediates certificates. This type of certificate can have many levels, no limit, but the verification of certificate validity, layer by layer, until the CA root certificate is found. Most of the Intermediates certificates currently purchased are level one. Such as:

The domain name certificate

  • Domain name certificates are classified into public and private keys. When the browser interacts with the WEB server, the WEB server returns the public key to the browser.

5. The certificate is revoked

  • Certificate Revocation List (Certificate Revocation LIst indicates the CRL. The CRL contains the expiration time and next update time of the CRL.

  • Online Certificate Status Protocol (ABBREVIATED: OCSP) : a substitute for THE CRL. Because the OCSP response contains less information than the CRL, it reduces the burden on network and client resources and requires less information to be parsed.

4. Operation and maintenance challenges brought by HTTP2.0 era

1. Best CP: HTTP2 + HTTPS

HTTPS is an HTTP protocol based on SSL/TLS. Therefore, how much more server resources are used in HTTPS than HTTP depends on how much SERVER CPU resources are consumed by SSL/TLS. The network part: HTTP uses THE TCP three-way handshake to establish a connection. The client and server need to exchange 3 packets. HTTPS in addition to the three packets of TCP, plus the nine packets required by the SSL handshake, so there are 12 packets in total. The CPU consumes more resources because of the HTTPS decryption process. HTTP2.0 standard, although there is no mandatory use of encryption (HTTPS) but currently mainstream browsers, chrome, firefox, etc., have publicly announced that only support encryption of HTTP2, so the current Internet can see HTTP2 is based on HTTPS protocol. HTTPS guarantees the security of the transport but incurs additional performance overhead, while HTTP2 has just emerged through multiplexing, header compression and other features to greatly improve transport performance. I have to say that HTTP2 + HTTPS is the best combination of the new generation of Web services.

2. Problems caused by incomplete certificate chain

  • Symptom: The company switched to a new domain name, and some customers reported that there was an untrusted certificate when their mobile phones opened the official website after ali Cloud directly deployed the certificate to SLB. But chrome opened on the computer and everything was fine.
  • Operating systems usually include trusted cas, but many certificates are not issued directly by cas. Instead, a mid-tier certificate is used for signing. This will cause if you deploy the middle tier of the certificate is not contained in the certificate, because the certificate chain is not complete and not be trusted, mainstream chrome and firefox browser, of course, already contains most of the middle tier certificate when visit so there is no problem, but like all sorts of android distribution inside the browser, does not necessarily include secondary certificates, If the Web server does not include an intermediate certificate and uses a browser that does not include an intermediate certificate, trust issues can result.

3. Certificate security

  • One issue that can easily be overlooked when HTTPS is deployed is the security of the certificate itself. The leakage of HTTPS private keys may cause many security problems. The above content can be learned. If the private key is obtained, the interaction between the user and the server is basically in a state of streaking under certain conditions. The user account secrecy and order transaction information may be intercepted. Therefore, it is necessary to manage the SSL certificate itself issued by the CA, and cannot be copied or placed at will.

4. Monitor certificates

  • Using the curl command, you can obtain the HTTPS handshake process and certificate details. Usually we monitor certificate expiration times by getting expire dates. Curl curl curl curl curl curl curl curl curl curl curl curl curl curl You can also use openSSL or write a script to monitor openssl without using curl.
wangxun@wangxun ~ curl https://zcygov.cn -vv * underway URL to: https://zcygov.cn/ * Trying 101.37.44.108... * TCP_NODELAY set * Connected to zcygov.cn (101.37.44.108) port 443 (#0) * ALPN, offering h2 * ALPN, Offering HTTP /1.1 * Cipher Selection: ALL:! EXPORT:! EXPORT40:! EXPORT56:! aNULL:! LOW:! RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: /etc/ssl/cert.pem CApath: TLSv1.2 (OUT), TLS Handshake, Client Hello (1): TLSv1.2 (IN), TLS Handshake, Server Hello (2): TLSv1.2 (IN), TLS Handshake, Certificate (11): TLSv1.2 (IN), TLS Handshake, Server Key Exchange (12) TLSv1.2 (IN), TLS Handshake, Server Finished (14): TLSv1.2 (OUT), TLS Handshake, Client Key Exchange (16) TLSv1.2 (OUT), TLS Change Cipher, Client Hello (1): * TLSv1.2 (OUT), TLS Handshake, Finished (20): TLSv1.2 (IN), TLS Change Cipher, Client Hello (1): * TLSv1.2 (IN), TLS Handshake, Finished (20): * SSL connection using TLSv1.2 / ecdhe-rsa-aes128-GMM-sha256 * ALPN, Server accepted to use HTTP /1.1 * server certificate: * subject: C=CN; ST=\U6D59\U6C5F\U7701; L=\U676D\U5DDE\U5E02; O=\U653F\U91C7\U4E91\U6709\U9650\U516C\U53F8; OU=IT; CN=*.zcygov.cn * start date: May 7 00:00:00 2019 GMT * expire date: May 6 12:00:00 2021 GMT * subjectAltName: host "zcygov.cn" matched cert's "zcygov.cn" * issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=GeoTrust RSA CA 2018 * SSL certificate verify OK. > GET/HTTP/1.1 > Host: zcygov.cn > user-agent: Curl /7.54.0 > < HTTP/1.1 301 Moved Permanently < Date: Wed, 07 Aug 2019 07:16:47 GMT < content-type: text/html < Content-Length: 191 < Connection: keep-alive < Set-Cookie: acw_tc=76b20feb15651622072312298e0526c6496462332328e0842a443f28ecb7be; path=/; HttpOnly; Max-Age=2678401 < Location: https://www.zcygov.cn/ < <html> <head><title>301 Moved Permanently</title></head> <body bgcolor="white"> <center><h1>301 Moved Permanently</h1></center> <hr><center> OpenReSTY /1.13.6.1</center> </body> </ HTML > * Connection #0 to host zcygov.cn left intactCopy the code

6. Configure HTTP2 and HTTPS in Nginx

server { listen 4433 ssl; listen [::]:4433 ssl; server_name cai-inc.com; add_header Strict-Transport-Security "max-age=31536000; includeSubdomains"; HSTS ssl_protocols TLSv1 TLSv1.1 TLSv1.2; Ssl_ciphers "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH:! aNULL:! eNULL:! EXPORT:! DES:! MD5:! PSK:! RC4"; # Server supported and unsupported encryption suites. ssl_certificate "/etc/letsencrypt/certs/fullchain.pem"; ssl_certificate_key "/etc/letsencrypt/certs/privkey.pem"; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; ssl_prefer_server_ciphers on; Location / {proxy_pass http://127.0.0.1:8899; }}Copy the code

conclusion

  • HTTP2.0 is a good match for HTTP1.1 and HTTPS for link security. Using HTTP2.0 can significantly improve page loading efficiency when dealing with heavy page loading.
  • The core of the HTTPS certificate system is the trusted CA. The disclosure of the HTTPS certificate private key of the same domain name also causes security risks, because the private key of the domain name certificate must be kept properly when the domain name certificate is deployed on the user side.
  • During certificate deployment, a complete certificate chain must be deployed. Otherwise, some old devices may fail to pass certificate verification.
  • Forging a root certificate and being trusted by the operating system is scary, meaning that all of your requests are naked in the eyes of the owner of the root certificate private key.
  • Untrusted certificates can cause major stability incidents, so it is necessary to monitor certificates