Demystifying ‘Secure’ in SSH/TLS/HTTPS

Meet Patel
Code Dementia
Published in
4 min readJul 15, 2020

Insecure connections would be the last thing we’d want nowadays. So how do the latest communication protocols manage to have them securely?

In whatever kind of WebApp or API, different requests have to be there. Before a request reaches the destination, it needs to go through some hops over routers/network devices in the path to server (use Traceroute to list these network devices that your requests go through). You never know who might be listening to your network calls. So the best and probably the only way to protect them is to encrypt all the communication, so that even if the listener gets access to our information, he can’t make much (or anything) out of it. We’ll not go that deep into encryption though, rather we’ll assume it just works as in principle it should and take a high level overview of its types and working.
P.S. : I recommend going slow as Asymmetric Encryption can be confusing.

Types of encryption:

1) Symmetric Encryption (a.k.a. Private Key encryption): Old, Fast
2) Asymmetric Encryption (a.k.a. Public Key encryption): Comparatively slow but has advantages

This classification is based on the encryption/decryption keys used to encrypt/decrypt the information.

Symmetric encryption uses only single key — used to both encrypt as well as decrypt both using that same single key. This is also known as Private Key encryption as the key is shared between both and only the sender and receiver and is kept private. Both the persons have to make sure that it is only them who has the key and no-one else. This also happens to be the weakness of the method, as before the secure communication happens, you have to have made sure that the key is securely exchanged which cannot be ensured without being compromised over the network.

Credits: https://www.clickssl.net/blog/symmetric-encryption-vs-asymmetric-encryption
Symmetric Encryption — Image Credits: https://www.clickssl.net/

Asymmetric encryption uses two keys — only one of them can encrypt and only the other one can decrypt the data. One of the keys is called Public key and the other is Private key. The Public key designated to encrypt can only perform encryption, and the other (Private key) can only decrypt and can’t encrypt.

Image Credits: https://www.clickssl.net/blog/symmetric-encryption-vs-asymmetric-encryption
Asymmetric Encryption —Image Credits: https://www.clickssl.net/

So, the flow is like: Person1 has his own key-pair(Public+Private keys) and Person2 has his own key-pair (Public+Private keys). Public key, as the name suggests, is shared with the other person and Private key is strictly kept private. When P1 wants to send P2 a message, P1 encrypts the message using P2’s Public key. Now, this message can be decrypted ONLY using the paired Private key, to which ONLY P2 has access. Hence, P2 receives the message that’s supposed to be for him — decrypts it — and reads it. So even if someone other than P2 can access the message, he can’t make sense out of it as it is encrypted.
Similarly, if P2 wants to send P1 a message, P2 would encrypt the message using P1’s Public key, which in turn can only be decrypted by P1 using P1’s Private key. Interesting thing to note is, even if P2 has encrypted the message and has access to unencrypted form; he won’t be able to reverse engineer the encrypted message or make sense out of it (however he does have access to original message nonetheless).

Hence the biggest weakness of the Symmetric encryption, i.e. initial secure private key exchange, is solved by Asymmetric as only the person who is supposed to receive the message can decrypt and make sense out of it. Even the sender who encrypted the message can’t decrypt it.

These methods ensure that even if there is a man-in-the-middle of you and the remote machine, he won’t be able to decrypt the message and essentially making his efforts worthless. There are numerous encryption algorithms by which we can generate the keys or key-pairs and handle encryption/decryption operations. These are the methods that guarantee the secure term in protocols like HTTPS, SSH, SSL (replaced by TLS today), PGP and so on. These protocols use above mentioned encryption methods in their own way. Some of the good resources to know more on them are linked below.

Next Steps

To know how Secure Shell (SSH) uses these methods: https://youtu.be/qWKK_PNHnnA . If you’re not aware of what SSH is, it’s essentially used to connect to a remote machine and gain access over it to execute our desired commands remotely and securely. In fact, you can access my Public Key at https://github.com/meet59patel.keys ; adding the key to your machine would grant me access to it. There are numerous other amazing use cases of SSH though.

For detailed explanation on how ‘TLS Handshake’ is done to ensure secure HTTP connection: https://youtu.be/cuR05y_2Gxc

A new buzz term DNS over HTTPS also utilizes these methods only. Briefly, it is a way by which your ISP can’t know what domains you are accessing. Without this, although ISP is not able to read/decrypt your messages, he can know what domain/IP you are requesting.

It is worth noting that, these encryption methods must not be confused with how passwords are stored securely using hashing and salting.

A good resource to read more on such topics is: https://www.cloudflare.com/learning/ .

Thanks for reading!

--

--