Introduction

In this post we will be briefly looking at one of the security features available in pfSense – TLS. TLS stands for Transport Layer Security and is one of the building blocks of eCommerce. This will also introduce us to some other concepts such as X.509 certificates which will be useful when we setup a VPN.

TLS protocol

When you log into the pfSense web console you will see we use https in the URL bar. This is because we are connecting on port 443. The service used here is know as Transport Layer Security (TLS).

You will have seen this on eCommerce sites such as Amazon when you purchase goods and is denoted in the browser bar with a little padlock and the https protocol.

Within pfSense the option to set the web console to run over HTTPS (and thus use TLS) can be found on System > Advanced.

Here you will see a radio button selected labeling HTTPS. In addition to this a drop-down can be seen with SSL Certificate. Make a note of the name here as we will cover this later in the post.

TLS also known historically as SSL handles encryption and authentication. In pfSense it is used to provide a secure channel on which to connect to the web console in order to administer the firewall.

Currently when we visit the firewall via https we see an error:

This is related to the certificates that are used by TLS as part of the authentication process. We’ll look a little more into this error later in the article and how certificates are used as part of the security process.

The overall security services provided by TLS encompass:

• Origin authentication – client to server at application and transport layer
• Data integrity – to prevent being compromised in transport
• Data confidentiality – to prevent eavesdropping

TLS is implemented using a key exchange mechanism, certificate verification and digital signatures. Typically the client authenticates the server and not the other way round – although mutual authentication is possible and supported by the protocol. As you can imagine this would be impractical/unnecessary on an eCommerce website with hundreds of thousands of users and where we would expect them to have their own signed key chain.

However there are arguably places where mutual authentication would be beneficial – such as online banking.

So how does TLS work? Let’s take a look at some of the gory details.

How TLS works

When a client connects to a server, it kicks of the TLS handshake. This process includes negotiating cipher suites, encrypting shared session keys and generating message authentication codes (MAC).

MAC in this instance defines a Message Authentication Code – a hashed version of  a message(s). It shouldn’t be confused with the MAC address on your NIC. So same acronym – different definition.

TLS also uses a key exchange service. This provides for key agreement which is typically achieved by the client sending a secret that has been asymmetrically encrypted to the server.

One of the current methods in TLS 1.2 of doing this is via RSA however this is being phased out in version 1.3. The Diffie-Hellman key exchange is also available in various forms. You can see a list of these formats here.

Let’s take a quick look at RSA as this method is used in a number of other tools we will be using such as SSH.

RSA

The RSA algorithm is made up of four steps, these being the key generation, key distribution/exchange and finally encryption and decryption. RSA is a type of “asymmetric”encryption methodology also known as public key encryption.

The key generation steps are designed to produce two keys; a public key and a private key. The public key can be distributed to multiple machines/users. The private key is kept secret. The methodology for this revolves around using large prime numbers and modular exponentiation.

With the key distribution step we can use RSA to allow us to transfer a symmetric encryption key via an asymmetric key exchange protocol. The public key can be distributed through non-secure channels and then used to encrypt said private session key. Only the owner of the private RSA key can subsequently decode this encrypted message containing the symmetric session key.

Symmetric encryption is generally faster than asymmetric encryption but relies on both parties having the same key. This isn’t practical in most cases or at least without having some form of key distribution mechanism. Examples of these mechanisms include Kerberos and other trusted third parties built around the Needham-Schroeder symmetric key protocol. Of course we can also use public key cryptography as a means of distributing a dynamically generated session key for symmetric encryption.

The fourth step has in essence been described above when discussing key exchanges. To encrypt a message the plaintext is encrypted using the public key and then sent to the other party.  They then use their private key to decrypt the message. The inverse is true. A message can be encrypted with the private key, and decoded with the public.

Many protocols use the public/private key only for setting up a secure channel. In fact after this has been completed we can expect the messages to be encrypted using the shared symmetric keys using the method previously described.

With a quick summary of RSA under our belt let’s take a look at the TLS handshake in more detail.

TLS Handshake

The handshake as we have discussed involves negotiating cipher suites, exchanging keys over RSA and generating MACs.

How this all fits together is demonstrated as follows with two roundtrips:

Client	Server
Sends SYN
	Sends SYN ACK
Sends ACK
Roundtrip 1. Sends ClientHello including TLS version, random numbers (32-bit nonce) and list of supported cipher suites
	Roundtrip 1. Sends ServerHello with random numbers, Certificate and ServerHelloDone
Roundtrip 2. Confirms certificate is OK. Sends ClientKeyExchange, pre-master secret, ChangeCipherSpec,  and Finished message
	Roundtrip 2. ChangeCipherSpec, verify MAC and sends encrypted Finished message.
Decrypts Finish message with symmetric encryption key and checks MAC. Sends application data encrypted.
	Sends application data back and forth
Sends application data back and forth until connection is closed.

One useful feature of the TLS handshake process is that part of it can be “re-used” across a session. This means if we navigate between multiple webpages, we can leverage the fact we have already completed the 2 round trips. Thus in this latter re-use case only a single roundtrip is used.

TLS components

Digging a little deeper into TLS we can see some of the components that make up the protocol and handshake we saw above.

SSL handshake	SSL change cipher spec	SSL alert	Application data
Record protocol
TCP
IP

The first layer of the protocol contains the components needed for TLS handshake, alerting when the connection is closed and negotiating the cipher suite.

The next layer down is the Record protocol. This takes the data from the previous layer and fragments and encrypts it and also assigns an HMAC (Hashed Message Authentication Code).

Following this we see the TCP and IP layers.

If you would like to read more about how TLS works check out the High Performance Browser Networking guide by O’Reilly. This article includes more information on the handshake and other features of the protocol.

TLS summary

In the above section we have seen how TLS creates a secure channel between your machine and the pfSense box on port 443 to serve up the web console. We also mentioned that certificates are used, so what exactly is their purpose?

Certificates

Certificates are used to identify a party as trustworthy. This is important if you wish to transfer financial data between them and yourselves. They follow the X.509 standard where by a public key certificate chain (called public key infrastructure – PKI) is created. Each certificate is signed by a trusted party and ultimately by a trusted root authority. For example Google, Microsoft or a government department.

As you might imagine from the name, public key certificates are built around the same principles as public key cryptography.

When running the TLS protocol we check the certificate chain of the server to ensure it is trustworthy and the certificate hasn’t expire. If one of these two instances aren’t the case, we see an error same/similar to this:

In pfSense by default you will have a self signed certificate called “webConfigurator default”. You will remember this from when we looked at the Advanced screen. This is the certificate assigned to the pfSense box and used as part of the TLS authentication process.

To access the list of certificates on your system select System > Cert. Manager from the main menu.

This will bring you to the CAs tab. From here select Certificates.

On this screen you should see the certificate details and note that the Issuer (the CA) is self-signed. This is why we are seeing the error as the certificate is not signed by a trusted root.

As this is our local network we do not need to worry about purchasing a signed certificate. If you are interested in importing the self signed certificate however and trusting it in your browser – you can follow the steps here and also here for Mac users.

When we come to setup a VPN we will be creating a CA and also client and server certificates. More on this however in further posts.

Summary

In this post we briefly looked at TLS which explained the error we see when we login to pfSense web console. In addition it very briefly introduced us to RSA and X.509 certificates.

These topics will be covered in more detail in later posts. Next we will look at some further features in pfSense.