HTTP Client VIs and TLS 1.2

[Tgrogan]

Hello,

For the LabVIEW HTTP Client VIs, there is a "ConfigSSL.vi" where we are able to give it CA certification, key information, etc for security. Does this also support TLS 1.2, as opposed to just SSL? This is for LabVIEW 2019

In my project I'm logging data to an InfluxDB database via http protocols. This was working all very well and good when the database was hosted locally on the machine that was also doing the DAQ, and we were able to just use HTTP, not HTTPS. Recently we relocated the database to a remote server (instead of local to the machine) so now I need to use HTTPS (which I understand is fine for the HTTP Client VIs). However the InfluxDB server requires TLS 1.2 encryption or higher and I'm presently getting a "HTTP/1.1 400 Bad Request" response when I try to POST data to it. I believe I have the proper CA certificate (a ".cer" file) for it (though this is something I'm having a hard time verifying). And I shouldn't need any client certificate or private key since the server is not authenticating the client.

So I thought I would ask if it's the HTTP Client VIs that don't support it and that should buckle down to learn the .NET or proxy way of doing HTTPS.

I also learned through other forums that TLS has been in incorporated into the native LabVIEW TCP functions, but I was hoping to not have to (1) update LabVIEW, and (2) write my own HTTP functions from the TCP protocols when the HTTP Client VIs get me 95% there.

See below for how I am initializing the HTTP handle. The Authorization header is an authorization Token that is provided by the InfluxDB platform that allows me to push data to it via HTTP.

[DavidBoyd]

I've needed to support connections to HTTPS in the past, and just went looking at old initialization code I wrote (about seven years back, how time flies).  It definitely worked for me, I was connecting to SAP ME PAPI services, and like you, what started out as plain HTTP in development got switched to secure HTTP rather abruptly.

Your code looks similar to mine, mostly;  I had to implement basic auth so I had a plaintext username/password supplied to my OpenHandle.vi call.  Also, my call to ConfigSSL.vi happened immediately after the OpenHandle, and then I called AddHeader.vi for some custom stuff (Content-Type, Connection:Keep-Alive... ...nothing auth-related).  I *think*, but am not certain, that the OpenHandle call *may* add its own auth header, and I'm unsure if calling ListHeaders.vi returns just your added ones, or all headers, so perhaps try that and see.

One very important thing which should be obvious, but gets overlooked:  do you specify the port in your URL?  Because I seem to recall that the HTTP VIs don't make any assumptions (beyond port 80) just because you're specifying HTTPS.

Good luck, and sorry I don't have any better advice.

Dave

[rolfk]

The Config SSL VI may still use the SSL name, but I'm pretty sure it won't even use SSL anymore but at least TLS 1.1. The older versions are all considered obsolete and most libraries don't actively support them or will at least require the client to forcefully require its support by some extra option to prevent downgrade attacks by the remote site or a man in the middle.

I would be surprised if the NI library they use internally (basically a private build of libcurl for the HTTP Client implementation and I believe OpenSSL for the LabVIEW 2020 secure socket support for the TCP nodes) would not automatically support at least TLS 1.2. So your problem might be something else than missing TLS 1.2 support.

[DavidBoyd]

Running a bit of test code in LabVIEW 2019 SP1 (Win10 x64, though I doubt it's relevant) returns for me that the library versions are:

libcurl/7.61.0 OpenSSL/1.0.2o

I also ran the test under LV 2020 (20.0f1) and got the same result.

Though NI could use newer versions of these libraries when rebuilding annual or service pack LV releases, I'm sure they're reluctant to do so without an overriding concern (like a major security vulnerability getting patched).  OpenSSL is at 1.1.1k, and cURL is up to 7.76.1.  These are of course, up-to-the-minute releases.

OpenSSL history claims support for TLS 1.2 since release 1.0.1, so I'll echo @rolfk here; I don't think that's your issue, NI just didn't rename the "ConfigSSL" VI name.

Dave

[rolfk]

Never used libcurl but a switch from OpenSSL 1.0.2 to 1.1.x is not a drop in replacement. While some of the changes are seamless such as not needing to initialize the engines anymore explicitly (but the according functions still exist and do nothing if the engine is already initialized) there are other changes that definitely require modifications of the calling code, so not something you can just do as a maintenance task. 

[Tgrogan · Accepted solution]

Thanks @rolfk and @DavidBoyd. As it turns out you guys are correct. The HTTP Client VIs do automatically support TLS 1.2 even though the VI and name still mention SSL. I changed two things, and I'm not sure if it was a combination of the two or just one:

1) moved the "ConfigSSL.vi" to right after the "OpenHandle.vi" and before the "AddHeader.vi" to add the Authorization token. (as @DavidBoyd suggested)

2) Changed the CA certificate file from type ".cer" to type ".crt". In the "ConfigSSL.vi" help documentation, it shows an example using a ".cer" file which is why I had our InfluxDB manager provide me with that type of certificate file. However, when I ran the software, it would work fine so long as I disabled the option to verify the server (a boolean input). Of course this would pose as a security risk, but when I put that boolean to true, I'd get an error message saying there was an issue with the file and that it couldn't verify the server. I don't remember the specific error but through some more forum digging, it lead me to this article:  

SSL Certification and LabVIEW

and then ultimately to this article:

ERROR 363507 WHEN USING SSL ENABLED LABVIEW WEB SERVICES (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000019P6VSAU&l=en-US)

Even here it says it could be a ".cer" or ".crt". But because LabVIEW's default private key list is in ".crt" format I figured I'd give that shot. And thus it worked.

(also side note for anyone using HTTP post to push data to an InfluxDB database, always double check your syntax and data that you're pushing. Another issue I stumbled over is InfluxDB doesn't like empty strings or values written to tags and will give a "Bad Content" reply. It just added to the noise of my challenges above.)

Thank you guys for your help!