Video 10.3 Project 4 Security - Authorization with TLS/SSL: Implementation & Analysis In this video, we will cover the following topics. What is TLS/SSL How to configure Project 4 to enable TLS/SSL Implementation & packet analysis TLS/SSL Imagine that you are sending a letter. You would have written the recipient address on the letter. Thus it’s clear from the letter who the recipient of the card is, and the postman will make sure that the letter arrives. But, nothing prevents the postman from reading the content of the letter. In fact, everyone who is involved in delivering the postcard can read the content of your letter. A bad person could even alter the contents of your letter! This scenario is also true for computer networks in general and the Internet in particular. The use of plain TCP/IP is like sending the letter. The TCP packet passes through many network components like routers, firewalls, etc., before reaching the target. Every participant along the way can read the content of the packet in clear text and even modify it. TLS/SSL is all about providing a secure communication channel to ensure that the contents of your communication can not be read or altered by third parties. When it comes to MQTT, we all know that it is built on top of the TCP transport protocol. By default, TCP connections do not use encrypted communication. To encrypt the whole MQTT communication, many MQTT brokers use TLS instead of plain TCP. This is on top of the authentication mechanism we have done earlier. When we use the TLS/SSL encryption, the full MQTT packet will be encrypted and encapsulated into a TLS packet. Till now, we have been using the MQTT port 1883, which is an unsecured port due to a lack of encryption support. Thus for MQTT over TLS, port 8883 is exclusively used. So TLS is a must-have feature of any MQTT system, right? Wrong! While every IoT developer would love to include the TLS/SSL encryption, there are some disadvantages. There are two overheads for implementing TLS/SSL. One is the CPU usage overhead for the broker, and the other is the big overhead for the client. The communication overhead of the TLS Handshake can be significant if the MQTT client connections are expected to be short-lived Sometimes, TLS is not feasible for constrained devices due to insufficient resources. Depending on the implementation, TLS can be very computation-intensive and can require many kilobytes of memory. If TLS is not possible with your devices, there are two options. Use payload encryption for your PUBLISH messages, which we will be covering in the next video Encrypt the password in the CONNECT message of your client. TLS/SSL Implementation is a vast topic, and there are different methods to encrypt in the TLS implementation. They are as follows. 1. Using a root certificate authority certificate 2. Using a root CA certificate plus a client certificate along with a key 3.Using a pre-shared key (PSK) We are going with only the first implementation, due to time constraints and as security is a vast topic. But I have provided adequate resources in the resources section to learn about the second and the third type of TLS implementation with the IBM IoT Platform. Now download the code files that we will use in this video from the resources of this video. After you download, make sure you send over the raspberry pi 4 client code and the CA certificate file to the Pi 4. Now first, let’s look at the Client Code of the ESP32. Instead of the WiFi Client library, we are now using the WiFi Client Secure library to implement TLS encryption. All these instructions are the same as in the last section implementation This constant character array holds the Root CA certificate of the IBM IoT Platform. The Cloud Service provider itself has provided the CA certificate. If you want to learn more about that, check out the resources of this video. The next change happens in this object definition. We have used WiFi Client Secure instead of WiFi Client. The next instruction is very important. Here we can see that the port number has been changed from 1883 to 8883. There is only a single more change in the code Inside the setup loop, we have used the setCAcert method to set the CA certificate for TLS Implementation. Now let’s look at the client code for the Raspberry Pi 4. Opening tls.py, reveals that there are no changes to the client code. Thus the only change will be with the configuration. So now open the app.yaml file There are 2 changes in this file. The first change is that the port number is changed to 8883 from 1883. The final change is the inclusion of the path of the CA file Make sure that you modify the path based on where you have saved the certificate file. The CA file consists of 2 Certificates, unlike the ESP32. This is because the raspberry pi 4 accesses the IBM IoT platform through a gateway API. So there needs to be a CA certificate for the API Gateway on top of the normal IBM IoT Platform CA certificate. The explanation of the client codes are done. Now set up the hotspot, connect the clients, and fire up Wireshark. After you open the Hotspot interface in Wireshark, enter the display filter to only show packets sent through 8883. Now, run the client code on the Raspberry Pi 4. And just after that, give power to the ESP32 client, in which you have already uploaded the client code. Now let the ESP32 client publish the GPS coordinates once, stop the Pi 4 client, and disconnect the ESP32 from power Now, if you look at the captured packets, it is clear that all the MQTT packets are encrypted and encapsulated into the TLS packets. Let’s look at the application data packet. Here you can see that the MQTT is the type of packet in the encrypted form encapsulated inside the TLS packet. As it is encrypted, we cannot understand or decipher any of the data. As said earlier, TLS has quite some overhead. This is evident from the number of packets sent before and after the application data We have completed the packer analysis for the TLS Implementation. Summary. In this video, we have covered the following topics. What is TLS/SSL How to configure Project 4 to enable TLS/SSL Implementation & packet analysis TLS/SSL In the next video, we will learn about payload encryption in MQTT.
