Internet Security: SSL/TLS
Elsewhere at this site I have described the GATT Client MQTT Gateway project. There a BLE (Bluetooth Low Energy) server (peripheral device) communicates data to a BLE client (central device) that also acts as a WIFI gateway to send data to the cloud. The gateway messaging protocol is MQTT (Message Queue Telemetry Transport), which is a simple and lightweight protocol ideal for Internet of Things devices. However, sending data across the network usually requires security, and the SSL/TLS protocol provides this security.
If you built the above mentioned project then you will have discovered that the ESP32 library has support for TLS and you will have enabled it along with downloading a certificate from your cloud service and putting the data into file cert.c in the main directory. What this file is and how SSL/TLS works is the subject of this post. Furthermore, I will show this working with Wireshark exhibiting a short TLS exchange.
What is SSL/TLS?
SSL/TLS stands for Secure Sockets Layer/Transport Layer Security. Although you will see the two presented together as in the above title, SSL is deprecated and what is used are versions of TLS. Differences between the two aside, what is important is both are protocols that practice encryption, the most important of which involves asymmetric public-private key cryptography, invented in 1976 by Whitfield Diffie and Martin Hellman.
Asymmetric Verses Symmetric Encryption
I think that we all grew up with having some idea of symmetric encryption. There is a secret key, usually a number that we hold secret, and we use it in some mathematical sense to encrypt a clear text message, resulting in an encrypted, obscured text message. Then, the other party receiving the message possesses the same secret key, and applies it in a similar mathematical sense to unencrypt the obscured message to produce the original message. The same secret key is used to send messages both ways.
The magic that Diffie and Hellman created was a mathematical way to create two related numbers whereby one is used to encrypt the message but only the other can decrypt the message. You can also encrypt the message with the second number and only the first number can decrypt it. Truly magical! This is what public-private key cryptography is about, and its invention has enabled information security on today’s internet. We generally assign one number to be the public key (anybody can have it) and the other to be the private key (the owner keeps it secret). This results in some very practical protocols described in what follows.
How TLS Works
Let us start with the simple concept. Once a secure session is established, both client and server have the same secret cryptography key and each uses it to either decrypt receiving packets or encrypt sending packets. This is straightforward symmetric cryptography that has been around since well before Diffie and Hellman invented asymmetric cryptography.
The secret key is created and exists only for the current communication session. The big question is how does this happen? If the client creates the secret key, how does it get over to the server without being intercepted by a bad guy? If the server creates it, how does it get to the client safely? How does the client know that the server is legitimate and is not an imposter? All very serious questions and asymmetric cryptography comes to the rescue with its magic!
Server Keys and a Certificate Authority
Let us begin by saying the server creates a public and private key pair and keeps this pair for use in communication sessions. These are the two related numbers mentioned earlier. When a client contacts it requesting to start a secure session, the server is going to send its public key to the client. The client then uses this key to encrypt a symmetric secret key and then sends this encryption back to the server. No one can intercept and open this encryption to get at the secret key since only the server’s private key can do so. The server uses its private key to open up the message and extract the secret key. Voilà! Now both client and server have the same secret key and they can securely communicate. Truly magical!
But wait. How does the client know that the server it contacted is legitimate? What if a bad guy re-directed the client’s request to his own server? That is where the need for a Certificate Authority (CA) comes into the picture. A CA is an organization that verifies the legitimacy of a server’s site and uses the magic of public-private key cryptography (PPK) to provide a sort of certificate of authenticity attached to the server’s public key that any client can check. This certificate is known as a Digital Signature and is one of the protocols that the invention of PPK has enabled.
There are a number of organizations whose sole purpose is to verify the authenticity of web sites that want to engage in secure communications with clients and do so by providing the server sites with a certificate that the CA has signed with its private key. What the server sends to the client is this certificate. It contains the server’s public key along with a digest of this key that the CA has encrypted (“signed”) with the CA private key. So now the client has both the server’s public key but also an encrypted digest that it can open with the CA’s public key. The client opens this digest revealing the clear text version of the digest, takes the server’s public key and converts it into a digest using the same method that the CA used, and compares the two digests. If they match, then the client is certain that the public key is legitimate. If one thinks this through, there is no way a bad guy can create a public key whose digest will match the real one.
If this sounds confusing, that is because it is. When one first encounters these concepts, one often needs to study it awhile before understanding settles in. Also keep in mind that these keys and certificates are text files containing numbers formatted in certain standardized notations and are used in the mathematical operations of encryption, decryption, and making digests. All of this is easily handled by the machines running as servers and clients.
One more item: from where does the client get the CA’s public key so that it can decrypt the digest? Well, the server additionally sends a second certificate in the same transaction, which is in fact the CA’s certificate containing its public key. The client inspects it and then determines if this CA is trustworthy and proceeds accordingly. To make this determination the client needs to have a copy of the CA’s certificate in its default trust/CA store. In most cases this copy is already on the client’s machine. On Linux machines, for example, look in the /etc/ssl/certs/ directory.
Wireshark: TLS between Client and Server
Now we look at a real example where a MQTT subscriber receives data from an MQTT cloud broker using secure TLS. Shown below is the mosquitto command and data being received. The port ( -p 22850) specified is the cloud’s SSL port and the – – cafile switch specifies the location of the CA certificate file. Separately data is repeatedly sent to the broker using TLS and a mosquitto MQTT publisher on a Jetson TX1 receives this data securely under TLS.
nvidia@tegra-ubuntu:~/mqtt$ mosquitto_sub -h m11.cloudmqtt.com -p 22850 -t esp32/gateway -u tegra -P nvidia -v --cafile /etc/ssl/certs/ca-certificates.crt
esp32/gateway 172 mv
esp32/gateway 172 mv
esp32/gateway 172 mv
esp32/gateway 172 mv
esp32/gateway 172 mv
esp32/gateway 172 mv
esp32/gateway 172 mv
esp32/gateway 172 mv
esp32/gateway 172 mvThe broker is at www.cloudmqtt.com. Here is shown an overview of the whole session. Pointed out are the TLS handshake beginning and ending, the packets of encrypted application data, and the ending of the TLS session.
The SSL or TLS client sends a “client hello” message that list cryptographic information such as the SSL or TLS version and, in the client’s order of preference, the CipherSuites supported by the client. The message also contains a random byte string that is used in subsequent computations. The protocol allows for the “client hello” to include the data compression methods supported by the client.
The SSL or TLS server responds with a “server hello” message that contains the CipherSuite chosen by the server from the list provided by the client, the session ID, and another random byte string.
The server also sends its digital certificate.
The client now has the server’s public key and its encrypted digest signed by the CA. Included is the CA’s certificate containing its public key, which is then verified trustworthy since it is contained in the client’s certificate store. The client now sends the random byte string (encrypted with the server’s public key) that enables both the client and the server to compute the same secret key to be used for encrypting subsequent message data.
Voilà! Both client and server have the same secret key and encrypted application data are now sent back and forth. All of the magic happens within the “handshake”.
More Wireshark and Certificates
For those who wish to see details let us look at the packets in some of these exchanges. We begin by looking at the “client hello” packet.
Note the random number and list of ciphers mentioned earlier. If one expands this list a considerable number of ciphers are offered to be chosen for the secret symmetric key. Next we look at the “server hello” packet. Note the cipher is chosen and another random number for computation is sent back to the client.
Next the certificate packet is shown and it has lots of substance to it. Note that one certificate is that of the broker and there are two certificates in a chain for the CA. When one expands these certificates one sees they contain public keys and signed digests.
Let us look at the brokers certificate and the last certificate in the chain for the CA, which is the most relevant one when there is a chain.
In the screenshot the public keys have been expanded for viewing. We see they consist of an exponent and modulus, the modulus being a very long number that appears random. Also shown is the digest of the public keys that have been encrypted with a CA’s private key. Again this is a long, random appearing number.
We now finish by viewing the “key exchange” packet. What is encrypted by the server’s public key is a random number created by the client. Both client and server then use it in the cipher that creates the secret key. Now both client and server have the same secret key and the session can now continue using the symmetric cryptographic cipher.
Conclusion
To understand SSL/TLS security and how it works one needs to grasp the concepts of asymmetric public-private key cryptography. Normally, for the newbie this is not easy. But with some diligence enough understanding settles in and then the protocol of SSL/TLS can be understood. More on the subject can be found here.
If you understand the subject adequately and want to set up TLS on a MQTT broker then go here. You will also find there a nifty diagram that explains the SSL/TLS protocol.
