I am working on a small application on an embedded platform which has to send some classified information to a server. This connection to the server is encrypted using SSL. The encryption is tunneled trough a proxy - in this case a Zentyal proxy. The embedded application is written in C and the connectivity part is done with wolfssl and lwip.
The application works fine with Zentyal 5.1. But recently the proxy server was updated to 6.1 and now the connection is falling all the time. Debugging the issue, I have found the problem occurs when the application ask the server for a tunnel connection. What I see happening is that the application sends the CONNECT request to the proxy ...
... to which the the proxy answers with a 200 Connection Established.
But after that packet is received the proxy send another message with Proxy-Coneection:Close. Whith has the effect that the connection is shut down before the SSL handshake.
I have tried different configuration in the Zentyal (transparent proxy enable, disable cache, etc.) but the error remains the same. Also, I have added different HTTP headers like proxy-connection: Keep alive. But the connection is still being closed.
Maybe this is a problem with the 6.1 version. I have tried looking through the change log but there is no reference to any change in the processing of the connect request. Neither are there any known problems related to the way the connect is being handled.
Any advice?
Related
I have written a basic TLS client for use in embedded systems (written in C). It uses TLS1.2, and it works great in 90% of situations. I have it working fine for HTTPS, and also have it working with various FTP servers using implicit and explicit FTPS. This week I've encountered an issue when using it with Cerberus FTP and proftpd though. TLS handshake goes through absolutely fine when opening the control channel on port 21, but when using passive mode and opening the passive port, my client sends the TLS Client hello (and I can see the server reply with a TCP ACK), but the FTP server never replies with a Server Hello. Does anyone know of a reason why that might be?-I'm guessing that there is something different in the way Cerberus and ProFTPd have implemented TLS that my client doesn't cater to. My client hello on both connections is identical (apart from port number in tcp headers) and I am not reusing the session data. I don't have this issue when testing against vsftpd or filezilla servers.
Found the reason for the lack of response, and it's an interesting one if anyone is ever writing their own FTP Client and need to use FTPS with it. The FTP Client I had written issued the PASV command, and then immediately opened the data channel port before then issuing the STOR command on the control channel. This behaviour is fine for all FTP servers when using un-encrypted FTP. However, as I discovered, you have to beware when using TLS. With proftpd and cerberus FTP, the FTP server doesn't seem to attach a listener to that port until you issue the STOR command (or equivalent), so it won't negotiate TLS on that port until you've issued the command, whereas other FTP servers like vsftpd and filezilla are happy to negotiate TLS as soon as the port is opened. SO the solution was to open the port after sending the STOR command.
I am trying to connect from a NoMachine client on a Windows 7 machine to an OpenSUSE machine. I can only connect via NX however I keep running into Error 138:Connection Timed out. I can connect via SSH on my Command prompt however Seem to be unable to connect via here. Does anyone know a solution - been doing this since morning with no light in sight!
Routers supporting UPnP or NAT-PMP are configured automatically to pass connections to NoMachine and all required information is displayed at initial screen (Welcome to NoMachine).
Routers not supporting UPnP or NAT-PMP and Firewalls have to be configured manually to pass traffic to port 4000 (NX protocol), 22 (SSH protocol on Linux/MacOSX) or (4022) (SSH protocol on Windows).
So, check the configuration first.
I have a similar issue setting up my ftp server.
There are a couple of possibilities why the connection was not established, but in my case, and perhaps yours, you must allow the service you're trying to execute in your firewall settings.
In my case I allowed the ftp port and some other specific port for tcp communication.
This (and the proper service, router, etc setup) allowed the communication to be established.
I have setup a nagios distributed monitoring system environment and i am able to send passive checks to Nagios server using send_nsca. When i look at the handshake between Nagios Client and Nagios Server, i see that Nagios Client is establishing a tcp connection to Nagios server whenever it has something to send and terminating the connection once the client is done sending the information. I want the tcp connection to stay up forever instead of terminating every time after data transfer is done. Could anyone please let me the know the process to make this happen?
You cannot do this without modifying the standard NSCA daemon. Normally, it will time out and that's why the NSCA client reestablishes the connection.
I've implemented send_nsca in both Perl and Ruby, and in both cases cannot make a persistent connection work.
A better solution, though, if you are using Nagios 3.x is to install the livestatus module (part of check_mk). This allows passive checks to be submitted, but supports a persistent connection and a whole lot more. We've moved to using this instead for many cases.
With Selenium 1 there was the possibility to enter a URL to stop the server:
http://:/selenium-server/driver/?cmd=shutDown
Is there a similar way in Selenium 2?
I tried the following URL to check whether the server is running:
http://:/wd/hub/
but that only returns an HTTP ERROR 503 (service unavailable).
Is there any other URL I can access to verify that the server is running?
The Selenium server in 2.0 contains all of the same code that was in Selenium 1, so checking for, say, http://localhost:4444/selenium-server/driver?cmd=getLogMessages will test for the existence of the server. Likewise, you can issue http://localhost:4444/selenium-server/driver?cmd=shutDownSeleniumServer to shut the server down.
There was recently a new /status URL added to the JSON wire protocol used by the 2.0 parts of the server, but I'm not certain it's been implemented in the remote server just yet. This would be accessed by http://localhost:4444/wd/hub/status, when implemented. Additionally, there isn't yet an equivalent shutdown URL in the wire protocol.
First off, I don't know if this is possible, but let me describe my scenario.
I have a set of WCF services, a SQL Server 2008 Database all running on Windows Server 2008. All of this works fine when I am connected to my LAN, however I am going to be using this box for a demo, and I would like to make it work in standalone mode (ie, not connected to any network).
When I attempt to do this in standalone mode, the SQL Server database appears to be working (I am able to retrieve data). However when I try and insert data within a transaction scope from the WCF services, on the client side I am getting a communication fault exception. Checking the windows event logs, I see that there is a message along the lines of "MSDTC encountered an error while attempting to establish a secure connection with system ".
Does anyone know what needs to be set on the DTC to allow this to work
In context of what happened, the error now makes perfect sense.
The problem here was that somewhere in one of the applications deployed to the server, we were referring to a hardcoded dns name that was inaccessible by this server (since it was standalone). From what I understand, the DTC attempted to flow the transaction, failed to establish the address from the computer name and that was where it bombed out. As the application was a WCF service, the error was pretty well obfuscated, but eventually we traced by turning on service tracing.
Hope that helps anyone else that encounters a similar error. Beware the hardcoded values.
It could be to do with the connection string the WCF services use to connect to the database. Try using Data Source=. or Data Source=localhost, to ensure you are using the loopback network adapter (127.0.0.1).
Is there a firewall running on the Windows machine? Is the server part of a domain?
I would also suggest looking at the security settings dialog of MS DTC (Component Services MMC plugin). Try setting the "Transaction Manager Communication" to "No Authentication Required" and ticking most other options as a base line.