TLS/SLL is an important part of secure network communication. Through key exchange and key generation, the whole process of encryption channel is finally established. As we all know, TLS/SSL takes a considerable amount of time. Compared with TCP’s 3 RTT times, if TLS/SSL is added, the total RTT time is at least 4 times. Although it seems to be a lot, if compared with the current network environment, it is about 20~30ms each time, so it is estimated to be about 100ms. That’s a tolerable time lag, but I’m not counting DNS resolution yet. In addition, TLS/SSL generated sessionkey if the expiration date, then this time can be completely ignored. Without further discussion, let’s get straight to the basics of TLS/SSL.

Please Call me HR

The TLS algorithms

TLS/SSL is actually the process of generating symmetric encrypted sessionkey through asymmetric encryption. Symmetric encryption algorithm is no more than AES, or Cipher/Decipher module. Asymmetric encryption is usually RSA, but diffie-Hellman is also used. But, in terms of security, DH is higher. When RSA generates a sessionkey, browser generates the sessionkey, encrypts it with the public key, and sends it to the server. The problem is that if a hacker obtains a private key, He can monitor the traffic all the way and then decrypt it using the private key, which, predictably, exposes the sessionKey. The difference between DH and SessionKey is that the Sessionkey is generated independently at both ends instead of being transmitted over the network. Ok ~ This involves the consistency of the two keys. DH also has perfect Forward Secrecy (PFS) : The private key on the server side cannot be used to replace any previous sessionkey, so it cannot decrypt any previous session content. DH regenerates a key for each connection and discards it when the session ends. However, this is not too much of a problem, because DH generates keys very quickly. Because it takes half as much time on the network as RSA. The following figure shows the DH encryption algorithm:

In simple terms, the two sides complete the key generation through a one-time information exchange. Because the sessionKey is placed independently at both ends, DH needs to renegotiate and generate the sessionkey every time the connection is connected to achieve consistency. Now the question is: why should there be a session key? What is its purpose?

Sessionkey purposes

TLS/SSL is actually a process of generating symmetric encrypted session keys through asymmetric encryption

So what does the session key basically do? First of all, we need to make it clear that the session key is used for symmetric encryption, which mainly uses AES encryption algorithm. This is different from Elliptic Curve Diffie-Hellman (ECDH), which is an asymmetric encryption algorithm. Both can actually be used to encrypt information, but they take different amounts of time due to different implementation mechanisms within the algorithms. Basically, ECDH takes three times as long as AES.

You can test this for yourself:

openssl speed ecdh
openssl speed aes
Copy the code

Ok, the algorithms used for TLS/SSL are outlined above. Next, let’s take a look at the process of TLS/SSL key exchange.

The TLS/SSL process

Before we get into the details of the process, we need to understand what happens during the process.

  • Session key: This is the result of TLS/SSL negotiation and is used for symmetric encryption.
  • Client Random: is a sequence value of 32B that is dynamically generated for each connection. That is, the value generated for each connection is not the same. Because it contains a 4B timestamp and a 28B random number.
  • Server Random: Like client Random, it is generated by the server.
  • Premaster Secret: This is 48B bloB data. It can pass client & Server Randompseudorandom(PRF) Generates session keys together.
  • Cipher Suite: Defines the algorithm used for TLS connection. There are usually four parts:
    • Asymmetric encryption (ECDH or RSA)
    • Certificate Validation (Type of certificate)
    • Confidentiality (symmetric encryption algorithm)
    • Data integrity (functions that generate hashes) for exampleAES128-SHARepresents the:
      • The RSA algorithm performs asymmetric encryption
      • RSA performs certificate authentication
      • 128bit AES symmetric encryption
      • 160bit SHA data encryption algorithm
    • Such asECDHE-ECDSA-AES256-GCM-SHA384Represents the
      • ECDHE algorithm for asymmetric encryption
      • ECDSA performs certificate verification
      • 265bit symmetric AES encryption
      • 384bit SHA data encryption algorithm

