I have been trying to connect to a partner's web service which is running on HTTPS default port 443. I had been under wrong impression that they had not open firewall ports for us because telnet from my server was unable to establish a connection. For example, I was typing:
$ telnet <vendor's host> 443
After waiting a long time (Around 15-20 seconds), it prints out that it connected but immediately also says that the connection closed:
Connected to <host>.
Escape character is '^]'.
Connection to <host> closed by foreign host.
However, on running the SOAP UI from the server and hitting a URL that is hosted on the same host and port works fine.
Just wondering why telnet connection gets tripped. Is there any kind of setting possible at the server side?
Maybe you're actually making a Telnet connection? But then it closes because the server finds no interesting conversation, because the server is expecting SSL negotiations to complete.
Understand that Telnet is not very different than TCP. ][CyberPillar: Telnet may discuss that.) So what would you expect the SSL server to do with a TCP connection? In the case of an HTTPS server (which is what I'm presuming, since you mentioned TCP port 443), I would expect the HTTPS server to want to immediately perform SSL negotiation. If a client does not successfully provide SSL negotiation, then the client may just be an attacker trying to use up the server's resources. So, the server won't be wasting resources by responding in interesting ways (like printing out an informative message). That would be the behavior that provides the most desirable results, most of the time. Most connections from clients who know what they are doing will be HTTPS connections by a client that does know how to negotiate SSL.
I would expect similar results from many other protocols that are designed to use encryption. Offhand, I don't know that this behavior is absolutely required by any specific technical specifications/requirements. However, what I do know is that the description you provide, which notes the behavior you experienced, is really not surprising to me whatsoever. Perhaps just from some experience I've had, it's what I would expect. The results you describe would not be surprising to me, even if your firewall was doing nothing. Consequently, I don't offhand know whether your firewall is effectively doing anything noteworthy with this traffic. Maybe the firewall is blocking it, or maybe the firewall is passing it to an HTTPS server which is just handling the connection in a way that you weren't expecting.
Related
I would like to seek for your advice if you have any idea or you have already encountered this issue “SSL/TLS handshake Issue” ?
To give you a summary, we’re getting an error the error below when connecting to Coupa (ERP) through HTTP.
Remote host closed connection. Possible SSL/TLS handshake issue. Check protocols, cipher suites and certificate set up. Use -Djavax.net.debug=ssl for further debugging.
We have several HTTP requests using the same HTTP config, but there’s this only one specific request that gives the said error. Also, this HTTP request works in postman. This occurs only in one Mule environment (UAT Environment). It works fine in our sandbox environment.
We are not sure whether the SSL connection/Handshake is closed on our end or server end.
If ever its on our end, how do we identify the fix for that?
If it’s on the server end, what should be the proof that we need to provide to them to say that the issue is on their end.
The server -Coupa in this case- is closing the connection just after it was opened by the client -a Mule application- probably before the client can send the HTTP request. The server could do this by any of a number of causes and the client does not receive any error messages or codes to indicate a reason. You will need to learn the reason from the server side.
Usual reasons are because an HTTPS connection doesn't match thee required ciphers suites or protocol versions accepted by the server, or because the client IP is not whitelisted. In those situations documentation from what's acceptable to the server side is useful. There could some other reasons that are known only to the server side.
A method to troubleshoot TLS connection issues is to do a traffic capture of the TCP packets, ideally from both sides, but if you don't control the server it will be only possible from the client. Another option if you are using HTTPS is to enable Java SSL Debug log in the Mule runtime to print the HTTPS connection information. You need to understand how to troubleshoot TLS to use these tools.
We are attempting to allow a client to access one of our QA environments. They are seeing the following error in IE:
This page can't be displayed
Turn on TLS 1.0, TLS 1.1, and TLS 1.2 in Advanced settings and try connecting to https://oursite.com again. if this error persists, it is possible that this site uses an unsupported protocol or cipher suite such as RC4 (link for the details), which is not considered secure. Pelase contact your site administrator.
I am not asking stackoverflow users to solve this problem.
I am asking the following very specific question:
Because we are seeing this error, does this prove that connectivity exists, i.e. our firewall is letting them through? I am thinking if they were blocked at the firewall they would simply get a timeout or perhaps a 403 or 500 error. since they are getting so far as to be able to see what TLS protocols are supported on the web server, I infer that they must be able to communicate with it on OSI levels 1-4. Am I correct? (I need to know whether to engage the networking team, which runs the firewalls, or to engage the application support team, which sets up the TLS configuration).
Note that SSL terminates on our IIS web server (we don't have SSL offloading).
Unfortunately we have port 80 blocked so we can only test on 443; otherwise I would suggest using http access to help isolate the problem.
... if they were blocked at the firewall they would simply get a timeout or perhaps a 403 or 500 error.
In order to send back a 403 or 500 error the firewall must have successfully done the SSL handshake with the client because the HTTP response (which includes the status code, i.e. 403, 500..) will only be sent inside the encrypted connection. There is no way to return a 403 or 500 inside the SSL handshake already.
Typical behavior with a firewall in between would be a timeout (firewalls drops packet) or more likely a connection reset or close (firewall resets or closes the connection). With a simple packet filter firewall it will usually block the TCP connection already, resulting in connection refused. But a firewall using DPI might actually let the TCP connection establish and only block after it gets actual data based on the content of this payload (i.e. application detection).
The last case might result in the error you see. But exactly the same behavior can be seen if there is a problem on the server side where the server simply closes or resets the connection. Some TLS stacks show such behavior (instead of sending back a TLS alert) when they cannot find a shared protocol version or cipher. Insofar you can neither conclude from this error message that the firewall is blocking the connection nor can you conclude that the server is causing the error.
I discovered today that if I ssh-forward the local port X to ssh server port Y, and no process is listening on port Y, I can still connect to local port X (I don't get the usual "connection refused" error).
I did my test with 2 different SSH clients on a windows host connecting to a linux server.
After a bit of reflexion, I came to the conclusion that from a pure network point of view, this is the behaviour I should expect: the SSH client is actually listening on localhost:X, so the connection is possible.
Nevertheless, this leads to a problematic situation in which I have an apparently connected socket that talks to nobody. Even sending data on the socket is a successful operation.
So my question: does the SSH protocol manage this situation in some ways, i.e. do I have strategies for detecting this situation? And if yes, may I hope support for this feature on some SSH clients and APIs (today I'm using ssh.net, that does not seem to offer this feature).
If not, how would you proceed for detecting the situation? Timeout on answer?
Thanks for your help,
Alberto.
The only logical behavior would be to close client connection if the server can't connect to the remote side, but that would not be much better than just a hanging connection.
Also there can happen situation when the SSH server is waiting for the remote connection for a minute or two before giving up, so the client's connection will be opened for this period of time anyway.
So there's actually no logical alternative rather than a hanging client connection.
How does a web-server serve its client using the same port(80) for a TCP connection. For a UDP connection, i understand that there is no connection, per se, so we can have multiple clients send packets to same port. If i try to use an already used port on my localhost, i get BindException.
One solution i see to this is starting a thread for each connection, but wouldnt this be cumbersome for site like google/yahoo where there a >100000 connections in each server?
What solutions do web servers employ for this problem?
Server listens on a well-known port (80) and delegate the request to a worker socket once it receive the request. That way it can serve the next request. You can write your own simple server to understand whats going on. Oracle site has a nice example code. [1]
[1] http://java.sun.com/developer/technicalArticles/Networking/Webserver/WebServer.java
first it creates a server socket;
ServerSocket ss = new ServerSocket(port);
then it listnes on the specified port and create a new socket once it accepts the request;
Socket s = ss.accept();
As shown in the code, it has a worker thread pool, so at a given moment you can control the number of request get served by the server at a given time. Others wait in a Queue may be.
You only have one port for listening, but a connection has two ports, one on each side of the connection. This pare must be unique.
So, say you connect to google.com port 80, then your connection will have some port on your machine, say 42312 and port 80 at google.com. You can see your connections with netstat -a. To get a shorter list: netstat -an| grep ESTABLISHED" Which shows all established connections without resolving their IPs to names.
AFAIK, Apache will start a new thread for every request, which is a big reason that event driven servers like Node.js are a little faster. Google and Yahoo also have TONS of servers and spread this large processing load among them. What Roger says also makes sense, although I'm not 100% sure on the details of how exactly google doing output on port 42312 would reach your computer at port 80 :P
I need a Reverse Proxy to front both Lablz Web server and SSL VPN Adito (SSL Explorer fork) by sitting on one IP/port. Failed to achieve that with Nginx. Failed to use Adito as a generic reverse HTTP proxy.
Can HAProxy fall back to being a TCP proxy if it does not sense HTTP traffic?
In other words can it fall back to Layer 4 if its Layer 7 inspection determines this is not HTTP traffic?
Here is my setup
EC2 machine with one public IP (Elastic IP).
Only one port is open - 443.
Stunnel is sitting on 443 and is passing traffic to HAProxy (I do not like to use Stunnel but HAProxy does not have full support for SSL yet, unlike Nginx).
HAProxy must be configured to pass some HTTP traffic to one server (Apache server which fronts the SVN server) and the rest of the HTTP traffic to our Lablz Web/App server.
All non-HTTP traffic must be forwarded to Adito VPN.
This traffic is:
VNC, NX, SMB
... and all other protocols that Adito supports
I can not rely on source IP address or port to split traffic into HTTP and non-HTTP.
So, can such config be accomplished in HAProxy? Can any other reverse proxy be used for this? Let me know if I am not thinking right about HAProxy and an alternative approach is possible.
BTW, Adito SSL VPN is amazing and if this setup works we will be able to provide Lablz developers with a fantastic one-click single-login secure VNC-over-HTTPS access to their boxes in the cloud.
No solution exists for this but via Adito - please prove me wrong. But please do not say that VNC over SSH is better. Yes, VNC-over-SSH is faster, more secure, but also is much harder (for our target user base) to setup and presumes that user is behind the firewall that allows outbound traffic on port 22 (not always the case).
Besides, Adito is much more than the remote access gateway - it is a full blown in-browser VPN, a software distribution platform and more. I am not associated with Adito guys - see my Adito post on our Lablz blog.
OK, first off, I'd use a simple firewall to divide all HTTP from NON-HTTP traffic. What you need is packet inspection to figure out what it is that is coming in.
Neither haproxy or nginx can do that. They are both made for web traffic and I don't see how they could inspect traffic to guess what it is that they are dealing with.
Update: Looked into this it a bit and with iptables you could probably use string matching to devide the traffic. However, that's all tricky, especially with the encrypted nature. A friend of mine discovered l7-filter and this looks like what you need. Let me know if this helps.