HTTPS Fundamentals and Configuration-2
This article was last updated on: July 24, 2024 am
〇、Overview
As an overview, here’s what this article is about. What is HTTPS? Everyone probably recognizes HTTPS from the browser and has a good impression of it. Moving on to the basics, and then to the protocol version, cipher suites, the focus of this article will be on how to configure NGINX so that your website uses HTTPS services.
In addition to this, there is the issue of using HTTPS as a proxy; So, if your NGINX is in front of another application, how do you set NGINX as an HTTPS client.
Here, I’ll cover some ways to check your HTTPS configuration to see that it’s the most secure and up-to-date, as well as some additional topics to help you get the A+ level of security you need.
This article covers the following:
- What is HTTPS
- Protocol version
- Cipher suites
- certificate
The next article will include:
- Configure NGINX
- Back-end HTTPS
- Check the configuration
- Configure HSTS
- OCSP Stapling
1. What is HTTPS
As you might guess,HTTPS It is HTTP add S, S stands for Security. As far as networking is concerned, there are two protocols called SSL and TLS. They can be used interchangeably. However, a security protocol is a layer of security that sits on top of communications. If you think about the OSI seven-layer network model, it’s located below layer 7, layer 6, called the presentation layer.
Between the client and the server, it provides you with the confidentiality of your data. Therefore, all information sent from the client to the server is fully encrypted, so only two people know how to read the information, and that is the client and the server. It also provides a form of authentication in which the client knows who the server really is. These are all intertwined in the concept of handshake.
1.1 SSL handshake (Diffie-Hellman)
- client: The client sends hello, client random, and cipher suites to the server.
- Step two
- 2a:serverSend server random and public key certificates (also a session ID for session multiplexing) to the client.
- 2b: Key signing for client random, server random, and public key certificates.
- serverSend server DH (Diffie-Hellman) parameters and key signature to the client.
- clientSend the client DH parameters to the server.
- Both the client and server get the same premaster secret from the server DH parameter and the client DH parameter.
- Both the client and server receive the same session keys from the client random, server random, and premaster secret. The client can request content from the server, and the request will be encrypted. (Session tickets for session multiplexing are also sent.)
The diagram above shows the SSL/TLS handshake flow. It’s a bit complicated; There are a lot of movable parts, but essentially, if you take a step back and look, it’s an extra round trip or two between the client and the server sending the encrypted message. In this case, you have several options – there is server random, there is client random; These are esoteric things you don’t need to know.
All you need to know is that the server itself sends a public key, and the client and server establish a shared secret that they can use to encrypt communication. Therefore, all communication between the visitor and the server is encrypted with a symmetric key, which means that both parties have the same key. There’s also an integrity key, in this case HMAC, but I’ll skip this diagram for now and move on to the more important question: “Why do I need to set up HTTPS?”
1.2 Why do you need to set up HTTPS
- User Privacy
- SEO bonuses
- Put it in front of “services without HTTPS capabilities”
- Common best practices
The main reason is user privacy. In the case of service communications, this is the privacy of the information - how much do you trust the network you are using to transmit information? Do you trust that these networks do not inject information into your traffic and are able to read the transmitted information? In addition, after 2015, if you use https on your website, it provides an SEO advantage, and Google rankings (and Baidu in China) will rank higher than those websites that do not support HTTPS.
Another thing you can do for HTTPS (which is one of the main use cases for NGINX) is to put it in front of services that don’t support HTTPS or don’t support the most modern, latest versions of SSL and TLS. So what you get from NGINX is the best and most advanced implementation of all encryption algorithms, and you don’t need to really think about the complexity of HTTPS, which is a good practice overall.
Also, if someone goes to visit a website, they like to see that happy little lock icon. In this example, it is nginx.com, which enables HTTPS and HSTS (I’ll discuss this feature later). You can no longer access with the normal HTTP version; Browsers know to always use HTTPS. The other thing you see here is that there’s a beautiful one NGINX, Inc and [US] This is shown to be an Extended Validation Certificate – essentially, this certificate indicates which company NGINX belongs to. They paid a little more for it, did some research and showed it on the certificate.
1.3 What are the disadvantages of HTTPS?
- The complexity of operational operations
- Additional latency (2 more round trips for the first connection)
- CPU consumption
But HTTPS is not perfect; There are also some drawbacks. Specifically, there is a bit of operational complexity. You have to manage certificates, and you have to make sure they are constantly updated. You need a trusted administrator to save the private key.
When you connect to a website over HTTPS, it may be slower the first time; If your physical distance isn’t necessarily close, then in addition to the TCP handshake, there’s the SSL handshake, which, as I mentioned, adds at least two round trips. As a result, latency suffers slightly, but this can be mitigated by some of the more advanced features of SSL, such as SPDY and HTTP/2, which are not covered in detail in this article.
Eventually HTTPS can be as fast as HTTP, but sometimes it isn’t. There is also the cost of encryption on your server; This is a reason why HTTPS has not been used for a long time, but it is increasingly not applicable. The latest generation of Intel servers can complete the encryption required for HTTPS very quickly and at almost no cost. So, in modern hardware, encrypting data in transit is basically free.
1.4 What do you need to do for HTTPS?
- A range of SSL/TLS protocols supported
- A range of cipher suites preferred to use
- Private keys and certificates signed by a trusted certificate authority (CA).
If you want to set up HTTPS for your service or website, you need to make some choices and get something. The first “decision” is the protocol you want to support, the second “decision” is the cipher you want to support (more on what this means later), and the “you need to get” certificate and corresponding private key. This is an important part that is “issued” by a third-party certificate authority trusted by the customer. I’ll get to that later, but first let’s talk about protocol versions.
Protocol Versions
To recap, HTTPS is HTTP plus S, and S is changing all the time; It has evolved over time. Originally, SSL v1.0 was a protocol invented by Netscape. There is a famous anecdote that when Marc Andreessen was giving a lecture at MIT, someone in the audience described with a pencil how to crack a cryptographic algorithm.
So, the SSL TLS encryption protocol doesn’t actually have a long history, 1995 Netscape SSL v2.0 was released, which was also the beginning of web encryption. This allows people in the e-commerce world to submit passwords and credit cards online and at least be fairly secure.
2.1 HTTPS Historical Background
2.2 Client Compatibility
2.3 Configuration Options and Scoring
Cipher Suites
Now let’s get into the cipher suite. What is a cipher suite? SSL, TLS, and HTTPS use various cryptographic algorithms to establish a connection, which is effectively a pool of letters. What do they mean?
A cipher suite is a complex string that describes the type of encryption used, defined by OpenSSL (which can be passed openssl ciphers
View your cipher suite).
Examples are as follows:
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:RSA-PSK-AES256-GCM-SHA384:DHE-PSK-AES256-GCM-SHA384:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:AES256-GCM-SHA384:PSK-AES256-GCM-SHA384:PSK-CHACHA20-POLY1305:RSA-PSK-AES128-GCM-SHA256:DHE-PSK-AES128-GCM-SHA256:AES128-GCM-SHA256:PSK-AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:ECDHE-PSK-AES256-CBC-SHA384:ECDHE-PSK-AES256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:RSA-PSK-AES256-CBC-SHA384:DHE-PSK-AES256-CBC-SHA384:RSA-PSK-AES256-CBC-SHA:DHE-PSK-AES256-CBC-SHA:AES256-SHA:PSK-AES256-CBC-SHA384:PSK-AES256-CBC-SHA:ECDHE-PSK-AES128-CBC-SHA256:ECDHE-PSK-AES128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:RSA-PSK-AES128-CBC-SHA256:DHE-PSK-AES128-CBC-SHA256:RSA-PSK-AES128-CBC-SHA:DHE-PSK-AES128-CBC-SHA:AES128-SHA:PSK-AES128-CBC-SHA256:PSK-AES128-CBC-SHA
3.1 Cipher Suite Disassembly
Essentially, the first term is:Key exchange, that is, the algorithm used by the two parties to exchange keys. In the case shown above, it is based on the Diffie-Hellman algorithm.
The second term is yoursThe key type in the certificate。 Because each certificate has a specific type of public key. Here is RSA.
The third part is yoursTransfer password, the encryption algorithm used to encrypt all data. There are many different parts of this, but AES-GCM is the most secure password; This is actually something that Intel processors do at almost zero cost. So it’s a pretty cheap and reliable password to use.
The last point iscompleteness。 As I mentioned, messages have a cache to make sure they haven’t been tampered with, but if it’s encrypted and has integrity, you can verify it from there.
3.2 Server Cipher Suites
- Clients list the supported cipher suites in order of preference
- Server Acceptance: The intersection of the client list and the server-supported password list
- The server selects the ones that are left over that it is preferred more like
Now, not all browsers and servers support the same list of passwords. This is calledProtocol flexibility, essentially what the server does: The client says, “Hey, that’s all I support”. The server said, “Well, I know five of them. I’ll pick my favorite.”
3.3 Cipher Suite Negotiation
So, as shown in the figure above, if the client says, “I support these on the left in turn,” and the server only supports two, then it will choose what it likes.
3.4 Recommended cipher suites
It’s not a big issue to argue about, but you have a lot of options. CloudFlare uses this list of cipher suites that you can find in GitHub hereFind it. There is an NGINX configuration format, and these are recommended by CloudFlare. These are the ones that all websites on CloudFlare will eventually use.
1 |
|
There’s a cool new password called ChaCha 20. It is not yet supported in the mainline NGINX, everything else can be used. Mozilla also has its own advice in this regard, which you can visitTheir server-side TLS site, they will generate the SSL configuration for you for NGINX or any web server you might use. This is a cipher suite. The resulting example is as follows:
1 |
|
4. Certificates
Now we have the protocol set and the cipher set; Next is the certificate. This is the most important part of HTTPS. This is a sign that identifies you as a site in front of customers. But what’s in the certificate?
4.1 What’s in the certificate?
- Organization name
- Public Key
- Issuer name
- Permissions
- expiration date
- Domain names (Hostnames)
- Digital signature by issuer
These include your name (who you are), which domain names your site applies to, when the certificate is valid, the public key (customers can use it to verify anything you sign with it), and then the digital signature. A digital signature is a stamp from a public certificate authority that indicates that it is a genuine certificate: the person actually owns the DNS name and is valid at these points.
4.2 What is a Certificate of Credit?
So, what makes a certificate trustworthy? This is currently the classification of all Certificate Authorities (CAs) on the Internet, and most certificates are signed by these authorities. Here are some common names. Symantec has purchased several such certificate authorities, including GeoTrust, Verisign, and others.
These are large trusted companies and, above all, their certificates are trusted by the browser. So, if Symantec indicates that the certificate is good through the process of someone buying it from them, then the browser will display a green lock.
4.3 How do I get a certificate?
You can obtain a certificate by creating a private key or a pair of keys, and then send your public key to a certificate authority, converting it into a certificate by verifying the seal. This usually costs some money (there are free methods), but essentially the private key you have to keep private,The only entities that deserve it are your administrator and your web server itself。
4.4 How do I create a CSR (Certificate Signing Request) and private key?
There are several ways to create these key pairs. A CSR is essentially a way to package a public key into a certificate authority to create a certificate. There are many ways such as OpenSSL, CFSSL, etc.
Using OpenSSL:
1 |
|
4.5 How do I get a free certificate?
If you want a free one, the most well-known sites at the moment are: Let’s Encrypt - Free SSL/TLS Certificate (letsencrypt.org)。 They will give you a certificate for a free website. Over time, it seems that the cost of obtaining a certificate will be lower. There are also recommendations from free certificate authorities. So now, you can pay to use sites like Comodo or DigiCert, or you can opt for the free route.
4.6 Certificate Chain
Certificates are not signed directly by a certificate authority; It’s a chain of trust that has been built. If you have a certificate, it is usually signed by an intermediate certificate authority that is signed by a real certificate authority.
In this case, not all browsers have to know what the next certificate in the chain is, and browsers are actually only bound to the top (true offline root certificate). Therefore, when you get a certificate, you also need to have the entire chain of trust.
Usually the CA will give you this certificate chain, and you can create it through some tools if the CA does not give you a certificate chain.