Add ability for Omnicomm to support secure connections to devices

Also, note from Franz Berkemeier regarding NiSource:

NiSource has an internal standard for TLS and they've asked how the planned backported DNP3 extension for SCADA 2021 is equipped to meet this standard.

If the expectation is there with ES2021, we need to assume it is much stronger for newer versions.

SNAM does require a release with Secure Sockets. This is required for the 2026 release.

Additionally, we are getting more questions about DNP3's ability to support secure sockets and the SAV6 standard is due out this year which I believe requires secure sockets.

"Their" response...

Seems TMW had responded but had gotten my email address wrong, here is there response: Yes. We do provide Linux and Windows target layers that support TLS using OpenSSL.

This idea has some relation to "Omnicomm to inform protocol of connection changes"

I was waiting for a response back from TMW before updating, but perhaps it is best not to wait. There are effectively two possibilities:

• The TMW library supports TLS, in which case Omnicomm will (most likely) need to be extended to allow the protocol to establish and manage the connection.

• The TMW library does NOT support TLS, in which case Omnicomm could possibly implement the TLS for us, and the protocol could just use the TLS connection. Alternatively, Omnicomm could still be extended to allow the protocol to establish and manage the connection.

I can't think of a third possibility, so I believe that enhancements to Omnicomm are required (hence my earlier comment of "I can't imagine a scenario...") and a high priority.

The remaining question is whether the enhancement can be a generic TLS that would work for multiple protocols (Secure Modbus, IEC870, DNP3, perhaps others), or whether Omnicomm would pass the responsibility to the protocol to manage the connection. I am not 100% certain that all TLS implementations are the same and whether Omnicomm can implement a generic enhancement. Perhaps an investigation, to establish requirements, is in order. But certainly there are other possibilities that would require protocol specific handling of the connection (imagine RSLinx for instance, or any library that implements the connection).

I will also resend my email to TMW, but I will note that on their website it says "TLS is supported for IP based networks". This implies to me that TMW does support TLS and is able to manage the connection but I'm not sure if that means that TMW must manage the connection. Further, there will be serious performance requirements around validating certificates used in the TLS process, so any Omnicomm enhancements need to consider this (should be able to validate 2000 TLS connections and still be polling all devices within 20 seconds of going hot). On OPC UA we also implemented the ability to pre-validate certificates so that upon going hot, the certificates were already cached and there was no need to re-validate.

Considering all of the above, I think there will be considerable incentive to allow the protocol to establish and manage the connection. Although, in the case of Secure Modbus, it would seem silly to require the protocol to implement a fairly standard TLS connection. So the ask is for both options.

FYI, SNAM has requested that we implement IEC62351-3 and IEC62351-5 (as part of IEC60870-5-104). These require TLS. Depending on how the Advosol library implements this we may require a solution to this ticket for 2025. Actually, I can't imagine a scenario in which we don't require a solution. The alternative would be for us to implement similarly to how we implemented Sparkplug or OPC UA, but those have the unfortunate side-effect of nullifying the Enterprise SCADA backup connection configuration, which SNAM needs (this is not a problem for Sparkplug B due to the broker architecture, but is a problem for OPC UA). So the need for this will very likely soon be very high, for a release by mid-2025.