This article mainly wants to talk about one topic - authentication. That is, how to confirm that this data is sent by this person?

User Password

To solve this problem, let’s look at one of the simplest solutions - the use of passwords. Usually, to prove a person’s identity on the Internet, something private and unique about that person is needed. For example, in many places, if you provide your user name + password, you can be sure that the person is you (note: password management, strong password settings, password leaks, password cracking and password cajoling are not in this article), that is, the password is a very private matter, we can assume that only one person in the world knows this matter, so We can assume that only one person in the world can know the password, so that when the person has provided the correct password, we can authenticate the person.

To enhance the security of passwords, generally 2FA (Two-factor authentication) or MFA (Multi-factor authentication), two-factor authentication or multi-factor authentication is used, which requires the user to provide a unique trusted device, such as the user’s cell phone, and then authenticate the user by verifying the cell phone SMS, or like Google Authenticator to complete the dynamic password. This is already a high level of security. It would be better if the password could be changed frequently.

In addition, some companies use biometric passwords for user authentication, such as face recognition. However, I personally feel that face recognition or biometrics is the worse way to go because.

  • Biometric information that can currently be verified (such as faces and fingerprints) is too easy for someone to obtain and forge.
  • Such things cannot be changed and revoked, passwords can be revoked and reset, faces cannot.

key pairs and certificates

Passwords can solve the problem of identity authentication has many problems, the most important one is that you have to provide your password to the other party, the other party to verify your identity. You can’t provide your password to the whole world, right? In this case, the whole world has your password, then anyone can become you. So, the user password thing can only exist between the authority and the ordinary user, not in the universal application. So, a better solution needs to be used here.

Using ECC (Elliptic-Curve Cryptography) elliptic curve cryptography, you can use a “key pair " for asymmetric encryption. This technique, when encrypting and decrypting a message, uses two different keys, one of which is used for encryption and the other for decryption. In this way, we can publish one of the keys, called the public key, and keep the other key private, called the private key.

For example, I use my private key to encrypt a message, and then I publish the public key paired with this private key to everyone, and everyone uses the public key to decrypt the message, and you cannot decrypt the message without my public key. In this way, we can ensure that the information is sent by me, which not only ensures the security of information, but also completes the identity authentication.

image

Such a real-life case is usually used for websites, that is, the user needs to know that the website I visit is real and not made by someone else. Because DNS can be easily hacked, if you connect to an untrusted network, the DNS in that network will resolve the IP address of the website to whatever it is. But with this encryption mechanism, the website encrypts its information and gives it to the visitor with the public key, and then you can know if it is the website after visiting and decrypting it.

However, there is still a very serious problem here, that is, man-in-the-middle attack. As shown in the figure below.

image

Chad, the middleman, disguises himself as Bob to ask Alice for information, and then, disguised as Alice, says to Bob that this is Alice’s public key, so Bob can’t verify if it’s Alice’s public key, because the public key is a bunch of messy data, and we can’t tell which public key belongs to Alice. Think about it, if we receive a key that claims to belong to a bank. How do we know it really belongs to your bank?

The answer here is using a digital certificate. A certificate is very similar to our ID card in that it needs to be issued and verified by a trusted authority. The CA (Certificate Authority) is an authority that everyone trusts with their integrity (which is of course strictly managed and audited), and the CA also uses such asymmetric encryption technology to do the issuing and verification. The diagram below illustrates the process.

image

To illustrate the above diagram.

  1. In order to solve the problem of public key authentication, we need an authoritative CA organization.
  2. Alice packages her information (name, organization, address, email, URL, etc.) and her public key into a CSR file and sends it to the CA.
  3. the CA will come to Alice for physical world authentication, and if it passes, it will use its own private key to turn the CSR into a signed certificate.
  4. Bob gets Alice’s certificate, decrypts it with the CA’s public key, and gets Alice’s public key.
  5. then you can verify whether the message is from Alice.

Yes, this process is in the “nesting”, this certificate authority can also issue certificates to the lower level of the certificate authority, so it will be layer upon layer, forming a certificate chain, the top level is called the root certificate, you have to absolutely trust it. For the client to verify the authenticity of the certificate, it needs to be able to verify the signatures of all CAs in the chain, which means that the client needs to access the certificates of all CAs in the chain.

Certificate generation process demonstration

