Understanding Information Security: From Superman's S to HTTPS
The Illusion of Safety
Hello, everyone. I'm Mr. Dan. Every time Superman takes off his clothes and shows his chest with that big "S", people feel a strange sense of security. Similarly, when people open a web page and see the little lock next to the URL, most assume they are safe online because the website uses HTTPS. While the "S" in HTTPS means "secure" and Superman's "S" has a different meaning, both give a false sense of absolute safety. In reality, the small lock and Superman's "S" are just logos. HTTPS has its weaknesses, much like Superman has his kryptonite.
Symmetrical Encryption and Its Challenges
To understand information security weaknesses, we need to address three core problems. Consider the King of the Golden Angles and the King of the Silver Angles who are not in the same cave and need to communicate via flying song transmission. To prevent others from knowing their call contents, they use letters, boxes, and locks. Only they have the same box key. This is symmetrical encryption, where the two keys (private keys) are shared between them.
However, a major problem arises. The two must meet to determine the key. If only one has two private keys and tries to send the other key to the partner, it's likely to be intercepted. What if they can't meet? How can they send the "poison" (information) safely?
Secret Key Exchange
King Jingjiao comes up with a solution. He puts two pairs of magnetized "poison" in a box and locks it with his golden key. He sends it to King Yingjiao. After receiving it, King Yingjiao locks the box with his silver key and sends it back to King Jingjiao. King Jingjiao then uses his golden key to open the golden lock and sends the remaining locked box to King Yingjiao. King Yingjiao uses his silver key to open the box and gets one of King Jingjiao's two pairs of symmetrical encryption private keys. Since the gold and silver keys are their own, they successfully share the encrypted private key. This is secret key exchange.
While they can communicate using this method, it's time-consuming and labor-intensive. For computers transmitting files, this would be inefficient. So, this method is often used for encrypting and negotiating symmetry, as the size of a general secret key is relatively small compared to documents. After both parties negotiate the private key symmetry, they use symmetrical encryption for normal communication.
Asymmetric Encryption and Hash Calculation
But there's another problem. If someone intercepts the locked box in the middle, they can change the box lock and the letter content, making it impossible to determine who is communicating. To solve this, King Jingjiao creates two corresponding keys: a public key and a private key. The public key is public, and the private key is kept secret. The amazing thing is that only the public key can open what the private key has locked (private key for encryption, public key for decryption).
King Jingjiao makes many public keys and sends them out. To deal with the letter content, he extracts all repeated words and marks them with numbers, getting a special line (hash value). He puts this special line in another box, locks it with his private key, and sends it along with the letter to King Jingjiao. After receiving the letter, King Jingjiao calculates the special line in the same way and uses the public key to open the box with King Jingjiao's special line. By comparing the two special lines, he can verify if the letter is from King Jingjiao and if the content has been modified. This hash calculation is a crucial part of ensuring data integrity.
The correct use of private and public keys is one of the asymmetric encryption methods. The core principle of HTTPS operation is to first exchange the secret key, then use symmetrical encryption for communication, and in the middle, use the hash method for verification.
TLS: The Protagonist of HTTPS
The "S" in HTTPS is operated by a separate protocol, TLS (Transport Layer Security). Although its predecessor is SSL (Secure Sockets Layer) and many still call it SSL, TLS is now quite different from SSL, especially after evolving from TLS 1.2 to TLS 1.3.
TLS 1.2 has two core algorithms: RSA and DH. In the RSA key exchange, the server has a public key and a private key. The public key is used for encryption, and only the private key can decrypt. The client receives the server's public key, encrypts the negotiation secret key with it, and sends it. The server uses its private key to get the secret key, and both parties exchange the unknown password.
In the DH key exchange, both parties have private keys and must provide their negotiation parameters to each other. After receiving the other party's parameters, they use their own private keys and the other party's parameters to calculate the same secret key. The DH algorithm is more secure as it generates different random numbers each time, increasing the difficulty of being broken. In contrast, the RSA algorithm, if used with static public and private keys, has a risk. If the private key is exposed and previous communication content has been intercepted, all previous content can be decoded. For this reason, static RSA and DH secret key exchange algorithms were removed from TLS 1.3.
Parameters and Password Suites in TLS
When using the non-static DH algorithm, the parameters in the DH algorithm are crucial. The difficulty of solving the DH algorithm lies in the "subtraction problem" (modular arithmetic). Larger parameters make it more difficult to reverse-engineer. However, some host devices may not support the new version of TLS or only support SSL. Although the TLS 1.2 protocol supports version downgrade, if the server configuration is incorrect or not upgraded in a timely manner, problems may occur. The parameters (P and G) in the DH algorithm are selected by the server, and not all combinations are safe.
In TLS 1.2, during the first two steps of the handshake, the client and server negotiate encryption details, including the algorithm to use. The password suite represents the agreement name, key exchange, verification, symmetrical encryption, mode, and hash. There are 37 different combinations defined by TLS 1.2, which can lead to confusion and inefficiency in negotiation.
In TLS 1.3, the password suite has been simplified to a five-type package, including the agreement name, symmetrical encryption, and hash. TLS 1.3 only supports three key exchange modes. The PSK-only mode is basically a symmetrical encryption method using a recommended fixed key. The other two modes involve DH algorithms, and the selectable parameters are much fewer in TLS 1.3. The client can send DH negotiation parameters at the beginning, improving performance.
Encryption Modes and Their Risks
There are different encryption modes. Group passwords like DS and AES are used. For example, if the data has 10 characters and the password has 4 characters, the data is divided into parts and encrypted. If there are remaining characters, padding is added. The CBC mode uses random numbers to make the encrypted output more random. However, hackers can use the server's response to guess the padding in the CBC mode, so it's no longer used in TLS 1.3.
RC4, a stream cipher, also has a loophole and has been removed. TLS 1.3 uses the AEAD encryption method. It first encrypts a string of numbers to get the hash value, then generates random numbers and performs encryption and transformation operations to get the ciphertext. For the server, it verifies first and then decrypts, making it difficult for hackers to guess.
Signature and Padding Issues
In TLS 1.2, when using RSA to exchange keys, the client generates a pre - master secret key after receiving the server's certificate. This key is used to generate the session key. The pre - master secret key is encrypted with the server's public key and sent. Due to the length difference between the pre - master secret key and the RSA public key, padding is required. The PKCS1 1.5 version of padding has a loophole that hackers can exploit. In TLS 1.3, it was changed to PSS padding, which uses more complex operations for encryption.
TLS Handshakes: 1.2 vs 1.3
Let's review the handshakes. In TLS 1.2, the client sends a "Client Hello" with its random number and supported password suites. The server chooses a password suite (e.g., DH for key exchange), generates its random number and DH negotiation parameters, encrypts them with the certificate, and sends the certificate and the encrypted data (number signature). The client decrypts the number signature with the certificate, verifies the server's identity, and sends its DH negotiation parameters. Both sides then generate the pre - master secret key, session key, and encrypt the formal content.
In TLS 1.3, since only the DH algorithm can be used for key exchange and the parameter group is limited, the client can directly generate DH negotiation parameters along with its random number at the beginning. The server also generates random numbers and DH negotiation parameters and sends them. The server can encrypt the certificate when sending it as it already has all the parameters to generate the key. The client can generate the key after receiving the server's parameters, verify the certificate and signature, and then encrypt the formal content.
This is the core content of understanding information security and the workings of HTTPS. See you next time.
{#