LabVIEW 2020 TLS Question

[adekruif]

With LabVIEW 2020 having TLS support (link below), does that mean we will now have the ability to use FTPS? I'm currently downloading LabVIEW 2020 community on my personal machine to see what is included in the palette as well as shipping examples.

https://forums.ni.com/t5/LabVIEW-Idea-Exchange/SSL-TLS-Support/idi-p/3314187/page/3?profile.language...

[rtollert]

We didn't update the FTP nodes, if that's what you're asking.

To be honest, the thought came to mind, but I thought the customer applicability was entirely theoretical. Do you actually possess an actively-used FTPS server?

[adekruif]

I was playing around with  the FTP nodes, and I can modify them to connect to the server but am unable to send/receive files. I'm a novice when it comes to this so it may be something simple that I'm missing/not understanding.

To answer your other question If I understand all the terminology correctly, then yes my company has a FTPS server that is active. 

[rtollert]

Are you in a position where you would prefer FTPS over SFTP?

[adekruif]

Back working on this, and have confirmed the details with IT on the server. I was mistaken in my earlier post and it is a SFTP server (Not FTPS as I originally thought).

If I understand correctly this means I will be unable to connect to the server as LabVIEW 2020 does not have native SSH support.

[adekruif]

Updating this again as I learn more about TLS and the server my company has.

I am able to connect to the server using port 990 in LabVIEW and can logon to the server. I can also transfer small files to the server, but when I try to transfer larger files (Anything above several KB) I get an error. Depending on the file size I seem to get a different error back from the server

550 The client and server cannot communicate, because they do not possess a common algorithm.
550 The message received was unexpected or badly formatted.

I also get error 62, which I posted about here: https://forums.ni.com/t5/LabVIEW/FTPS-Error-62/m-p/4078019

For those more knowledgeable with TLS, is there a configuration setting that needs to be updated that I am missing? Filezilla can transfer files no problem using the same credentials as LabVIEW so I am assuming there is something in LabVIEW that needs to be updated for FTPS? I am using the FTP VI's for this, and the FTP [STOR] VI is what returns the error. I have dug into the STOR VI and I cannot find anything that should be an issue for FTPS vs FTP.

[rolfk]

The FTPS protocol is not just a simply FTP over TSL but does require some additional protocol support in order to fully us TLS security. The server can be typically configured to allow unsecured communiction over the command and/or data channel, or to actually refuse that for either of the two (with the exception of the basic commands to establish a command connection, since an FTPS connection always starts out as unprotected FTP connection for backwards compatibility reason.

 Depending on that configuration it could simply drop a command channel connection that doesn't immediately switch to TLS after the initial connection establishment. Typically it will however allow at least some basic communication over unsecured connection. Once the client wants to switch to TLS secured communication it needs to send the AUTH TLS command, which will cause the server to transfer the command channel to TLS protected operation if supported (and the client should do of course the same by calling the Start TLS node in LabVIEW on the connection,  after having read the still unencrypted response from the server which returned the 234 response code that indicates that the desired AUTH mode is allowed and supported.

The client can then use PBSZ and PROT to define the protection mode to use for any data connection and the FTPS server can be configured to allow non protocted transfers (PROT C) or not whenever one of the data transfer operations is started (STOR, RETR, NLST, LIST, STOU, APPE) but it should not check for a valid protection when initiating a specific data transfer mode (PORT or PASV).

It is all described in RFC-4217 and the additional AUTH, PBSZ, PROT and CCC commands are described in RFC-2228.This means that the FTP library needs to be modified to support the additional TLS operation and issue the according commands. 

[adekruif]

Thank you! Thank you!

I have made some FTPS VI's of my own and following the RFC-4217 I believe I have most of it working. I send the AUTH TLS command and then when I receive the 234 back, I start the TLS. I then send the PBSZ 0 command, followed by the PROT P command. I get responses back for all these commands that match with the RFC. I then logon with USER and PASS, and get the expected 311 then 230 response.

I still get a 550 error when trying to send a file so I assuming there is something buried in the FTP STOR command that I still need to modify.

 

[rolfk]

Are you setting up the actual data connection with TLS too? I would expect that to be necessary if you enabled protection for the data link. FTP uses two different connections, one is the control link and the other is the data link. Depending if you use the PORT or PASV command, you need to setup a listener or initiate a client connection. I'm not sure how the listener would need to be setup to use TLS protection right from the start. Maybe Start TLS can also work with listener refnums but I'm not sure.

[adekruif]

After I send the PASV command, I can establish a TCP connection on the data port, but I can't figure out how to make it a TLS connection. If I don't make it TLS I get an error 62 from the TCP write that is writing all the data from the file in 1024 byte increments.

I did some more reading and found this in RFC-4217: 

To protect the data
   channel as well, the PBSZ command, followed by the PROT command
   sequence, MUST be used.

And further down found this (the connection is private):

If the data connection security level is 'Private', then a TLS
      negotiation must take place on the data connection to the
      satisfaction of the Client and Server prior to any data being
      transmitted over the connection.  The TLS layers of the Client and
      Server will be responsible for negotiating the exact TLS Cipher
      Suites that will be used (and thus the eventual security of the
      connection).

Which means that once I establish the TCP connection on the address/port that PASV returned, I need to negotiate the TLS for the data port before I can send data.

Now to see if I can figure out how to make that negotiation happen.