Adding CIP Security to your device is no easy feat, we get it. We’ve done it, so trust us when we say we know! One part of the development process that is critical to your success is the debugging and testing phase.
When it comes to understanding TLS connection problems, sometimes it can be difficult, especially when it’s not clear what messages are actually being sent and received.
However, there is light at the end of the tunnel, since CIP Security uses an identical application layer as EtherNet/IP, once the (D)TLS handshake is complete, the messaging is the CIP that we all know and love.
CIP Security Debugging Tools
Wireshark is an open source network protocol analyzer and is the most important tool for any EtherNet/IP development as it can decode nearly all EtherNet/IP and CIP messages.
The most common issues that need to be debugged are the initial communication and the (D)TLS handshake. Several things can go wrong within the (D)TLS handshake when starting a new development and porting the SSL library to your device. The (D)TLS handshake is easily captured and analyzed as it is not encrypted, and Wireshark is able to decode all TLS and (D)TLS handshake messages.
Once the (D)TLS handshake is complete, everything is EtherNet/IP. When running EtherNet/IP over DTLS it’s still possible to capture and see the traffic in Wireshark, but it’s impossible to decode the traffic and see the exact contents if it is encrypted.
However, there are things you can do to help ease debugging issues when running CIP Security over EtherNet/IP.
One option is to use a NULL cipher suite, which provides for authentication-only communication and all messages will be in the clear and can be decoded by Wireshark. The CIP Security Specification allows for three NULL cipher suites, one each for RSA, ECC, and PSK.
In the cases when it’s not possible to change the cipher suite, i.e. in a real installation, it’s still possible to decode the actual traffic by configuring Wireshark with the key being used for encryption. This is clearly for development use only, but it is an option.
OpenSSL is an open source library that provides a plethora of SSL related functions, from a full SSL library to command line test and debugging capabilities. OpenSSL can be used to test TLS handshake functions in various ways. The most basic command is:
$ openssl s_client -connect <host_ip>:2221
Specific certificates and keys can be used as well:
$ openssl s_client -connect <host_ip>:2221 –cert certFile.pem –key keyFile.pem
Arguments are also available to specify the cipher suites to be used, and a PSK. There is also an s_server argument that allows OpenSSL to act as a server. All of this is useful when verifying the CIP Security objects and their interaction with the (D)TLS library.
The OpenSSL command line tool can also be used to test and debug other SSL protocol related items. It provides options to test protocol support to verify that your device is supporting the correct TLS protocol, v1.2. With some scripting, OpenSSL can be used to verify the required cipher suites are supported.
Another useful feature of OpenSSL is the creation and verification of keys and certificates. This allows you to create keys and certificates for use in testing and development.
Similar to OpenSSL, Nmap is a free and open-source network scanner. It can be used to discover hosts and services on a computer network by sending packets and analyzing the responses. Nmap provides a number of features for probing computer networks, including host discovery and service and operating system detection.
From a CIP Security device testing standpoint, Nmap can be used to verify the protocol support and implemented cipher suites in your device. This is accomplished with the following command line:
$ nmap –script ssl-enum-ciphers -p 2221 <host_ip>
The most important thing to remember is that outside of TLS and (D)TLS, all communications are standard EtherNet/IP; hence if you have an EtherNet/IP issue, it is likely going to be the same issue whether you are connected securely or not. When you experience issues with the EtherNet/IP application data or communications we recommend debugging this without running over (D)TLS.
Look into using Wireshark and OpenSSL tools to effectively test and debug your CIP Security applications. This is critical to ensure you’ve successfully added CIP Security to your device, and it will ensure your communications, support, and the TLS Handshake are all working properly.
To learn more about CIP Security, check out our Practical Guide for CIP Security Device Developers, where you can also find the debugging and testing section this post is based off.