Read on to not only learn about how TLS works to protect one’s data from prying eyes, but also why one might consider taking encryption into their own hands in certain use cases.

Regarding Encryption:

A fundamental consideration for data security is encryption. For many of us out there, perhaps we have pondered the implications of encrypting our data, deeming it necessary in order to maintain the integrity of our information while offering protection from the prying eyes of bad actors. Indeed, using strong and well-established encryption algorithms to safeguard our private data is such a powerful tool that most hackers figure it would be far easier to resort to utilizing common social engineering practices, that is, preying on human emotions or their proclivities, in an attempt to squeeze as much sensitive data out of unsuspecting users as possible. Thus, most modern algorithms and ciphers are so strong, like the standard AES-256 bit encryption, that such methods often lead hackers towards working around encryption rather than against it.

Even still, best security practices are not always adhered to when it comes to protecting data at rest. While most internet traffic is encrypted in transit using Transport Layer Security (TLS – more on that later), encrypting data at rest typically ends up being the server’s responsibility. For example, when you use a password with, say, a company like Google, you are at the mercy of their security practices when it comes to hashing your password, or storing it in an encrypted state in their cloud servers. Now for Google, this is most likely not a concern as they are a tech giant responsible for billions of users’ data. That said, perhaps it is no surprise that encryption is not always at the forefront of every company’s agenda. Storing passwords in plaintext (unencrypted), for instance, is not a rare occurrence and is heavily frowned upon in the cybersecurity industry. And for good reason. Should a breach occur, all that data is as good as compromised. This is why solid incident response and any subsequent remediation practices are imperative for such occurrences as they can mitigate the negative impact of data leaks as much as possible.

Accessing Data Securely:

So how can you protect yourself from a company’s bad encryption practices? There are a few methods you as a security-conscious user can do to minimize the overall attack surface should you find your data in a precarious position, but the truth of the matter is that if you want to use an organization’s services, you have to accept how your data is shared or stored with them. The first order of business is to conduct due diligence on how a company handles your data. How much of the data can they see? What do they do once you share that data with them? Some of this info can be found in their privacy/data policies, but you can also refer to security audits or testimonies from third-parties to help cross-check the validity of what a company claims. At the end of the day, one question remains: do you trust that company with your data? Only you know the answer to that, and it may be dependent on your own needs or what risks you are willing to part with for the sake of certain features, like ones that provide increased convenience to you.

VPNs and TLS:

You could also decide to keep most of your personal data on you at all times and only access it locally. This maximizes security at the cost of convenience. To access your information remotely, you will need to take a look at protocols that help encrypt traffic in transit. One of the most common ways is through a VPN. I talk about this subject in more detail here, but the gist is that VPNs are a great way to access data securely as they typically authenticate using a secret only known by each device enrolled in the VPN. I should add that I am not referring to VPN vendors like NordVPN or ExpressVPN (or even the VPS server article I wrote prior to this one), but rather a local VPN server you yourself set up to connect to your information as if you were doing so from your home’s local network. Some VPNs require a little bit of research or known-how to get working, like OpenVPN or WireGuard. Some routers also advertise having built-in VPN functionality, which might be a boon for some. There are even VPNs, like the aforementioned OpenVPN, that encrypt your traffic based on the TLS protocol, the very one that allows you to send data securely to web services across the internet, whether it be YouTube or your bank’s website.

TLS, or Transport Layer Security (formerly known as SSL), is a transport layer protocol that creates an encrypted connection using what is known as asymmetric cryptography. “Asymmetric” in this case means that there are two keys, a public and private one, that work in conjunction with one another to encrypt traffic when a session is established. Public key cryptography is a complicated process, and we should definitely thank those like Whitfield Diffie and Martin Hellman, who devised a common means of exchanging keys over insecure channels to establish private connections. For now, just know that information encrypted with a public key can only be decrypted with the matching private key. Let’s see this process in action with TLS. It performs its key exchange through the process of a “three-way handshake” which all TCP/IP connections use, described in an abridged format below.