Not all scenarios require applying for public key certificates from these large CAs, but any enterprise, organization or group can form its own “small kingdom”, that is, you can generate such certificates yourself, only you need to secure your own private key to generate the certificate and not to spread it to the the entire Internet. Let’s use the openssl command to demonstrate this process.

  1. Generate the CA certificate (public key) ca.crt and the private key ca.key
1
2
3
4
5
6

openssl req -newkey rsa:2048 \
    -new -nodes -x509 \
    -days 365 \
    -out ca.crt \
    -keyout ca.key \
    -subj "/C=SO/ST=Earth/L=Mountain/O=CoolShell/OU=HQ/CN=localhost"
  1. Generate alice’s private key
1

openssl genrsa -out alice.key 2048
  1. Generate Alice’s CSR - Certificate Signing Request
1
2

openssl req -new -key alice.key 365 -out alice.csr \
    -subj "/C=CN/ST=Beijing/L=Haidian/O=CoolShell/OU=Test/CN=localhost.alice"
  1. Use a CA to sign a certificate for Alice
1
2
3
4
5

openssl x509  -req -in alice.csr \
    -extfile <(printf "subjectAltName=DNS:localhost.alice") \ 
    -CA ca.crt -CAkey ca.key  \
    -days 365 -sha256 -CAcreateserial \
    -out alice.crt

Two-way authentication mTLS

Above, we are talking about basically one-way authentication, a large number of scenarios are to ensure that the user side is accessing the real service side, such as: banks, e-commerce sites, etc.. This ensures that users are not attacked by phishing sites or man-in-the-middle. However, in many cases, we also need two-way authentication. Here is a typical scenario - interaction between WeChat Pay and a merchant

  • A user goes to a merchant to buy something and the merchant asks the user to make a payment.
  • The user chooses WeChat Pay, so the interface cuts from the merchant side to the WeChat side
  • After the payment is completed on the WeChat side, the merchant receives a notification that the payment is completed on the WeChat side and starts shipping.

One thing is very important in this process - it’s when WeChat notifies the merchant that the payment is complete.

  • WeChat has to make sure that the merchant that the user paid is the one that is notified and not someone else.
  • The merchant also has to be able to confirm that it is WeChat that is not someone else that is notifying me.

Generally speaking, WeChat will give the merchant an AppID and an AppSerct, and use this to make sure it is my authenticated merchant to call me. Then, the merchant is required to fill in a callback URL in their own system, and do MD5/HMAC signature by the key set by the platform to make sure it is the official callback. These are all techniques mentioned in “The Art of HTTP API Authentication Authorization”, which are relatively traditional techniques.

Today, mTLS is the protocol of choice for securing communications between services in cloud-native applications. It is also known as two-way authentication.

The traditional TLS authentication process is.

  1. The client connects to the server
  2. The server provides its TLS certificate
  3. the client verifies the server’s certificate
  4. client and server exchange information over an encrypted TLS connection

In mTLS, both the client and the server have a certificate and both sides use their public/private key pairs for authentication. Compared to regular TLS, there are additional steps in mTLS to authenticate both parties (additional steps shown in bold).

  1. Client connects to the server
  2. Server provides its TLS certificate
  3. The client verifies the server’s certificate
  4. Client presents its TLS certificate
  5. The server verifies the client’s certificate
  6. The server grants access
  7. Client and server exchange information over an encrypted TLS connection

mTLS requires a “root” TLS certificate; we perform the certificate authority duties ourselves. The certificate that authorizes the client and server to use must correspond to this root certificate. The root certificate is self-signed, which means we need to create it ourselves. (Note: This method does not apply to one-way TLS on the public Internet, since external certificate authorities must issue these certificates)

So why not upgrade to mTLS when the entire Internet already uses TLS?

  • The problem to be solved on the public Internet is to A) ensure that users are visiting the right website and not a phishing website. B) the content transmitted by the website is secure and private and will not be tampered with.
  • Distributing TLS certificates to all end-user devices would be very difficult. Generating, managing and verifying the billions of certificates needed for this purpose would be an almost impossible task.

On a smaller scale, mTLS is useful and practical for individual organizations, especially if those organizations use a zero-trust approach to securing their networks. Since the zero-trust approach does not trust any user, device or request by default, organizations must be able to authenticate each user, device and request every time they try to access any point in the network. mTLS helps achieve this by authenticating users and verifying devices.