I’m sure you’re familiar with this picture:

But doesn’t it say there are two different types of asymmetric encryption? RSA & DH? So why is the map just one? Ok, this is actually correct, he didn’t write down what he was transmitting, which is crucial. And the two algorithms are also separated in the transmission of content, the basic process is exactly the same. According to the wiki, we have a pretty good idea of what we need for the whole transfer process.

  1. The client sends a clientHello message, which contains the highest TLS protocol version supported by the client, random Num (mentioned above), Cipher Suite. If the client uses resumed Handshake, the sessionID is sent. If the client also supports ALPN, it should also need to send other protocols it supports, such as HTTP/2.
  2. In the ServerHello phase, the server adopts different policies according to the information sent by the client. The server also sends the highest VERSION of TLS that matches the information sent by the client. Cipher Suite and random num generated by itself. In addition, a unique sessionID is generated for this connection.
  3. In the Certificate phase, public Key Certification is added to the information flow. ServerKeyExchange This stage is mainly aimed at ECDH encryption mode, which is not described here and will be explained later.
  4. ServerHelloDone Indicates the end of the server phase and sends the information generated in this phase to the client.
  5. In the clientKeyExchange phase, the client randomly generates a pre-master secret sequence, which is encrypted with a public key and sent to the server. In ChangeCipherSpec, the client generates the sessionKey through pre-master Secret + Server random-num + client random-num. This indicates that the TLS/SSL process is nearing its end on the client side.
  6. The subsequent ChangeCipherSpec on the server side is similar to that on the client side. The private key is used to decrypt the pre-master Secret sent by the client, and then the sessionkey is generated. After the authentication, the session Key is used for encryptionserver finshedTo see if the decryption is successful to indicate that the final TLS/SSL is complete.

The above is mainly based on RSA encryption mode to explain. Because RSA will transfer the pre-master secret display during TLS/SSL, it is possible that hacker will get the private key and then generate the same sessionKey. That is, the security of the connection is lost.

Next, we will focus on another encryption method, DH. The main difference between RSA and it is whether to pass pre-master secret. RSA is transmitted but DH is not.

According to CloudFlare, the difference between the two is clear:

This is the TRANSMISSION mode of RSA, and the basic process is described above.

The specific differences of DH are shown in the following figure:

So let me just give you a little bit of background on the DH algorithm. Because that’s how pre-master Secret was generated. The basic DH process is not too difficult. See the wiki for details. The main formula used is:

To prevent large data during DH parameter exchange, DH uses modulus to limit the transmitted value to always be [1,p-1]. Here, the basic conditions of the DH algorithm are explained:

  • Common conditions: both P and G are known and disclosed. That is, third parties can also freely access.
  • Private conditions: A and B are generated by both ends and cannot be obtained by a third party.

The basic process is:

We simply replace the DH parameter in the figure above with the corresponding X/Y. And the final Z is the Premaster Secret we want. After that, it is consistent with the RSA encryption algorithm, and random num on both sides is added to generate the sessionKey. Pass, we often call DH also called Ephemeral Diffie-Hellman Handshake. Because his sessionKey is different every time.

The difference between RSA and DH is that RSA transmits premaster secret, which may cause security problems caused by private key leakage. DH does not transmit the premaster secret display.

Basic concepts in TLS/SSL

The above Outlines the basic TLS/SSL encryption process. However, there are many other small details, such as SNI, ALPN, Forward Secrey. We’ll focus on these details, because they’re also important.

Forward Secrey

FS(Forward Secrey) mainly describes private keys. If your private key can be used to decrypt the session contents of previous communication, for example, if your private key is used to decrypt your premaster Secret, then you can decrypt the contents of the transmission. This case is called non-forward-secrey. So how do you do FS? It is very simple and has been mentioned above. Use DH encryption. The final sessionKey is not directly related to the private key. The premaster secret is obtained by g(ab) mod P.

