Go on, admit it. At some point in your life you've written down a password on a piece of paper in clear text. Anybody walking by can simply glance at your note, and they'll know what your password is.

No, you have never done that? Excellent. 

But if you've ever used your web browser to log into a website over the web, and entered sensitive information like your password without encryption, you've effectively transmitted that information through the internet for all to see, almost like writing it on paper and showing it around.

Whoa.

So, how do you tell if your connection to that website is encrypted? We'll get to that, but first, let's discuss what encryption is and how it works.

Encryption for transferring information to a website via the Internet has been around for decades. But today, we use strong mathematical formulas to build encryption and decryption algorithms that would take a hacker hundreds of years to decode.

These particular algorithms go by the term of TLS, or Transport Layer Security. TLS evolved from Secure Sockets Layer (SSL), which got its start at Netscape Communication Solutions in 1994 to protect e-commerce data transferred over the web.

Several iterations have evolved since then, each with different version numbers and subsequent bumps in the level of the core algorithms, resulting in a much stronger security model. SSL is no longer considered adequate encryption, and TLS is the newer standard.

TLS is normally used with TCP (Transmission Control Protocol) in order to encrypt application-layer protocols such as HTTPS (Hypertext Transfer Protocol Secure), FTP (File Transfer Protocol), SMTP (Simple Mail Transfer Protocol), instant messaging, and so on.

Most modern web browsers currently support TLS and use it by default. However, while a lot of traffic on the web is encrypted with TLS, it’s not required; it’s up to both the application client and the server to make it work.

How does TLS work? It uses a combination of symmetric and asymmetric cryptography between the client and the server to encrypt and authenticate the session data.

TLS also makes significant use of a certificate of trust—which we will get to in a moment.

Let’s shake on it

After establishing a TCP connection, the client (usually a web browser, but it could be another application) starts a TLS handshake. Broadly speaking, the handshake goes like this:

1. The client connects to the server, requests a secure connection, and tells the server which level of TLS it supports.
2. Client and server agree on the encryption method for the rest of the transaction.
3. The server sends its certificate, which is used by the client to verify the server's identity.
4. The client validates the certificate, to ensure it really is talking to the server it thinks it is.
5. The client, now trusting the server, generates an encrypted session key using the public key in the certificate it got from the server.
6. The server decrypts the key it got from the client and validates the secure connection (which only the server can do, since only it has the private key that works with the public key in the certificate it sent).
7. Finally, the server and client have negotiated what they need (the session key) and agree that from here on out, everything will be authenticated and encrypted.
8. At this point the handshake is done, the encrypted connection is negotiated and verified, and the client application can begin transmitting data.

This last step is important: because the encryption is now in place, all data from the client to the server (and back) is encrypted and protected from man-in-the-middle attacks. So when you log into your groov EPIC, for example, no one can intercept your username or password!

Here is an even more simplistic overview.

The certificate the server sends the client must be trusted by either the client itself or by a third party that the client can trust, like a Certificate Authority, or CA. Once the certificate is verified (thus verifying the server), the asymmetric key is exchanged. This key is often, but not always, seeded by a random prime number and is used to compute the symmetric encryption messages from here on. (Symmetric encryption is used because asymmetric keys are computationally heavy.)

More about certificates

So what is this all-important certificate about? Security certificates do just as the name suggests: they certify that the source is exactly who it says it is. They also encrypt the server’s public key in such a way that no other server can masquerade as the author and pass itself off as being the same entity.

Like a passport, the certificate identifies you and only you. It contains information about your identity that proves who you are. In the case of the passport, the government of your country is responsible for ensuring that your passport is linked or issued to you and only you.

In the case of the certificate, a CA (certificate authority) exists to do the same job: to prove that the entity it gives a certificate of trust to is who it says it is. Two well-known CAs are Verisign (owned by Symantec) and Digicert, but there many others, including perhaps your very own IT department.

As well as proving who you are, a certificate also encrypts the public key, thus keeping it secure from prying eyes while it’s on its way to the intended recipient and back. The certificate does this using a system called asymmetric key cryptography. This method consists of two keys, a public key and a private key. The public key can be made, well, public; it can be given to anyone that you need to converse with. The other, private key must remain locked away and kept safe by you.

Data locked by the public key can only be unlocked by the private key and vice versa. So, for example, a bank can use your public key to encrypt your account balance, and only your private key can unlock it and see your balance.

What about groov EPIC?

Now that you have all that background, here’s what you really need to know: The groov EPIC processor uses TLS on port 443 (used by groov View, groov Manage, and Node-RED), so all communications on this port are encrypted. These applications also require authentication, so to use them, you must enter your username and password.

And in addition to using encryption and authentication, the groov EPIC processor provides the necessary tools for you to install and manage your certificates and thus strengthen communications to and from the device by proving its identity.

The EPIC system supports X.509 PKI standard certified connections to servers and from clients using TLS/SSL certificates, which can be registered publicly through a Certificate Authority (CA), registered with your IT department, device generated, or self-signed, depending on your application and what your clients need to see. Since the certificate can be registered with your IT department, you can install their managed certs and encrypt all communications with your company's existing infrastructure.

As part of best security practices, we highly recommend that all communications to and from your groov EPIC be encrypted with TLS and use these certificates. This will help prove ownership of the messages passing between client and server. (Note that groov EPIC can be either client or server or both, depending on who originated the data flow. See our blog post on device-originating data for more information.)

By default, groov EPIC does encrypt all usernames, passwords, API keys, and data between client and server on secure HTTPS port 443 and uses TLS encryption for secure data transmission.

This means that no man-in-the-middle hacker can sniff the traffic and view those credentials. Without the TLS encryption, the data would be in clear text for all the world to read. Not something you want.

TLS and certificate administration are just two more ways that groov EPIC helps you build and maintain a secure network.

Now, back to that question: How do I know if I have an encrypted connection to a website before I enter in my username and password?

The good news is that all modern browsers indicate the type of connection currently established, right in the URL bar. If you see https at the beginning of the server or website address (typically with a padlock next to it), you're good. If the s is missing and the address just shows http, danger!

You can also click the padlock to get details about your encrypted connection. Cool!

Till next time. Cheers, Mate.

Other posts in this series:

• Part 1: Dual network interfaces
• Part 2: What's a firewall?
• Part 3: Device-originating communications, or how and why MQTT rocks
• Part 4: User accounts
• Part 6: Linux operating system and repository