LabVIEW
TLS 2.0 or 1.3 support for LabVIEW
Your use of TLS 2.0 is a bit confusing. It seems some people use it to indicate TLS 1.2 but that really doesn't help. So far a post TLS 1.3 standard may be in the head of some researchers but there is really no official main stream implementation of that available anywhere. As such it is not anything you or me or even NI could worry about at this point.
As to supporting TLS 1.3, I do have a LabVIEW library based on OpenSSL 1.1.1 that can replace the standard LabVIEW TCP VIs and support IPv6. And I'm currently working on the side to upgrade it to use OpenSSL 3.0. But it is neither in a state that could be easily usable for others nor am I considering to make it available for free or open source it.
Well, I guess LabVIEW R&D might be slightly resource strained, although they seem to be getting more active recently. Around 2011-2013 a lot of resources were starting to move into the LabVIEW NXG project, which eventually was canceled just before Covid hit. Rather than moving those NXG resources back into the LabVIEW Classic project most seem to have moved on to other challenges. Then Covid hit and pretty much everything seemed to stop.
There are of course several areas where TLS gets involved in LabVIEW and they are unfortunately not uniform or even fully shared:
Native TCP nodes: I'm not sure what TLS implementation they are using, but OpenSSL is a good candidate as it is the only library that is applicable to all the platforms LabVIEW was released on at the time when TLS support was added (2020). Supposedly the Mac was using libreSSL, but that is for most practical purposes mostly simply relinking to a different library (or at least used to be back then, with OpenSSL 3.x things are starting to diverge more and more).
HTTP Client Library: This one uses under the hood an NI build of libcurl and that then uses an NI build of OpenSSL. Personally I think the choice to have NI private builds of these libraries is somewhat unfortunate. It is understandable in a way as the APIs, especially for the OpenSSL library are anything but static. They don't usually change in dramatic ways but enough to encounter very subtle bugs or even crashes when the library doesn't match with what the application was compiled against.
So it all takes a bit of work to upgrade. I know that for the HTTP Client Library they used and still use one of the OpenSSL 1.0.2 releases. The openssl.exe under <ProgramFiles>/National Instruments/Shared/nissl reports in fact 1.0.2u from December 20, 2019. That is used by the nicurl library under <ProgramFiles>/National Instruments/Shared/nicurl, which reports a version from 2024, so seems to have been rebuild for the LabVIEW 2024 installation on my machine, and which in turn is used by the ni_http_client library that provides the HTTP Client VI functionality.
You may be interested to search for a semi official replacement from Darren Nattinger which he calls Advanced HTTP Client library, but I'm not sure in how far he is using more up to data curl and OpenSSL libraries under the hood.
As for native TCP nodes, I'm afraid we have little options than to wait. If they use OpenSSL it shouldn't be a multi man year project to upgrade to OpenSSL 3.0. The API hasn't changed that dramatically but of course testing is a serious and very likely bigger effort than adapting any code to use OpenSSL 3.0 instead of 1.0.2.
Another interesting point is: https://learn.microsoft.com/en-us/windows/win32/secauthn/protocols-in-tls-ssl--schannel-ssp-
According to this if an application decides to use the Windows SChannel API to implement TLS rather than an external OpenSSL or LibreSSL implementation, TLS 1.3 is not even an option without moving to Windows 11!
@Zbyszek_StS wrote:
General question to the LabVIEW R&D team: what about introducing TLS 2.0 to TLS functions?
Are there any expected upgrades?
OpenSSL 3.0 is in beta for 2024Q3: https://forums.ni.com/t5/LabVIEW-Public-Beta-Program-in/Beta-Change-TLS-Updated-to-OpenSSL-3-0/m-p/4...
It sounds a bit like you are measuring with double standards. On one side you lament NI's lack of support for TLS 1.3 since it is out there for so long already. At the same time you state that Windows 11 having been presented in 2021 and being the first to offer TLS 1.3 is totally fine with you. No mention about Windows 10 not offering that since then either despite that it was still in active development until recently and in full support until next year.
And please can you give me any reference to that mysterious TLS 2.0? I would really like to learn what it is about, but all my searches for that turn out to be about TLS 1.2, which you could do in LabVIEW since 2020 and in the HTTP Client library even before that.
Thanks for clearing that up. It's indeed TLS 1.3 and the v2.0 seems to refer to the document talking about that. A little bit confusing but it's not like SSL/TSL has a history of very strict consistency. That TLS 1.0, which is already awfully outdated, is actually newer than SSL 3.0, has confused many people as can be seen in several threads here in these forums and elsewhere.
Just as you I'm also bound by policies and in my case it is that IT hasn't transitioned to Windows 11 yet. Computers are up to this day delivered with Windows 10 pre installed and if you want to upgrade, which I'm honestly not so keen to do but it was pretty much impossible to avoid on my home computers, you are on your own. It's irritating enough in itself as Windows 11 hides even more of the things that make it possible to configure the system beyond pretty colors and fancy gimmicks. So any application running on these computers that uses SChannel will not support TLS 1.3 at all. I haven't looked into what it would take to change my LabVIEW Advanced Network library to use SChannel instead of OpenSSL, but this fact certainly hasn't encouraged me to even consider that option so far. I did change certificate handling to use the built in Windows Crypt API instead of OpenSSL simply to have one worry less about managing my own certificate store.
@rolfk wrote:
Just as you I'm also bound by policies and in my case it is that IT hasn't transitioned to Windows 11 yet. Computers are up to this day delivered with Windows 10 pre installed and if you want to upgrade, which I'm honestly not so keen to do but it was pretty much impossible to avoid on my home computers, you are on your own.
Our IT just last month started giving the option to use Windows 11. Considering my current work computer is approaching 8 years (started in Windows 7, had to get a hard drive upgrade when forced to Windows 10), I plan to refresh at the end of the year with a Windows 11 system.
