Cover Your Data Assets with TLS

Transport Layer Security (TLS) is highly recommended for many IoT and Ethernet connected applications. It is a cryptographic protocol that provides privacy and data integrity between two computer applications (e.g. a browser client and a host server). In a nutshell, TLS helps prevent eavesdropping and tampering. [ 3 ] TLS has evolved from SSL (Secure Sockets Layer) primarily to provide stronger encryption algorithms, to be more configurable, and to work on a variety ports. In terms of vernacular, usually when someone says “SSL” they now are really saying “TLS”. SSL 2.0 and 3.0 have been deprecated and you should make sure to disable those protocols on your servers and only use TLS moving forward. [ 4 ] You can test the quality of your server security using a tool like this one.

The reason SSL/TLS exists is to not only encrypt the data on the network, but also to guarantee the server is authentic. In other words, to guarantee the server you are talking to is who they say they are. This is accomplished by using a server certificate. You encounter this any time you are web browsing and go to a secure site, such as Amazon.

A certificate must be “signed” by a Certificate Authority (CA), such as Comodo, GoDaddy, Global Sign, etc. If you wanted to create a certificate for a website on the Internet, you would send the CA the proper files, they would verify you are who you say, and send you your certificate. Oftentimes, web hosts automate much of the set up for you. The CA’s information is already preloaded into your web browser. When you make a connection, your PC uses the certificate on the server and checks it against the CA’s information to verify the connection is legitimate.

In the above example you will have to pay annually for each certificate. A useful alternative, especially for IoT bootstrappers, is to create your own self-signed certificate. Self-signed certificates are great for secure internal networks, personal use, or to just try out the process on your bench prior to going live with your product. That’s what we will use for this article.

Unfortunately, creating and setting up a self-signed certificate is a bit too long of a process for this article…sorry! There’s plenty online about it and we plan to write up a post about it soon. Here’s our latest article on how to get that going.

Testing a TLS Connection between a PC and a NetBurner Serial-to-Ethernet Device

A common way to test a Serial to Ethernet (S2E) device on the network side of things is to use the venerable Telnet protocol utility – first developed in 1969 . Telnet can be run from the command line or you can use a program such as PuTTY (an open source SSH and Telnet client). Telnet creates a TCP connection to your NetBurner device. Anything you type in the command window is sent to the NetBurner platform, which in turn is sent out the NetBurner’s serial port. Anything received from the NetBurner’s serial port is sent to the Telnet console.

Telnet sends/receives data in plain text. In this article we will use the OpenSSL utility to perform the same type of functionality over an encrypted TLS connection from the PC to the NetBurner device.

To get set up for this tutorial, connect the NetBurner S2E device ethernet to the PC ethernet. Then connect the NetBurner S2E device serial port to your PC’s serial port. If your PC doesn’t have a serial port (and many don’t these days) you can use one of these Serial to USB adapter dongles instead.

For this test, we are going to have two applications open on our PC. First, we open a command (cmd) window which we will use to run OpenSSL and then, we open the NetBurner MTTTY serial terminal application (which is connected to the NetBurner’s serial port). Once OpenSSL makes the connection, whatever is typed in the command window will appear in MTTTY and vice versa. We are using a NetBurner SB800EX S2E server but any of our S2E devices will work.

You can get a free copy of OpenSSL from: https://www.OpenSSL.org/. If you don’t already have our MTTTY application you can download it here.

The NetBurner device is configured with an IP address of 10.1.1.161 (this value may change depending on your particular device) and is set to listen on port 443. Port 443 is an HTTPS port; this setting is critical as helps ensure that TLS is utilized for the connection. In our “How to create a virtual serial port” article, step 2 tells you how to discover the S2E device IP address and step 3 tells you how to change the listening port of the S2E device.

Now, back to our cmd window on our PC. The command to start the OpenSSL client is:

OpenSSL s_client -connect 10.1.1.161:443

The negotiation information will be displayed like so:

