Enabling NetBurner’s Built-in Secure Serial Capability
Let’s be honest, if you had a “kick me” sign taped to your back, you’d want someone to tell you it was there, right? Well, today we’re here to do you a solid and give you the lowdown on a feature that’s already built into your NetBurner Serial-to-Ethernet (S2E) device. Something that adds that extra layer of security and lets you walk the halls with ease.
In today’s world, data security means everything. Consumers, governments, and corporations large and small are taking huge hits because of cybercrimes and hacking. It’s becoming increasingly clear that everyone needs to go the extra mile and be vigilant when it comes to protecting things that are getting sent across the wire and out into the world. These vulnerabilities can be especially common for network-enabled systems and applications that were originally designed to run across a serial connection, and not be exposed to a network or the Internet at all.
In this article we are going to go cover how to securely connect two serial devices over a network using NetBurner’s Serial-to-Ethernet devices (two SB800EX-JDD-IR’s to be exact, though any of our S2E devices will work). It should be noted that if you only need one S2E module for your secure communications, the majority of the steps here will be unnecessary.
(If this is the case, please see our previous article, “Cover Your Data Assets with TLS“. This article goes the extra mile to cover both ends because, well, we like you, and you deserve it. Also, it gets a little more nuanced… but mostly it’s the first reason.)
Last month, we addressed how to add encryption to your device with a self-signed certificate in our article, “Creating a Self-Signed SSL Certificate for Secure IoT Applications“. In that example, the NetBurner device has the role of a basic web server that dishes out a single web page using TLS encryption to browsers that make their request through the HTTPS protocol.
“Well, that’s great,” you might say, “but that doesn’t help me at all with my legacy devices that need to communicate serially over a secure network connection with other legacy applications or devices.” Friend, we’ve got you covered. In the famous words of Emeril Lagasse, it’s time to take our previous example and “kick it up a notch!!”
To begin, we will need a few things from the aforementioned self-signed certificate article. Namely, we will need the Certificate Authority certificate (CA.crt) and private key (CA.key) that are created when running the makeca script found your \nburn\config directory. We will also require the server certificate (device.crt) and private key (device.key) created from the makeserver script.
To start, we are going to configure both devices so that they expect to communicate through a TLS connection. To do this, turn your devices on, open a browser, and head to their home page by typing in their IP address into the address field. The IP address can be found through the IPSetup or AutoUpdate (found in nburn\pcbin) for applications built using the NNDK 2.x tools. You should see the following screen displayed:
Figure 1: Secure Factory Application Main Screen
For applications built with our NNDK 3.x tools, you can simply visit discover.netburner.com or run the LocalDiscover application (also found in nburn\pcbin).
To make things easier, we will configure the Server first, and then Client. The Server should be the device associated with the side of the serial communications that will be receiving data. Which device you choose for each role isn’t important, just flip a coin and then stick to it.
Server Setup
From the main page shown in Figure 1, select the “TCP” link from the top menu, which will redirect you to the device’s TCP settings. For the SB800EX devices, the default debug port is Port 1, so we will configure Port 0 for our secure communications. The image below outlines the fields that we will need to take a peek at.
Figure 2: Server TCP Settings Page
The first setting to change will be the “Listening network port”, labeled (1) in Figure 2. This will be the port that the server listens for the secure communications on. The default port for TLS communications is 443, which is what we chose here, though you are free to pick a different port number.
Potential Hang-up: It should be mentioned that if you get a little nosy and want to do some packet sniffing with Wireshark (and who wouldn’t?!), the port number used will dictate the protocol displayed in the protocol analyzer. That means if you stick with port 23 and look at packets coming across the wire, what you will see will be labeled strictly as TCP packets, not TLS packets, even though it secretly will be.
The next setting to change is the checkbox labeled, “USE SSL rather than TCP for connections.” Just make sure it’s checked, and then hit the “Submit New Settings” button at the bottom of the page. With these established, click on the “HTTPS” menu option at the top of the screen so we can go ahead and upload the Server’s certificate and key. This link will take you to the screen shown in Figure 3.
Figure 3: Server HTTPS Configuration Page
To upload the certificate and key files, hit the “Choose File” button, as shown by label (1) and (2) respectively in Figure 3. Select the device.crt file for the certificate, and the device.key file for the key file. These are the files that were created by the makeserver script mentioned previously. Finally, hit the “Install Certificate and Key” button, and notice that the text has changed next to both the “SSL Public Key Certificate” and the “RSA Public Private Key Pair” from “Default” to “User Installed”.
Congrats, your Server is now ready to roll.
Client Setup
Similar to the Server setup, we will start on the main page of our Client device, and then navigate to the TCP settings page via the “TCP” link from the top menu. The TCP settings page will be identical to the one shown in the Server setup section, however we will change a few different fields, which are outlined below in Figure 4.
Figure 4: Client TCP Settings Page
There are four separate fields that need to be changed for Clients. The first dictates when a secure connection is attempted, and is labeled as “When to begin making outgoing tcp connections:”. Depending on your application and setup, either “If serial data received” or “On power-up” could be chosen. In this example, we opted to go for the former. Just as in the case of the Server, the Client needs to specify the connection port, and it needs to match the choice made for the Server. Here it fits in the field labeled, “Connect on network port:”. The default server port for a TLS connection is 443, and it is what we are going to use here. For the Client, we also need to specify the IP address of the Server we plan on connecting to. This is entered in the field labeled, “Connect to this address:”.
Finally, as with the Server, we need to tell the Client to connect using the secure protocol in place of a standard TCP connection. This is the checkbox highlighted in Figure 4 under label (2). Make sure it’s checked, and then hit “Submit New Settings” to save our changes.
With this done, let’s move over to the uploading the Certificate Authority certificate and key. To do this, navigate to the “CA Certs” link, found on the top menu of the page. It will redirect us to the page where we will be able to upload the required file, and should look like the page shown in Figure 5 below.
Figure 5: Client CA Certificate Page
The certificate file in question is the CA.crt file generated from the makeca script mentioned in the introduction above. Click on the “Choose File” button, labeled (1) in Figure 5, select your CA.crt file, and then hit the “Add New client CA” button to upload it. You should see the file’s data populated in the table on the CA Certificate Page.
At this point, both of our devices are setup, and we are ready to roll!
Side Note: If your configuration requires that both devices need to be able to initiate the secure connection, in essence acting as both the Server and the Client, just complete all of the steps above for both devices. At that point, you would then have created and uploaded a device.crt, device.key, and CA.crt for each device, and set the TCP settings for both devices accordingly.
Testing
- To verify our setup, we will perform a simple serial tunneling test. The steps for this are outlined below.
-
- Turn on both devices
- Connect each device to a PC via a serial connection through Port 0
- If your PC does not have 2 DB9 ports, it’s possible to use a serial to USB converter dongle, such as the one made by Sabrent found here
- Start two instances of MTTTY (our simple serial terminal application found in nburn\pcbin)
- Connect each instance of MTTTY to one of the COMM ports available from the drop down
- These should correspond to each connected SB800EX (if your PC has several available, this might take some trial and error)
- If the TCP settings on the client were set to connect “If serial data received” as shown above, then typing data into the Client’s MTTTY terminal should initiate a secure connection to the Server. The typed data should then be sent to the server and displayed in the Server’s corresponding MTTTY terminal.
- Success!!
If you don’t already have MTTTY you can read about it and download it from this blog post.