From Thursday, May 23rd (05:00 PM CDT) through Friday, April 24th (1:30 AM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TLS 2.0 or 1.3 support for LabVIEW

General question to the LabVIEW R&D team: what about introducing TLS 2.0 to TLS functions?

Are there any expected upgrades?

 

There is already TLS 1.3 at SystemLink as I see

(What Is the Version of TLS Used in SystemLink Server?: https://knowledge.ni.com/KnowledgeArticleDetails?id=kA03q000001ECxGCAW&l=cs-CZ)

 

And second in general for most experienced networkers:

How do you handle HTTPS with TLS 2.0 or even TLS 1.3 in LabVIEW?

Are you using some dll/.net solutions? 

Is there any other way to handle that than self-implementation or not use? 

😉

Well, maybe some idea of how to use SystemLink's TLS1.3 solution?

 

Kind regards

Ziggy

0 Kudos
Message 1 of 10
(472 Views)

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.

Rolf Kalbermatter
My Blog
0 Kudos
Message 2 of 10
(435 Views)

Well, TLS 1.3 is 6 years old so for the cybersecurity timescale sounds quite old;)

Let's leave TLS 2.0 then and be a bit more serious. 

 

TLS 1.3 is required for some devices that keep people safe. General requirements for devices using TLS 1.3 for two reasons: faster and more secure.

Several declarations about improving the quality of LabVIEW have already been published.

Like a lot of developers, I appreciate maps and sets, zoom, a faster compiler, and fancy controls.

 

Maybe someone in LabVIEW R&D will consider updating cybersecurity at the protocol level? Particularly if there is an implementation for SystemLink?

A significant part of communication between devices is moved to the network. Looks like the forgotten topic or even shot in the foot in the test systems area. 

 

Kind regards,

Ziggy

 

 

0 Kudos
Message 3 of 10
(420 Views)

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!

Rolf Kalbermatter
My Blog
Message 4 of 10
(402 Views)

@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... 


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 5 of 10
(383 Views)

Thank you very much for the specific overview of the topic. This valley is less shady now 😉

It would be great if someone would find time to put this info into the knowledge base.

 

Relating to the last part with Windows 11: this OS was presented in 2021, I have already seen test systems working on W11 a year ago.

Requests about TLS1.3 implementation in a test system, and questions about a possible switch to TLS 2.0 (from projects planning people), I have been receiving for over a year and I usually reply that it will for sure in the next version.  

 

Good to see that this is coming, thank you  for the beta pointing.  

 

0 Kudos
Message 6 of 10
(354 Views)

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.

Rolf Kalbermatter
My Blog
0 Kudos
Message 7 of 10
(350 Views)

Rolf,

 

Something got lost in the translation.
I state that Windows 11 has been in use in production systems for over a year, so stating that any need to wait until Windows 11, quote: "TLS 1.3 is not even an option without moving to Windows 11!" is already overdue.

Some of the produced devices that were using TLS1.2 and are tested by LabVIEW test systems were already switched last year and restricted to TLS1.3 due to cybersecurity policy. 


As for system preferences and measuring standards 😊 : I do not have a preferred operating system, I am obliged by the company I work for to adapt to the operating systems used in accordance with its IT policy.

This is the source of my questions which I have been receiving for a long time from the top shelf of my company

 

IT Security Guidelines for Transport Layer Security (TLS) v2.0 

Which as you will see, yes,  talks, yes, about TLS1.3 implementation. I think people asking questions got similar sources and let say, too shady scope.

 

I appreciate and respect your detailed answer, it not only cleared things up for me, also introduced new information in my head 🙂
I'm sorry if I offended anyone with my question, especially by introducing the TLS2.0 network mythology, that was definitely not the point of the question.

 

KInd (really) regards

Zbyszek

 

0 Kudos
Message 8 of 10
(321 Views)

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.

Rolf Kalbermatter
My Blog
0 Kudos
Message 9 of 10
(314 Views)

@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.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 10 of 10
(281 Views)