Bo2SS

Main Article: 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), and included it in RFC (a standard document that records Internet specifications, protocols, processes, etc.). Through updates and iterations, only versions 1.2 and 1.3 of TLS are currently in use (as of May 2022).

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

References:

• SSL/TLS History and Frontiers - Blog

• Differences Between SSL/TLS Protocol Versions - Anxin Certificate

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

We can see that:

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

2. In the two-way authentication process, 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 more details on the specific principles, I recommend some good resources here:

You can explore the following resources with two questions in mind: 1) Is the ClientHello simply saying "Hello"? 2) How is the key used for encrypted transmission of information generated? (The answers will be revealed in the "Practice > WireShark" section, 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 - 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, we can see that the process in the diagram is not absolute because different key exchange algorithms (RSA, ECDHE, etc.) have different processes. For example, the process based on the RSA key exchange algorithm does not include the 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 (TLS operates between the transport layer and the application layer), and it 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 3 steps:

1. Client verifies 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 here 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, and compare it with the "fingerprint" in the image. If they match, then decide to establish the connection.

As we can see, this verification process is controlled by the client. The client can choose to trust the connection without any comparison, but this carries risks.

2. Generation of the key for encrypted transmission of information (through key exchange algorithms), subsequent communication is encrypted

3. Server verifies the client (2 methods)

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

b. Client uploads 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, we 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 the developer certificate and the 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 detailed explanations, you can refer to my previous article: iOS | The Principles Behind iOS Code Signing. This article is also the source of this content.

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. You can use it to gain a deeper understanding of various network protocols.

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

1. Is the ClientHello simply saying "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 we can see, the ClientHello contains a lot of information, including the TLS version, random number (used for key exchange algorithms), and support for 21 encryption suites (from which the server can choose a key exchange algorithm). This answers the first question.

By analyzing each subsequent message, we will also find that in the ServerHello, the server selects a key exchange algorithm and generates the key used for encrypted transmission of information. This answers the second question.

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

---End of Extra---