Simply put, if you want to enable FS, you should use DH encryption instead of RSA. However, RSA is still the dominant encryption method for historical reasons (TLS version issues). But the DH is also increasing his share with the safety of his 5S.

ALPN

ALPN stands for Application Layer Protocol Negotiation. By looking at the application layer, programmers should be able to reflect the OSI 7 layer network protocol. In the application layer, the HTTP protocol should be the focus. However, due to issues with the HTTP version, and now the popularity of HTTP2, ALPN has emerged in order to make client-server use the same protocol. ALPN is actually derived from the NPN protocol in SPDY. But they work in reverse.

  • NPN: The server tells the client which protocol it supports. Then the client confirms the supported protocol and starts the connection.
  • ALPN: In TLS phase, the client tells the server all the protocols it supports and then starts the connection.

Generally speaking, NPN is out of history… ALPN is now a standard protocol specified by the IETF. The specific process of ALPN in TLS is as follows:

  • In the clientHello phase, the client adds a ProtocolNameList field to the message. Represents the list of protocols it supports
  • In the serverHello phase, the server processes the ProtocolNameList provided by the client. Select the protocol of the highest version and run the command. Add selection information to serverHello.

SNI

Full Name of SNI: Server Name Indication. This mechanism is proposed when there is a server that handles many hosts at the same time. As a result, one IP address maps multiple domain names, but since the certificate can only be valid for a level 3 domain name, for multiple hosts, the server needs to take care of these domain names simultaneously. An easy way to do this is to redirect to a given domain name, or if you want to support both, buy your own certificates. If you are very rich, there is such a situation, under an IP server, carrying multiple domain name server, and each domain name has a valid CA certificate. So how does the server determine which certificate is used for which domain name? And that’s where SNI comes in. This is equivalent to sending the host in the TLS phase, and the server knows what certificate to return in the ServerHello phase. Now, the question is, why do WE have to use SNI? Recall that we are only setting up a TCP + TLS connection here, and some of the client content, such as hostname, is not available in TCP. If you want to get it, you need to wait until the HTTP phase to get the host or Origin field from the client. Therefore, in order to solve this awkward point, SNI was proposed.

Session Resumption

I feel like anyone who can see this place should be a bum… If I had to look at this article, probably a few pictures, I would basically just shut down the site. Because it’s really complicated. And that’s just the complexity of the protocol. For a Computer, it just needs to remember what to send each time, but it’s the calculation of the key that really hurts the Computer. In particular, random key and Premaster Secret tend to be 32B or 48B data. So, to really reduce the amount of work on the computer (actually the server), Session IDS and Session Tickets are proposed to cache Session content that successfully connects.

Session ID

The Session ID indicates that the server saves the content of the last successfully connected Session on its own hard disk. There is no secondary encryption of session data. The basic process is:

  1. In the clientHello phase, the client sends random Num, TLS Protocol, and the latest session ID matched by hostname to the server. (In other words, the client also needs to store a session data.)
  2. After receiving the session ID, the server searches for it in the cache. If it finds the session ID, the server directly performs the ChangeCipher phase to generate the sessionKey. Then, return the same sessionID.

So only one RTT is used, as opposed to a full TLS/SSL connection. Then the protocol process becomes:

Session Ticket

Since Session ids are for network latency and computer performance, what does a Session Ticket do? The Session Ticket and Session ID do the same thing. The server sends the latest Sesion data through secondary encryption at the end of the last handshake, and the client saves the data. In this case, it’s up to the client to make use of the cached session data. If the session data does not expire, the client sends the data in the clientHello phase, the server receives the data, decrypts it, and then generates the sessionKey, and the handshake ends. So which one do I use, Session Ticket or Session ID? Depending on your business, Session ids are about saving performance, not space. Session tickets focus on saving space at the expense of performance. Both can save an RTT, depending on your server.

