Two keys for secure communications:

What are SSL/TLS and HTTPS? You may have heard them being used on the Internet, and you have more than likely used them when logging into your bank, but what are they?

Is there anything you need to do to use these secure protocols?

What goes on "behind the curtain" in your web browser when you use them?

In this week's blog we are going to continue the theme of network security by taking a close look at SSL/TLS and HTTPS.

It's all about encryption:

Authentication is used by a client, often a human, to tell a server that the client is authorized to use the server's resources.

Encryption involves changing the data so that it is unreadable by anyone who does not have the decryption keys.

A few weeks back we talked about passwords vs passphrases, which introduced some authentication aspects: a password helps the client prove they're authorized to use the server's resources. We'll revisit authentication in a future blog. Today's blog is going to cover encryption. 

HTTP

HTTP (Hypertext Transfer Protocol) is the foundation for data communication on the Internet. Hypertext uses logical links (hyperlinks) to connect pages containing text. HTTP is the protocol that defines how this data is formatted and transmitted, and what actions Web servers and browsers should take in response.

SSL/TLS

So TLS was developed as the successor to SSL. TLS (Transport Layer Security) also has a certificate using a private key and a public key, but it has the benefit of being an open protocol that works over any bidirectional stream of bytes, not just Internet-based data sockets.

So when you put this together, you end up with HTTPS (the combination of HTTP and the security layer) being the protocol that defines how the client and server are going to negotiate the secure connection. The certificate is the "document" that each end uses to agree on the server's authenticity and data encryption method.

How does this agreement take place?

Let's take your bank website as an example. You visit https://somebank.com in order to shuffle some personal funds around between accounts. You sure do not want anyone sniffing that traffic and getting your user name, password, or any other details. This third-party sniffing is often called a "man-in-the-middle" attack. To protect against this possibility, the bank will encrypt its data transfer between your web browser and its server, but how does your web browser know that it really is connecting to https://somebank.com and not a fake website built to steal your details?

The role of the Certificate Authority (CA):

When your browser hits the bank's website, the bank's web server responds with part of a certificate. Your browser then goes out onto the Internet and checks that the certificate your browser was just given from the server really does belong to the URL of the bank. It does this very quickly in the background before your browser loads the bank's web page. You probably won't even know it's doing it.

The CA is a trusted third party that issues the encryption key to the bank. Its role is to have a process in place that ensures that the bank, and only the bank, is the true owner of the URL that the certificate is tied to.

The bank web server has given your web browser the public part of their key; your browser has checked with the issuing Certificate Authority and found that the public key indeed belongs to the URL that issued it, so it gives your browser the thumbs up to go ahead and encrypt all traffic between it and the bank's web server. Thus you are protected from a man-in-the-middle attack.

If pictures work better for you than a wall of text, then just follow the numbers in this diagram:

As you can see, it's both straightforward and complicated. And yes, it happens every time you visit a web site with https.

It is important to note that the URL is a significant part of this process. The CA issues their certificate against that "real-world" (WWW) URL. If the web server you are connecting to via HTTPS is not on the web—like if it's on a local network that isn't connected to the Internet—it won't have a URL that the CA can verify. In that case you will need to use a self-signed certificate.

Self-signed certificate:

If you are using an HTTPS connection and it is behind a firewall or has no connection to the Internet, then you have no CA-verifiable URL for that web server. This setup might be common in an industrial automation network. How can your browser know that it really is connected to the web server and not an unknown man in the middle? The answer is that YOU need to install a certificate on both the server and the browser.

You trust yourself, right? On the web server, generate the private and public keys, then copy the public key onto every browser that will connect to that server. From that moment on, the server and the client will compare network connections and agree they match, and so they really are talking as a trusted pair. If another person tries to intercept or redirect the web server, your browser will issue a warning. You are also protected from snooping, as the traffic is encrypted.

These self-signed certificates can also be copied onto mobile devices so you can use their browsers to connect to the web server and have the traffic verified and encrypted. For a step-by-step guide on how to do this on your groov system, check out chapter 2 of the groov Server Users Guide (PDF). For a step-by-step guide on how do this on a groov Box, check out chapter 5 of the groov Box Users Guide (PDF).

If your company has an IT department, check in with these guys first. They may have self-signed certificates they can install on all your machines and clients. You could use these certificates on your groov system as well, and thus not have to worry about installing a certificate on each client (the web browser - PC or mobile).

TLS and HTTPS work hand in hand.

HTTPS is HTTP with TLS added into the mix. The CA is an important player in the encryption trail, as is your browser.

Using these well-proven, industry-standard tools is not hard and will go a long way to ensuring that the data flow between your browser and the server cannot be snooped on by any person.

Next week we will take a look at how you can lay out your network to add another layer of security.

Till then, Cheers Mate.