LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

TCP/IP using SSL

Highlighted

Hi,

 

Does anyone has any idea on how to do SSL based TCP/IP communication.

Any help/ideas/suggestions would be appreciated.

 

Thanks,

Runjhun Agarwal.

0 Kudos
Message 1 of 14
(5,173 Views)
Highlighted

Runjhun,

 

I contacted NI about creating a secure TCP/IP connection using SSL.  They do not natively support it, but they did have an implementation for HTTPS, however the block diagram is locked and password-protected so it cannot be accessed for reference.  Below is my response from the application engineer that was working my service request.  They indicated that it could be done by making .NET calls and provided a few links on info to do so.  For my project, we ended up creating a .NET DLL that we called in LabVIEW which created the secure connection.

 

Hi Gary,

I have done some extensive research on your question about creating a LabVIEW TCP client which uses SSL 3.0 or TLS 1.0 .  It appears that LabVIEW does not have any native functionality to support this function.   While LabVIEW does not have a specific palette of functions dedicated secure connections using the above mentioned protocols, it may be possible to create such a connection using .NET calls in LabVIEW.  I was unable to find a step by step guide for creating this type of architecture.  Below, I have included two great resources which address TCP clients in depth.  There is a section on Client/Server Authentication, but this does not make specific reference to SSL or TLS.

Understanding Client-Server Applications -- Part I : http://www.ni.com/white-paper/4431/en
Understanding Client-Server Applications -- Part II: http://www.ni.com/white-paper/4433/en

The information in Part II may be more useful for your application.  I apologize I was unable to find a step-by-step solution for this problem, and I wish you the best of luck in creating this application.  In the future, if you have specific questions about calling .NET assemblies in LabVIEW or any other questions, feel free to create another service request at www.ni.com.  

 

 

Hope this helps,

Gary

 

0 Kudos
Message 2 of 14
(5,149 Views)
Highlighted

Looking at the diagram of said HTTPS VIs wouldn't help you anything to use SSL for standard TCP/IP socket connections. The HTTPS VIs call directly into a shared library that implements the HTTPS functions in C code by incorporating the OpenSSL library into the socket creation and then implementing HTTP on top of it.

 

The way SSL works there is no easy way to add SSL support to the standard LabVIEW TCP/IP nodes since SSL really is implemented in an intermediate layer between the actual socket interface and the TCP/IP application interface. All useful libraries that implement SSL are based on the assumption that they can be directly layered on top of the system socket API, and that is not available from the LabVIEW diagram. Without chaning the very fundamentals of the LabVIEW TCP/IP nodes itself, the only two ways that rest are either to implement whatever SSL based protocol you want entirely in an external C/C++ library, like the HTTPS VIs do and access it from there or reimplement the SSL protocol on top of the LabVIEW network nodes in LabVIEW VIs. The second option is obviously not really an option since SSL being a security feature is not something that you can trust if it just appears to work fine. And verifying that it is secure and can be trusted is something only a few experts can do and they are very unlikely to go and learn LabVIEW in order to assess the correctness of such a solution.

 

Several years ago I posted a library at lavag.org that used OpenSSL and attempted to offer an interface similar to the LabVIEW TCP/IP nodes but allowing to configure it to also include various SSL protocols underneath. However this project never really went further than a proof of concept, mainly because of lack of time but also because the complexity was rather high, also because of the idea to make it multiplatform across Linux, Windows and Mac. Add to that that LabVIEW added (less flexible) HTTPS support in recent releases and the main interest for such an API library mostly went away.

Rolf Kalbermatter
Averna BV
0 Kudos
Message 3 of 14
(5,124 Views)
Highlighted

Thanks Rolf.

 

Yes I saw your library. I even tried using it by changing the system dateSmiley Embarassed , but no luck.

So I had to come here and post this problem.

 

I guess I need to go ahead with Gary's solution and use a .net DLL that can do the TCP/IP as well as SSL communication for me.

 

Runjhun.

0 Kudos
Message 4 of 14
(5,107 Views)
Highlighted

Thanks a lot Gary.

 

Using a .net DLL was the last option I was looking for. But I guess there is no other option I am left with.

I have a question :

Did you implement the TCP/IP communication along with SSL in the .net DLL or did you use LabVIEW TCP/IP pallette and on top of that you used the SSL .net library.

 

Runjhun.

0 Kudos
Message 5 of 14
(5,106 Views)
Highlighted

Runjhun,

 

Yes the TCP/IP communication along with SSL was implemented in the .net DLL.

 

The DLL included the following functions: OpenClient, Read Bytes, Write Bytes, CloseClient

 

Sincerely,

Gary

0 Kudos
Message 6 of 14
(5,097 Views)
Highlighted

Hi Gary,

 

I have developed the code for SSL communication over TCP/IP protocol using System and mscorlib dll.

Everything seems to be working fine but there is some problem with the SSL Read function.

 

After establishing successful connection, am able to read data only for few exchnages appmx 10. After some time, its unable to read any more data.

The write function is working perfectly fine, so we cant say there's some problem with the SSL Stream Ref.

 

Can you please suggest me anything on this.

 

Attached is my Read function code.

 

Thanks,

Runjhun.

0 Kudos
Message 7 of 14
(5,031 Views)
Highlighted

This may not be the problem, but make sure you close all your .NET references. Right now you're leaving the references to UTF8Encoding, Decoder, and StringBuilder open. In particular you create a new StringBuilder without ever releasing it.

0 Kudos
Message 8 of 14
(5,010 Views)
Highlighted

I see that you are reading the SslStream Ref from a FGV/action engine and then storing it back.  Is the reference changing and is storing it back actually needed?  Not seeing the rest of your code or .NET implementation its hard to determine where the problem is.  I agree that closing the UTF8Encoding, Decoder, and String Builder references would be a good first step.  Is there anywhere where you are calling the Close Ref method on the SslStream Ref that is causing the reference to become invalid?  Put probes on the SslStream reference wires after the Read Ref and before the Update Ref and see if the reference number is changing when the error occurs.  Also is there a connection timeout that might be occurring?

 

Hopefully a few of these ideas might help.

0 Kudos
Message 9 of 14
(5,004 Views)
Highlighted

Hi,

 

I have updated the code by closing all the references and not updating the ref every time.

 

After probing, I confirmed that reference is always same and valid.

 

I have set the Read Timeout to 500 ms and so when the timeout occurs I get this error. This error am getting when it is successfully able to read. But once when its unable to read any further I dont get this error.

 

The error is :

"Error calling method System.Net.Security.SslStream.Read, (System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation.Inner Exception: System.IO.IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.

Inner Exception: System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond)"

0 Kudos
Message 10 of 14
(4,991 Views)