01-24-2014 03:25 PM
I have been trying to use LabVIEW to access an https site through our corporate firewall/proxy and have been unable to get it to work. Does anyone have any experience with this and or know whether this should be able to be done?
I have successfully been able to get LV to access websites (http and https) without going through a firewall and thanks to posts on these forums figured out how to access an http site through the firewall but have come up blank when trying any https sites. Below are some test cases I have tried. All of these sites are easily accessed via browsers so it isn't due to firewall/proxy iblocking.
Any help would be appreciated,
-- Harold
Solved! Go to Solution.
01-24-2014 04:17 PM
This is a server authentication error, most likely because the proxy is returning an invalid SSL certificate. If the hunch is correct, you have two options: 1) installe a valid certificate to your proxy 2) turn off "server authentcation" on the HTTP Open Handle VI. We highly discourage the 2nd option as it opens you up to man in the middle or server impersonation attacks.
01-24-2014 04:31 PM
I tried option 2 of turning off verify server with False wired to the Open command as seen below but still get the same error. (Block diagram shown below). If I still get the error with verify server off, is option 1 still a possibility?
-- Harold
01-28-2014 01:19 PM
I should have asked up front... what version of LabVIEW are you using?
01-28-2014 01:55 PM
In addition to certificate problems, error 363507 also occurs when the SSL handshake fails, which would happen if the server is not listening for SSL on the a given port. I notice your two proxy examples are using the same port (8080). The proxy is would be listening on one port for HTTP and a different port for HTTPS. You don't see this problem when you are not using the proxy because the default port is different for HTTP (80) and HTTPS (443). Find out which port your proxy is configured to use for SSL, and try changing your URL to use that port instead of 8080. If that works, remove the verify server false if you can for security reasons.
01-29-2014 11:34 AM
I am using LabVIEW 2013 13.0f1 for OS X.
I am including the sample VI I wrote to test http and https access. Can anyone get this to work through their proxy? I'd be interested in hearing success and/or failures and particularly any differences made to get it to work.
Thanks,
-- Harold
01-29-2014 11:43 AM
I suspect the SSL handshake failing is getting close to the source of the problem.
We have the same proxy port (8080) for both http and https as far as I can tell. I have used wireshark to monitor the message flow and LV is doing something quite different than my browser does.
The browser opens a connection to the proxy (on port 8080) and then issues a CONNECT command to the proxy to access the ultimate location and then does a SSL handshake.
LabVIEW opens a connection to the proxy but then appears to be encrypting it immediately without a SSL handsake that I can see.
My speculation is that the underlying LabVIEW code is not really proxy aware and doesn't know how to issue a CONNECT command or equivalent. I'd be glad to be proven wrong with someone demonstrating this works for them (I've posted a sample VI in a previous post).
I can also post the wireshark message info if it would help anyone troubleshoot what is going on.
-- Harold
01-29-2014 12:51 PM
Okay, now I understand your setup. Unfortunately the HTTP client only supports tunneling proxies (sometimes called gateway proxies, those that accept a connection and then pass the request to another server without modifying it) because they happen without the client's involvement. It doesn't have support for HTTP proxies (sometimes called forward proxies) which, as you noticed, require the client to send a CONNECT request to proxy over SSL.
To be able to use the HTTP client here, you would need to configure your proxy to accept HTTPS connections on a different port using a valid SSL certificate and then forward those requests to the remote server like a tunneling proxy.