LabVIEW
C++ and Call Library Function Node
mrbean wrote:I'm trying to use the LabVIEW Call Library Function Nodes to call some openSSL functions found within the libeay32.dll and ssleay32.dll, however, the routines I need to call seem to return class objects (type SSL), etc. Can I even use CLF-Nodes to call C++? If so, how. Second, I started to look at CINs as a possible alternative, but I'm equally frustrated/confused. I have an openSSL.exe, and I have the two DLLs I mentioned above. I got these from the openSSL website, I did not create them myself. I saw a statement in the "Using CINs versus Call Library Function Nodes" help that said
"You compile the source code and link it to form executable code. If you already have a compiled DLL, this step is not necessary" My questions are these (about CINs).
1) If I somehow got Visual Studio 2008 to create me a DLL or EXE, would I be able to make C++ calls (create classes, etc)
2) How do I convert the above mentioned EXE or DLLs to .lsb files as required by CIN?.
3) Has anyone successfully created an SSL Client in LabVIEW?
The OpenSSL API is simply a standard function API. Even its implementation is entirely in standard C, to allow for a wide multi-platform support with the same source code.
It does however use object oriented techniques in that it uses pointers to structures that contain all the information and sometimes methods to describe the object in question and operate on it. However for the calling application those structures should be really treated as an opaque pointer. Opaque means it should simply see them as a void * and try to always use OpenSSL APIs to deal with those "objects". Otherwise if you access elements in those structure objects from your calling application, you need to start to worry about which version of OpenSSL you are calling and account for changes in the organization of those structures in different versions of OpenSSL.
As far as LabVIEW is concerned and if you can limit yourself to always use OpenSSL APIs to operate on those "objects" you simply configure those "object pointers" to be pointer sized integers in LabVIEW 8.6 and newer and 32bit integers in previous versions of LabVIEW.
Rolf Kalbermatter
Additional notes to my previous post:
Using OpenSSL in LabVIEW has one big complication for most regular use cases. OpenSSL expects to have direct access to the underlaying transport layer either through using the standard socket directly or through using a specifically setup BIO (block input/output) provider that implements an OpenSSL specific stream IO interface. So in terms of operation your application will access OpenSSL to read and write from the encrypted underlaying stream. However this stream can not easily be directed to the LabVIEW TCP/IP functions making it necessary to provide your own socket network layer too, calling into the Winsock (or Berkely socket on non-Windows platforms) interface. This gets soon very complicated and in fact not very practical to do directly in LabVIEW.
That said I have at one point started to develop a replacement VI library with underlaying DLL/shared library to replace the LabVIEW TCP and UDP nodes 1:1 that also supports SSL encrypted streams in addition to the unencrypted operation of the standard LabVIEW network primitives. This work has however stalled because of other more important tasks I have to do. I still intend to finish that in the next months but can't guarantee anything at the moments nor in what form I could make this available to the community. Most likely it will not be Open Source due to some undocumented LabVIEW features I am using in the shared library.
With all that in mind, if all you have to do is encrypt a TCP/IP stream for use in LabVIEW, I had great success with stunnel in the past, to connect to SSL encrypted https servers. Stunnel is an executable that sits on your or some other machine and simply acts as proxy between LabVIEW and the remote SSL enabled server turning the unencrypted stream from LabVIEW into an encrypted stream to the remote side and vice versa. Even the opposite is possible, with LabVIEW being the unencrypted server and stunnel turning this stream into an SSL encrypted stream for https clients, although with the new Web service server in 2009 supporting SSL, this is not really that much necessary anymore.
mrbean wrote:Rolf,
I don't know why I didn't listen to you from the beginning - probably because I didn't know what I didn't know. Anyway, now I'm ready to use Stunnel and, of course, I have some questions. On their website they say
... However, since C compilers are less common in the Windows environment, you can download these precompiled Windows binaries for stunnel.
Files with a .asc extension are detached PGP signatures. As of Stunnel version 3.8, Michal has begun PGP signing the Stunnel tarballs and executables. You can get a copy of his PGP public key on his home page. PGP keys for Brian Hatch can be found here, and the key used for Stunnel-3.x branch is available here.
I'm not sure what I need. I have MS Visual Studio 2008 if I have to compile things, but I've never used it, so this would be yet another learning curve. I'm thinking that HOW I plan to use Stunnel in LabVIEW would dictate WHAT I need, correct? So, what do I need. I think I've been convinced that CINs are not the way to go. So, would I use the Call Library Function Nodes, or the System Exec VI?
Once I understand that, I'll probably ask you some questions about your original reply...
What I have done in the past is simply implement a HTTP client in LabVIEW that supports proxy server communication and then use stunnel to let it handle the security aspects of the HTTPS communication. Basically you point your HTTP VIs to connect to the local stunnel port and let stunnel do the actual HTTPS encryption. Fairly easy to do, but your HTTP VIs need to support proxy communication (that is not really difficult, but you need to connect to the proxy port and send the fully qualified URI in your HTTP requests).
Thanks so much for your help.
The precompiled executables for Windows will relinquish you from having to compile the sources. The source distribution contains make files to be used with Visual Studio, but since you have absolutely no experience with using Visual Studio it will be easier for you to simply getthe executable download and use that. The PGP asc files are simply public keys of the authors so that you can verify the integrity of the downloaded exe files (or archivescontaining the exe) using an application like PGP.
So stunnel is an executable and stands as its own on your system. And you can start it from LabVIEW using System Exec, although I integrated it into the autostarted items of the system. The most tricky part is creating the correct configuration file for stunnel, though for simple HTTPS proxy operation it is basically leaving the default configuration.
mrbean wrote:I see in the man page for Stunnel that there is a -install, -start, etc. I can't seem to find any documentation that gives me a true step by step of what I need to do. I thought that downloading it was somewhat equivalent to installing. Apparently I need to install/start, but I don't know for sure. Do I have to add something to my Path so it can see Stunnel from anywhere? Also, the stunnel download gave me a stunnel.exe/.conf/.pem, and a libeay32.dll and libssl32.dll. Are those two DLLs the only SSL connection to Stunnel? I had (previously) downloaded openSSL_098 - do I need to configure Stunnel somehow to use that instead (i.e. replace the two DLLs with the 098 version)?
I've modified the stunnel.conf file a bit, and when I get errors, and the log window says (among other things) "sslVersion = SSLv3 for client, all for server", then I know it's not seeing my .conf file, since I told it to use sslVersion = TLSv1.
I'm obviously missing some glue logic!
The windows version of stunnel can run standalone or as a service. As a service it needs to be installed under Windows. This is what the -install option does. Then the service needs to be started. You can do that with the -start option or start the service from the service control panel. If you set the service to start automatically it will start everytime Windows starts up. All these options like installing and starting the service manually can only be done with administrative privileges.
You most simply just open a command line and go to the directory where you installed stunnel and simply enter those commands on the command line. This will also show you all errors that stunnel might encounter. System Exec is for the case where you only want to start the service in standalone mode. Here you should not try to add the directory to the path but instead pass the entire fully qualified path to System Exec.
The most recent version of stunnel 4.27 should also contain the 0.98k version of the OpenSSL library. It is best to simply leave the ones your stunnel version came with. libeay32.dll and libssl32.dll are the two DLLs that make up OpenSSL so that it ok. They provide the SSL functionality and stunnel sets up according BIOs to use by stunnel.
I'm using this in the conf file for https:
[https]
accept = 443
connect = 80
TIMEOUTclose = 0
and have client not enabled in the conf file. That is just about it.
When I then open a HTTP connection to "localhost" at port 80 and send a "GET example.com/index.html HTTP/1.0\r\n" I can contact a HTTPS server and get the unencrypted data stream on the LabVIEW side.
"example.com/index.html" is the URI from the "https://example.com/index.html" URL that you would enter in the web browser.
As to how this works with stunnel:
LabVIEW--->TCP Nodes===>stunnel--->OpenSSL--->Windows sockets===>network===>https server
The Windows sockets are initialized by stunnel and then passed to OpenSSL to be used.
In LabVIEW you would need to initialize the Windows sockets directly, then pass them to the openSSL layer and then call the OpenSSL layer. However to get a library in LabVIEW that works similar to the built in TCP nodes is quite a bit of work as I have found out 🙂
