CISSP Blog Post 4, Domain 2: Encrypting Data in Transit

Credit: Post based on CISSP course presented by Dennis Lee, November 2018

Today’s post is short and sweet – we’re going to quickly look at how we encrypt data when moving it between systems (aka "in-Transit").

We have two common ways of doing this – first Link Encryption which is where we encrypt the data header and data content / payload of packets at each point along the journey. The drawback to this approach is that it can be compromised in multiple locations. An example of a technology utilizing Link Encryption is WPA2 for Wi-Fi.

Link Encryption for Data in Transit

The other alternative is called End-to-End Encryption which only encrypts the data payload in packets. Examples are TLS and SSL. End-to-end encryption is faster, has simpler key management, and doesn’t decrypt the data at the middle nodes. The drawback is it exposes both the sender & destination since the data header is not also encrypted. The good news is, you can combine both link & end-to-end encryption for the best of both worlds!

End-to-End Encryption for Data-in-Transit

HTTPS Protocols and Ciphers

To give a bit of background on this post –

I was researching different Firefox about:config settings for another article (to be forthcoming) and had changed a bunch of security settings to try and force Firefox to use higher grade encryption when accessing encrypted (HTTPS) websites.

Later in the day, I tried to access a website I visit very frequently and found that it wouldn’t load. I eventually realized that it must be because I had changed my Firefox security settings. The question I was stuck with was, “How do I figure out what encryption protocol and cipher a website is using in order to allow that encryption in Firefox?”. After some more research I was left with the following:

What is HTTPS & how does it work?

When you access a website, you are typically communicating over one of two protocols: HyperText Transfer Protocol (HTTP) or HyperText Transfer Protocol Secure (HTTPS). When you connect using HTTPS, all the information sent back and forth between you and the website is encrypted.

There are of course exceptions to this – for example, on your bank’s website, it may have a secure component for logging into the website but it may also have a third party advertisement that is not delivered encrypted to your browser. Depending on your browser, it may alert you when there is “mixed” content being loaded.

At a high level, when you access an HTTPS website, the server has a list of approved protocols and ciphers that it will allow communications to be encrypted with. This list is either the default list that the server comes enabled with (i.e. no one really thought about it, they just turned it on), or it’s a customized list that (hopefully) only allows the latest and greatest encryption methods.

Just like the server, your browser has a list of approved protocols and ciphers that it can use. When your browser contacts the server to load the HTTPS page, the server gives it a list of the approved encryption methods – this list is prioritized by the server’s “preference”.

Assuming your browser allows connections using one of the approved server’s methods, the browser and server conduct a “handshake” where the encryption method and a key are agreed upon and exchanged, allowing both the server & the browser to encrypt and decrypt communications between them. When the “handshake” is conducted, it is the most dangerous part of the communications process because it is done without encryption and (if done improperly) can allow for “man in the middle” (MITM) attacks or other attacks by an outside party. (I hope to cover different types of attacks and how they work in a future article.)

So what’s the difference between a protocol and a cipher? Think of encryption protocols as the method by which information is encapsulated and sent whereas ciphers are the way which information inside the capsule is scrambled (encrypted) to prevent anyone from reading the information.

Determining a Server’s allowed Protocols and Ciphers

This leads us back to my original question – if your browser does not accept the encryption types allowed by the server, how do you figure out which ones you need?

I found that there is a very handy website called http://www.ssllabs.com that has a SSL Server Test tool (available here: SSL Server Test) that allows you to plug in any website and it will determine if there are any available HTTPS connections to that website as well as give you a high level score and a very detailed breakdown of the site’s security protocols and ciphers.

There is also a Firefox plug-in available (called CipherFox) to give you this information every time you visit a website.

Tomorrow I will cover which Protocols and Ciphers are best to use & how to implement them in your Firefox browser.

Got questions or feedback? let me know in the comments below. Thanks!