Bo2SS

Continuation: Information Security | How to Establish Trust in the Internet Age?

---Extra---

Related Technologies#

SSL/TLS#

To address the security issues of transmitting information in plain text over HTTP, HTTPS introduces the SSL/TLS (Secure Sockets Layer / Transport Layer Security) security protocol to enable encrypted transmission of information.

Let's take a look at the development history of SSL/TLS:

In fact, SSL is the predecessor of TLS.

SSL was designed by Netscape Communications Corporation. After SSL 3.0, Netscape handed SSL over to the IETF (Internet Engineering Task Force), which standardized SSL and released TLS 1.0 (= SSL 3.1), incorporating it into RFC (Request for Comments), which is a standard document that records Internet specifications, protocols, procedures, etc. Through updates and iterations, only versions 1.2 and 1.3 of TLS are currently in use (as of May 2022).

PS: Why isn't SSL 1.0 seen in the diagram? Because it had significant security vulnerabilities and was never publicly released.

References:

• SSL/TLS History and Frontier Overview - Blog

• Differences Between SSL/TLS Protocol Versions - Anxin SSL

Let's briefly look at the TLS handshake process (the left side shows the process of one-way authentication, and the right side shows the process of mutual authentication):

As we can see:

1. The TLS handshake occurs after establishing a TCP connection.

2. In the process of mutual authentication, the client also sends its certificate to the server.

3. After the ChangeCipherSpec, the information is encrypted and transmitted.

The entire TLS handshake process mainly involves steps such as exchanging certificates and keys. For the specific principles, I recommend some good resources here~

You can explore the following resources with two questions in mind: 1) Is the ClientHello message just a simple "Hello"? 2) How is the key used for encrypted transmission of information generated? (The answers will be revealed in the "Practical Part > WireShark," and I highly recommend using the network packet analysis tool WireShark to deepen your understanding of the TLS handshake process.)

• Video: SSL/TLS Handshake Process - Bilibili

• Articles

  • An Overview of the SSL/TLS Protocol Operation Mechanism - Ruanyifeng

  • HTTPS - Decrypting the Complete TLS 1.2 Handshake Process - 51CTO

  • HTTPS RSA Handshake Analysis - Xiaolin Coding

  • HTTPS ECDHE Handshake Analysis - Xiaolin Coding

Tips: From Xiaolin Coding's articles, you can see that the process in the diagram is not absolute because different key exchange algorithms (RSA, ECDHE, etc.) have different processes. For example, in the process of key exchange based on RSA, there is no ServerKeyExchange message.

SSH#

SSH (Secure Shell) is also a network security protocol, which is also developed by the IETF. However, it is an application-layer protocol based on TLS (which operates between the transport layer and the application layer) and achieves secure access, file transfer, and other services through encryption and authentication mechanisms. If you frequently use cloud servers or GitHub, you must be familiar with it~

The establishment process of an SSH connection can be divided into three steps:

1. Client Authenticates the Server

When you first SSH into a cloud server, you may have seen the following image:

The client receives some information from the cloud server, and the key is the "fingerprint" (the SHA-256 value of the public key in the ECDSA signature algorithm). We can obtain the server's real public key by using ssh-keyscan -t ECDSA -p 22 [host] > key.pub, and then calculate its SHA256 value by using ssh-keygen -E sha256 -lf key.pub to compare it with the "fingerprint" in the image. If they match, the connection can be established.

As you can see, this verification process is controlled by the client. The client can choose not to perform any comparison and directly trust the connection, but this carries risks.

2. Generating a Key for Encrypted Transmission of Information (through Key Exchange Algorithms), and all subsequent communication is encrypted

3. Server Authenticates the Client (in two ways)

a. Client does not upload a public key: The server will provide the client with a public key. The client uses this public key to encrypt user information (such as a password) and sends it to the server. After successful verification by the server, the connection is established.

b. Client has uploaded a public key to the server in advance: The server uses this public key to encrypt a random number and sends it to the client. The client decrypts it using the corresponding private key and sends it back to the server. After successful verification by the server, the connection is established.

Reference: SSH Public Key Authentication - Juejin

iOS Code Signing#

From the diagram, we can see that iOS code signing is actually a complex process that cannot be fully described in a few words.

Here, you only need to know about two essential files in iOS code signing:

1. .mobileprovision file: Also known as the PP file (Provisioning Profile), it can be understood as an upgraded version of a certificate. It contains not only one or more iOS developer certificates but also various other information.

2. .p12 file: It consists of a developer certificate and its corresponding private key. In relation to steps 2 and 4 in the diagram, Xcode searches for certificates belonging to the certificate collection in the PP file in the Keychain, extracts the private key, and signs the app with it during the packaging process.

For a detailed explanation, you can refer to my previous article: iOS | The Principles Behind iOS Code Signing. This article is also the source of this text.

Remember, if you encounter any issues related to iOS code signing and packaging, start with these two files~

Some Practices#

Finally, let me introduce two excellent practice tools to reinforce today's content.

OpenSSL#

OpenSSL is an open-source cryptographic toolkit. You can use the following script to review the algorithms we learned today.

# Generate private key (RSA)
openssl genrsa -out private.pem
# Generate public key from private key
openssl rsa -in private.pem -pubout -out pubkey.pem

echo "hello, world" > test.txt
# Encrypt
openssl rsautl -encrypt -pubin -inkey pubkey.pem -in test.txt -out test.enc
# Decrypt
openssl rsautl -decrypt -inkey private.pem -in test.enc -out test.dec

# Signature (hash:SHA-256)
## Generate
openssl dgst -sign private.pem -sha256 -out test.sig test.txt
## Verify
openssl dgst -verify pubkey.pem -sha256 -signature test.sig test.txt

# View Key as text
## Private key
openssl rsa -in private.pem -noout -text
## Public key
openssl rsa -pubin -in pubkey.pem -noout -text

# Generate a self-signed certificate
# {Creating a Self-Signed Certificate With OpenSSL——Baeldung}
...

References:

• openssl - Linux Command Encyclopedia

• Creating a Self-Signed Certificate With OpenSSL - Baeldung

WireShark#

WireShark is an open-source network packet analysis tool. Use it to explore various network protocols in depth~

Next, let's review the questions raised in the "Related Technologies > SSL/TLS" section:

1. Is the ClientHello message just a simple "Hello"?

2. How is the key used for encrypted transmission of information generated?

Now, open WireShark and apply a simple filter to the captured network packets, such as ip.addr == 115.236.119.85 && tls.

As you can see, the ClientHello message contains a lot of information, including the TLS version, random number (used for key exchange algorithms), and 21 supported cipher suites (from which the server can choose a key exchange algorithm). This answers the first question.

Continuing to analyze each message, we will find that in the ServerHello message, the server selects a key exchange algorithm, and the key used for encrypted transmission of information is generated through this algorithm. This answers the second question.

There is much more detail waiting for you to explore with WireShark~

---End of Extra---