Today I learned how TLS (based on RSA) works. Without entering the core mathematics of cryptography, there are several things you need to know in order to understand how and why common authentication and encryption types work.
Let’s start inside-out. Nowadays it is recommended to encrypt almost any type of data. Whether it is in the hard drive itself, and especially if it goes through the network. It is so important that even the CIS recommended using TLS for Kubernetes internal communication. Describing How Encryption works is too big for this page but it has these properties:
1. The sending side applies an agreed function with encryption key input on its data
2. Any middle man, that might have access to the encrypted data and does not have the decryption key, cannot read the actual data.
3. The receiver side can activate the decryption function with a decryption key and read the data as-is without loss/changes from the original one.
Did you notice the key problem? if the sender and receiver agree on the encryption function and keys- everything is much easier. (for example, mobile communication works that way since the operator passes you a hardware component called a SIM card with these predefined keys). But you cannot do that for every service that exists on the internet.
The solution? Public-key encryption schemes. These authentication methods consist of a known encryption function and a public key provided by the receiver that can only be decrypted using a private key that only the receiver side has. It is similar to giving every client a lock, where the key exists only in the server have.
But wait! There is another problem. How can I trust the server to be who it claims to be? I’ll explain it in 3 steps:
- The slient sends an hello message and it negitiate with the server about the encryption type.
- The server sends to the client it’s certificate (containing its public key) and a small data enceypted with the private key. since also the public key can decrypt data encrypted with the private one, we can make sure the server have the privare key matching the supplied public one.
- After we validate we can initiate an ecrtypted session, we now need to validate that the certificate is a real one, and not spoffed by a middle man. For that we got a Certificate Authority, a predefined known entity we trust. The client send the received certificate and validate its authenticy.
If we are talking about SSH connection, this needs only the 2nd step. As in keyed-SSH authentication is done by explicitly putting the allowed public key in the server. One that can prove it has the pair-private key is allowed to the server.
Now that we trust the other side and matched encryption keys and algorithms it is safe to transfer data that no man-in-the-middle can understand.