D:nburnconfig>OpenSSL s_client -connect 10.1.1.161:443
Loading 'screen' into random state - done
CONNECTED(000001A4)
depth=0 C = US, ST = CA, L = SAN DIEGO, O = NetBurner
verify error_num=18:self signed certificate
verify return:1
depth=0 C = US, ST = CA, L = SAN DIEGO, O = NetBurner
verify return:1
---
Certificate chain
 0 s:/C=US/ST=CA/L=SAN DIEGO/O=NetBurner
   i:/C=US/ST=CA/L=SAN DIEGO/O=NetBurner
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIB8zCCAVwCAQEwDQYJKoZIhvcNAQEEBQAwQjELMAkGA1UEBhMCVVMxCzAJBgNV
BAgTAkNBMRIwEAYDVQQHEwlTQU4gRElFR08xEjAQBgNVBAoTCU5ldEJ1cm5lcjAe
Fw0xNjA0MjgyMTEwNTNaFw0yNjA0MjYyMTEwNTNaMEIxCzAJBgNVBAYTAlVTMQsw
CQYDVQQIEwJDQTESMBAGA1UEBxMJU0FOIERJRUdPMRIwEAYDVQQKEwlOZXRCdXJu
ZXIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMJ3yMCW+BUTscJYtftk7eIg
w+mR7t9VJiPIE0CCoqlMitYH3HOKKSGU3oOUPonRnVIMOYpEAdM+7MDIk/gboUDS
MoEwn1aGgZNa1L04j+eXUA7P4/mDyuf1va06fuNOrCUDNv4B1/aemA2Uv5eoe/Lq
cmwSMj+YXKjfQI2+ey9vAgMBAAEwDQYJKoZIhvcNAQEEBQADgYEAiRSItSxnGIEk
dOPodbPGiOobS/p034y7JxZobQx7yGNSFuPzeHFXWoCbtAEAIEFsglVktlTfss4P
eG1wSmNvvNnOomsHZB2fsFSQpVAAU1jJioKuhtaUEtHaSSsSP+SSMdB870uXQS23
Oj7/xmxT9atovRpm3gJs/VctGammdZU=
-----END CERTIFICATE-----
subject=/C=US/ST=CA/L=SAN DIEGO/O=NetBurner
issuer=/C=US/ST=CA/L=SAN DIEGO/O=NetBurner
---
No client certificate CA names sent
---
SSL handshake has read 697 bytes and written 577 bytes
---
New, TLSv1/SSLv3, Cipher is AES256-SHA256
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : AES256-SHA256
    Session-ID: 00000002000044CA21993E5BCB70192225EAE7B351BF59FCFFD8683CEC9A3B33
    Session-ID-ctx:
    Master-Key: 48CA025A3CE59042F0DB5275FCEAD5EAB1E68749F45594B4704F8744C4414B993F9002F57E29D121322C4ACF1F1D2EC2
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1510772429
    Timeout   : 300 (sec)
    Verify return code: 18 (self signed certificate)
---

We can now send/receive data through the network or serial interface. In the screen shots below, “Hello from OpenSSL client” was typed in the OpenSSL window, and it appeared in MTTTY. “Hello from NetBurner SB800EX” was then typed in the MTTTY window and it appeared in the OpenSSL window. You will notice that OpenSSL echoes the typed characters whereas MTTTY does not.

As always, we hope you found this both informative and practical. TLS and security certificates are important to properly use and understand for your applications. References are provided below with more information. We’d love to hear your questions and comments.

Additional References:

1. https://www.forbes.com/sites/ciocentral/2017/05/08/security-surprises-arising-from-the-internet-of-things-iot/#1079d6f62495
2. https://www.iotforall.com/5-worst-iot-hacking-vulnerabilities/
3. https://en.wikipedia.org/wiki/Transport_Layer_Security
4. https://www.globalsign.com/en/blog/ssl-vs-tls-difference/
5. http://www.blinkingcaret.com/2017/02/01/using-openssl-to-create-certificates/
6. https://blog.didierstevens.com/2015/03/30/howto-make-your-own-cert-with-openssl-on-windows/
7. https://www.openssl.org/
8. https://knowledge.geotrust.com/support/knowledge-base/index?page=content&id=SO27347&pmv=print&actp=PRINT&viewlocale=en_US
9. NetBurner’s Serial to Ethernet Device Product List
10. Creating a Self-Signed SSL Certificate for Secure IoT Applications