CA Certificate Details

The previous section outlined how TLS/SSL works and what connection methods are available. It’s like learning to draw a line, we know how long the line should be drawn, but we don’t know where the line should be drawn from. So then we need to talk about what’s going on at both ends. In fact, it is not difficult, mainly about the storage and verification of CA certificates. The server side is very simple, is to send their OWN CA certificate ok. However, verifying that the certificate is trusted by the client is a bit more complicated. First of all, there are only a few certification authorities, in other words, each certification authority represents a CA certificate. However, the HTTPS sites on the market are so hot that they all use the same certificate. Do they all have the same PU/PR key? So does HTTPS security still work? Therefore, following the above reasoning, HTTPS certificates on our site must be different. Generally speaking, there are three types of certificates: Domain Validation (DV), Organization Validation (OV), and Extended Validation (EV). The average price goes up in order, so the cheapest one is DV, which should be affordable to our hard-working poor masses. The specific difference between them is domain name support:

  • DV: It is the personal certificate, which basically supports single domain name and multiple domain name, but does not support pan-domain name (*.villainhr.com). Look at the prices, however, for example, I this is tencent clouds give a free DV certificate, so that can support a level 3 domain name (https://www.villainhr.com). If it is charged, single/multiple domain names should be supported.
  • OV: More awesome, enterprise-oriented, multi-domain/pan-domain support.
  • EV: It belongs to aristocrats, ordinary people can not get it, mainly it needs to buy an insurance…

Then our certificate in the numerous certificates, is in which level? It’s usually three. How does that manifest itself?

So with all these certificates, which one do we use? Of course it is, the one at the bottom. Since not every certificate is trusted, the client first needs to know if your certificate can be used for authentication. If not, your connection is untrusted and there is no small green lock. So you need to understand the client side of the authentication process.

CA chain verification

First of all, what is a trusted certificate? We need to understand that HTTPS is built on the mutual trust between people first, and then on the mutual trust between machines. Suppose, for example, that the root certificate A authority maliciously sends A previously issued certificate to another shameless blocking site (for example, for advertising). That way, once I get this certificate, I can build my own server and use it to block browsing, monitor your site, and forcibly insert ads. This is called an untrusted authority/certificate. And the feasibility of verification, usually with the authority of the organization has a great relationship. The basic validation process is summarized as follows (in the hierarchy above) :

  • www.villainhr.com Ask TrustAsia DV SSL, can I trust my certificate?
  • Trusted! Ok, go ahead. TrustAsia DV SSL Ask VeriSign Class 3 whether my certificate can be trusted
  • Trusted! Ok, and then the TLS/SSL connection begins.

If there is a problem with any of the above steps, TLS/SSL will not proceed and will be fallback. So when they ask, do they send network requests? No, it doesn’t, because when the computer is initialized, it comes with a number of trusted certificate authorities (Root CA), which is the VeriSign Class 3 certificate authority we just mentioned. And, there are (relatively few) secondary bodies that can issue certificates. The browser will automatically verify the certificate against the digital signature.

CA Validation

As stated above, the validity of CA certificates is verified from the bottom up. So what are their validation protocols? Before we get to that, let’s talk about a few concepts:

  • Digital signature: It is the value generated by encrypting the public key of the subordinate certificate with the issuer’s private key. Digital_sign = CA_pr_key + sub_Cer_ppu_key.
  • Decryption: Decrypts the digital signature using the public key of the authority and compares the public key of the lower-level certificate with the decrypted value.

CA validation first needs to say something about its issuing process:

  • Issuer A encrypts the public key of lower-level certificate B with its own private key to generate A digital signature, and then carries related information: public key, public key fingerprint, digital signature, certificate name, issuing authority, etc.

Then, the verification process is based on this:

  • The browser parses the information about lower-level certificate B and finds the issuing authority and digital signature.
  • Then, find issuing authority A, use A’s public key to decrypt the digital signature, and compare the lower-level certificate B’s public key. It’s legal if it works, illegal if it doesn’t.

And the certificate level 3 above, is the same reason, top-down search ok. Of course, sometimes some caching is done for the speed of validation so that validation is not necessary. So, according to the above description, there are children shoes may think, can from the visa book? Anyway, the browser is found locally. Sure, OpenSSL can generate your own CA. However, it is important to note that the CA you are generating will only work on your own computer. If you want to ensure that your CA will work on other computers (which is not possible), you can spend money on it. For details, see generating your own CA certificate. I used to wonder, when I was using Charles and Fiddler, how they were able to turn their certificates into issuing authority certificates.

Later, it was discovered that it was the relevant fields in the certificate as its certificate content. However, there are still some problems with some advanced certificates, such as wx.qq.com.

In addition, in order to ensure the reliability of certificates, the Certificate Transparency project is put forward. In fact, the Certificate authority makes its issuing flow public. To prevent duplicate issuance.

Revocation of certificate

Now I have a question, why does the certificate have an expiration date? This is also for security, as mentioned earlier, if your certificate has been compromised (in effect, the private key). Other servers can then act as proxies to intercept your traffic. At this time, due to the expiration of the reason, may be a period of time, in the middle of the malicious server is useless, in addition, if you find that you lost the certificate, you can report the loss to the issuing authority. Another reason is the CRL mechanism of certificate revocation. Simply put, there is a list of certificates that have been revoked by the authority at the current time. If there is no expiration time, the list will grow exponentially over time. With the expiration mechanism introduced, the list only needs to record information about the certificates that are not currently expired but are revoked. Certificate revocation has two mechanisms: CRL and OCSP

CRL

Certificate Revocation List (CRL) : Certificate Revocation List. The CA generates a list of the serial numbers of the revoked certificates in the current period, which is also verified during certificate verification. If the certificate has been revoked, the TLS/SSL connection will also fail. We can find the CRL URI from the certificate information:

Although the protocol is simple, it has many defects.

  • Download time. Because the list is not native, it needs to be downloaded from the issuing authority, which causes network latency.
  • Cache time. If there is a cache, there is the problem of information not being synchronized, and if a certificate is expired but the cache shows that it is not, then there is also a security issue.

OCSP

Online Certificate Status Protocol (OCSP) : indicates the Online Certificate Status Protocol. It does this through an online request, without downloading the entire list, just sending the serial number of the certificate to the CA for verification. Of course, there will be some cache time for validation. However, there is also a delay due to validation. In addition, OCSP deployment also has certain requirements on the CA. The CA needs to set up a server to accept the verification, and the server performance is good (heavy load).

OCSP stapling

OCSP stapling is often called TLS Certificate Status Request Extension. Is another implementation of OCSP, because the first two (OCSP,CRL) are the client to verify whether the certificate is revoked, and both send a request. OCSPs (OCSP stapling) verifies the validity of certificates directly on the server. The server periodically sends a request to the CA to verify the validity and sends the corresponding signature information in the Certificate phase. However, the protocol is built on the premise that we fully trust serve, which precludes some malicious intermediate servers. For details, see OCSP Stapling.

The TLS/SSL optimization

TLS/SSL main performance tuning simplications include: enable False Start, OSCP Stapling, select appropriate Cipher Suite, Transnistor, etc. On the other hand, if you are looking for fashion, HTTP/2 should be a good choice. To do TLS/SSL optimization, you need to understand what the TLS/SSL handshake is all about. Sure, you can buy a certificate and build your own server from scratch, but that proves nothing but that you’re rich. Because, this can completely build their own Intranet ah ~ can refer to: 10s self-built certificate. Here, we combine nGINx to specific TLS/SSL Handshake optimization, do an overall elaboration.

Setting session Caching

The session cache setting allows two RTTS to be one, which is twice as fast (excluding key calculations, etc.). There are many ways to set a session for different servers. Here, nginx is used as an example. In Nginx, the Session ID form is supported, that is, the encrypted contents of previous sessions are cached in the server. There are two fields involved, SSL_session_cache and SSL_session_timeout.

  • Ssl_session_cache: used to set the session cache upper limit and whether the session cache can be shared among multiple workers
  • Ssl_session_timeout: Used to set the duration of the session cache

Watch a demo:

ssl_session_cache shared:SSL:10m;
ssl_session_timeout 20m;
Copy the code

Session cahCE will be shared among different workers, assuming that 1MB can only store information of 8000 handshakes. So 10 MB can store 80,000 handshakes. If it is exceeded, it will not be stored. The cache information exists for 20 minutes. Alternatively, you can enable session ticket. Session ticket (ST) requires a sign parameter, which can be created using OpenSSL.

$ openssl rand 48 > ticket.key
# Enable in nginx
ssl_session_tickets on; 
ssl_session_ticket_key ticket.key;
Copy the code

Choose an appropriate Cipher Suite

To be clear, the content of your certificate has nothing to do with your encryption suite. It all depends on how well your server supports it and how well your client supports it. In addition, if you want to enable False Start, this can also make a big difference in the choice of suite. Let’s take a look at the setup. In nginx, two main instructions are used:

ssl_prefer_server_ciphers on;
ssl_ciphers xxx;
Copy the code
  • Ssl_prefer_server_ciphers: tells the client to choose the preferred encryption suite I provide.
  • Ssl_ciphers: Specifies the content of the encryption suite to be set, used:Space.

The most supportive is the use of:

// Let the browser decide which suite to use (err... Last resort) ssl_ciphers HIGH:! aNULL:! MD5;Copy the code

In general, it’s up to you to decide which kit to use and whether it’s safe or not. For details, see Mozilla’s suite configuration. Here’s a safe one. All of the kits below must support Forwar Secrecy

ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:! ADH:! AECDH:! MD5Copy the code

However, it is best not to use the following encryption suites because they are basically insecure:

  • ANULL: a non-standard DH key exchange suite. Easy to beA middlemanAttack.
  • ENULL: plaintext is exchanged without encryption
  • EXPORT: a weak encryption method, used in the early days of the American side
  • RC4: Use the defunct ARCFOUR algorithm
  • DES: Use the obsolete Data Encryption standard
  • SSLv2: SSL2.0 encryption suite (at least, you also write SSLv3)
  • MD5: Uses THE MD5 encryption mode

The ones above are only available to some ancient browsers and are basically the bottom of the list of choices.

False Start

Also, how to enable False Start in nginx? It’s not really about the server, it’s about the suite you choose and the NPN/ALPN protocol.

  • First, your encryption kit must have Forward Secrecy or it won’t work.
  • The browser needs to use NPN or ALPN to tell the server the required protocol version and then decide whether to enable it or not.

So, in Nginx, we just need to choose the right encryption suite. I’ll just put a ready-made one here

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE -RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA -AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AE S256-SHA:DHE-RSA-AES128-SHA256::DES-CBC3-SHA:! aNULL:! eNULL:! EXPORT:! DES:! RC4:! MD5';
Copy the code

Use DH key exchange

The DH encryption process has been described above. DH comes with two common parameters, so this must be created manually (in effect, the parameter is signed).

// Create a DH param openssl dhparam 2048-out dhparam.pemCopy the code

The file is then invoked

ssl_dhparam dhparam.pem;
Copy the code

In this way, you are officially in DH encryption mode. If you use the packet capture tool to observe, DH should be in Server Hello:

However, due to historical reasons, DH Param has been used with a length of 1024, e.g. Oakley Group 2 version. At present, the popular DH encryption method is ECDHE, which is much faster in key generation than the previous encryption method (DHE). Again, the base condition is relatively high for historical reasons :(which is fine)

  • Android > 3.0.0
  • Java > 7
  • OpenSSL > 1.0.0

Open the OCSP Stapling

OCSP Stapling is a way to verify the authority of a certificate. There are also two types of CRLS and OCSPS. However, they all leave it up to the client to verify. OCSP Stapling puts validation into the server and checks it periodically to reduce network time consumption. To enable OCSP Stapling, you first need your certificate’s chain file, which specifies all the validations you need to go through from the root certificate to your certificate (just like the other two validations). So how do you get the chain file? Go directly to your certification authority. It’s not a secret document. If it’s a self-generated certificate (for your own testing), generate it yourself. Put all intermediate certificates in a file according to “Bottom to Up” :

cat intermediate/certs/intermediate.cert.pem \
      certs/ca.cert.pem > intermediate/certs/ca-chain.cert.pem;
Copy the code

Then ca-chain-cert. pem is the OSCP stapling authentication file. Then open it in nginx.

ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate ca-chain.cert.pem; Resolver 8.8.8.8 8.8.4.4; // Use Google by defaultCopy the code

For DNS resolution, you also need to ask the certificate provider, of course, this value can be ignored. The same applies here

ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate ca-chain.cert.pem;
Copy the code

After the opening, you can use the openssl s_client – connect www.yourDomainName.com:443 to test, test whether open success.

Open the HSTS

HSTS (HTTP Strict Transport Security) is essentially a response header, nothing special, except that all of your requests to the outside world are HTTPS, so there’s a problem. If your image address is HTTP, the end result, It changes to https://xxx, which may cause resource loss. Therefore, be careful whether to enable or not.

Strict-Transport-Security: max-age=15768000 # Set a mandatory 6 month period
Copy the code

The client will try to use HTTPS to access your site during this period of time. If your certificate expires during this period, HTTPS cannot be opened. Well, hehe.

Use the SNI

SNI is the protocol mechanism that you use when you have multiple certificates on one IP, and it’s basically to distinguish between different hosts using different certificates. The DETAILS of SNI have been mentioned above and will not be repeated here. The main format used is different server_name with different certificate

server{
    server_name www.abc.com;
    ssl_certificate abc.crt;
    ssl_certificate_key abc.crt.key;
}
server{
    server_name www.def.com;
    ssl_certificate def.crt;
    ssl_certificate_key def.crt.key;
}
Copy the code

How do you turn it on? Switch to a higher version of Nginx. You can use nginx -v to check if your nginx has it

TLS SNI support enabled
Copy the code

Complete sample

Finally, put in the whole one:

server {
        listen 443 ssl http2; Http2 is enabled by defaultlisten [::]:443 ssl http2; ssl_certificate /etc/nginx/cert/bjornjohansen.no.certchain.crt; ssl_certificate_key /etc/nginx/cert/bjornjohansen.no.key; ssl_session_cache shared:SSL:10m; ssl_session_timeout 20m; ssl_prefer_server_ciphers on; ssl_ciphers ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:! ADH:! AECDH:! MD5; ssl_dhparam /etc/nginx/cert/dhparam.pem; Ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_stapling on; ssl_stapling_verify on; ssl_trusted_certificate /etc/nginx/cert/trustchain.crt; Resolver 8.8.8.8 8.8.4.4;Select DNS IP as appropriate

        #add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
        # I don't usually run HSTS
        # add_header Strict-Transport-Security "max-age=31536000" always;
}
Copy the code

The reference list

This, too, is easy to configure, and you can get much richer content from Mozilla. Please refer to:

  • Wiki.mozilla.org/Security/TL…
  • Wiki.mozilla.org/Security/Se…
  • HPBN. Co/transport – l…

In addition, there are some test tools and build tools, and a list of them is also provided here:

  • Touch the official test tool straight
  • The official TLS/SSL configuration generation tool was straightened out
  • SSL Lab TLS/SSL test tool