Adding TLS/SSL in LabVIEW
Adding TLS/SSL in LabVIEW
By Ulf Nilsson
I stumbled into encrypted TCP traffic, or more specifically, TLS, over ten years ago in LabVIEW 2011. A colleague and I were working on a test system that needed to communicate with devices over Ethernet, using both TCP/IP and secure encrypted TLS/SSL. The network devices worked as clients, and we needed to build a server that could communicate with them.
We started the project by adding support for non-encrypted TCP traffic in the server, and then when we saw that the communication worked well, we added the encryption part.
Figure 1 Our network setup
Transport Layer Security, or short TLS, is a cryptographic protocol designed to add communications security over a computer network. The purpose is to supply privacy, integrity, and authority between two or more communicating network devices.
- Privacy: No one can see what you are sending
- Integrity: No one can change the message
- Authority: The sender and receiver are whom they claim to be
Although I have been working with encrypted communication for over a decade, I still considered myself an amateur as to how it all works behind the scenes. Support for TLS came to LabVIEW 2020, so we couldn’t use any built-in VIs for the encryption back then. Instead, we ended up using both LabVIEW TCP/IP VIs and Microsoft .NET code. Together with help of Wireshark, we could debug the protocol in both modes.
TCP and TLS handshake
The TLS communication starts with a regular TCP connection handshake and thereafter begins the TLS handshake, which, among other things, involves negotiation about what TLS version and cipher suite to use. The server and client identity are ensured with the help of digital certificates.
What do we need to do to use TLS in LabVIEW? Besides the actual LabVIEW code, we need to have a digital certificate. The certificate can be either self-signed or signed by a trusted certificate authority (CA). A self-signed certificate is created, signed, and issued by you, while a CA certificate is created, signed, and issued by a third-party, publicly trusted, authority. Certificates can be bought, and created in PowerShell or tools like OpenSSL.
Depending on the network and security environment, the TLS protocol can use one of two authentication methods: server authentication or mutual authentication. In server authentication mode, only the server needs to have a certificate and in mutual authentication mode, the client also needs it. In our case, we only had to deal with server authentication.
TLS certificates usually have the
following information:
-
-
-
The subject domain name
-
The subject organization
-
The name of the issuing CA
-
Alternative subject domain names
-
Issue date
-
Expiry date
-
The public key
-
The digital signature by the CA
-
-
Using TLS in LabVIEW
There is no support for TLS before LabVIEW version 2020, and if you are planning to use LabVIEW versions before that, you need to rely on third-party code to make it work. You can for instance use .NET code from Microsoft, as we did.
The code examples below show both the server and client implementation. The server side is implemented with help of Microsoft .NET and the client side is with native TLS VIs. Only the server is authenticated, with help of a self-signed certificate.
The TLS server code
The code for the TLS server starts with reading the certificate file for the server and selecting the network adapter and port to start listening on. Then, it waits for a TLS client to connect, and when that happens, it performs the TLS handshake, sends over a string to the client, and closes the connection.
Figure 2. The TLS server, using Microsoft .NET
Initialization
- Read the server certificate file
- Select the network and port number for the server to listen on and start listening
Figure 3. TLS configuration
Connecting to the Client
- Waiting for a client to connect
- Accept TCP client
- Get the client stream and start the TLS negotiation between the client and server
- Pack and send data to the client. Close client connection
Figure 4 Authenticate and send data when the client connects
Shutdown
In the shutdown section of the code, all created resources get are stopped and closed.
Figure 5. Client code
The TLS client
For this blog post, I tried to write the client code in LabVIEW, with help of .NET code, but failed as the .NET code required special callbacks, and that was not possible to achieve in LabVIEW. Instead, I used the built-in LabVIEW TLS VIs for the client.
The client code first reads and marks the server certificate as trusted, so that it can compare it with the one that the server sends over, during the TLS handshake.
After the TLS handshake and after the server certificate has been authorized, the client reads out the message from the server and closes the connection.
There is also a .NET call to read out and display the Subject property of the server certificate.
- Read the server certificate and add it to the trusted certificates storage
- Create the TLS connection
- Read four bytes from the stream to get the message size
- Read the rest of the message
- Close connection
Figure 6. Client code
Creating certificate
The server certificate, in the LabVIEW example, is created with OpenSSL in Ubuntu and Windows Subsystem for Linux, also known as WSL. Unfortunately, the .NET version that I used in LabVIEW did not support that certificate and private key are stored in two separate files (PEM format), so I had to combine them into a single file called p12. LabVIEW TLS VIs, however, cannot manage that file type, so for the client, I had to use the certificate PEM file.
Figure 7. Creating certificate file with OpenSSL in Ubuntu
The following two commands create the needed files:
openssl req -x509 -sha256 -newkey rsa:2048 -keyout key.pem -out cert.per -days 3650
openssl pkcs12 -export -out certificate.p12 -inkey key.pem -in cert.pem