TLS in a Nutshell:

1. The client sends a “hello” message to the server as if to say, “I’d like to establish a connection with you.”
2. The server replies, saying “Oh, hi. I see you, here is a personal certificate that proves I am the webserver you are seeking. I also have a public key that I am giving out to everyone who visits me, so please take that as well.” The server also has a private key that corresponds to the public one it just handed out, but it stays hidden from everyone to avoid compromise.
3. The client verifies the certificate. Assuming everything is in order, i.e. proper domain name, issue date still valid, etc., the client takes the public key and generates its own private key. Because this key is only valid for the session, it is now deemed the “session token”. The client finally acknowledges the connection by encrypting its session token with the public key and sending it back to the server.

Now the magic happens. The connection we established with asymmetric cryptography moves into its last stage where the server takes the encrypted session key and decrypts it with the only key that can do so: its private key. At this point, the server knows it’s in possession of the session token and can freely encrypt or decrypt traffic sent by the client that generated the key in the first place using symmetric cryptography. In other words, both the client and server have a shared secret in the form of the session token, where the symmetry comes from, and can use this to send secure traffic to one another for the full duration of the session itself. In essence, this prevents hackers from viewing the traffic by:

1. Having the server send a public key, which anyone can know. It does not matter if this is intercepted by an attacker.
2. Generating a private key client-side and encrypting it with the public key. Attackers cannot decrypt this info without the server’s private key, which they do not have.
3. Session key gets decrypted server-side and used symmetrically for the rest of the session.

The above method is how you securely send data to servers on a daily basis. However, it should be noted that TLS is not impervious to attacks or workarounds, as noted by certain cyber attacks such as Man-in-the-Middle, Phishing, or Session Hijacks.

As a side note, if you expose certain services to the internet or want to create strict zero trust network policies, TLS has a built-in function that enables clients to also use certificates. This is called mTLS, and you can provide these certs to your client so that it can authenticate itself to your own servers. That said, mTLS is not very scalable in this manner, and is practically useless for servers intended to be truly public-facing. This is designed more for exposing services to very few clients, or allowing internal servers to only trust each other and no one else.

How to Further Protect Ourselves:

Aside from relying on the internet’s built-in protocols to protect data, there are extra steps we can use depending on our desired level of security:

1. Implement End-to-End Encryption Wherever Possible:

Several companies are starting to introduce true end-to-end encryption, where your client sends messages to the target client or server directly, preventing data from potentially being intercepted in an unencrypted format. You may have experienced this firsthand with Google using RCS encryption on their messaging apps.

2. Manually Encrypt Data at Rest:

Do not trust the encryption practices of a cloud provider? Encrypt the data yourself before sending it over! There are multiple software-based solutions that allow one to encrypt using algorithms like AES 256 locally. One of which I am personally fond of is Cryptomator, which is an open-source software that allows you to encrypt info wherever you like, whether it be in the cloud or otherwise. Once encrypted, the data is stored in a location you designate. Veracrypt can be an alternative if you are attempting to encrypt larger, containerized sets of data in one go.

I personally use this method for cloud providers that offer encryption yet hold the “keys to the kingdom”, meaning they could theoretically decrypt the info at any time or inadvertently enable a bad actor to do so instead, albeit this can be a rare occurrence. Well-established companies offering “Zero-Knowledge” encryption practices is also another option in this manner.

To summarize, there are many facets to handling data that ultimately boils down to what risk you are willing to take on, or what countermeasures you wish to implement for mitigating said risk in the event of a breach/data loss scenario. I always recommend backups to help with that last point. Data will never be fully compromised if there is an off-site, up-to-date backup readily available. These are just a few aspects to bear in mind when contemplating the security of our data, though I hope you found this information useful! Thank you for reading, my fellow tech enthusiasts! Feel free to leave comments down below.