TCP: Client sends [RST, ACK] immediately after sending [ACK] to Server - wcf

I've got nginx 1.9.7 compiled against OpenSSL 1.0.2e running on Ubuntu 14.04.3 LTS (3.13.0-71-generic x86_64). I can connect to it with a browser no problem at all, and get a secure connection.
I also have a client who is running some Windows Server and is trying to connect to using WCF. They report they aren't able to connect to my service.
My nginx error log shows:
2015/12/09 17:38:27 [info] 10750#0: *6494 recv() failed (104: Connection reset by peer) while SSL handshaking, client: {REDACTED}, server: 0.0.0.0:443
Digging deeper, a Wireshark dump shows this pattern:
Client -> Server [SYN]
Client <- Server [SYN, ACK]
Client -> Server [ACK]
Client -> Server [RST, ACK] (connection closes)
Sniffing a successful request shows:
Client -> Server [SYN]
Client <- Server [SYN, ACK]
Client -> Server [ACK]
Client -> Server [PSH, ACK] (sends SSL Client Hello)
I'm not really a TCP guy, so I'm a little out of my depth in understanding what could be happening here. Any advice would be appreciated.

Turns out that the problem was the client's firewall :(
Edited to add detail: the client's firewall had been configured to block the domain and was therefore dropping the TCP connection as soon as it was established. Once the block was cleared, the issue went away.

Related

ClientHello Retransmitted many times followed by TCP DUP ACK during SSL handshake

we have one client and server our application running as bridge between client and server.
our module responsible for forwarding the traffic between client and server.
During SSL handshake i am trying to interrupt the client hello and respond to the client with serverhello.
we are able to interrupt and send the serverhello to the client but SSL handshake is failed.
captured the packets during SSL handshake.
i could see Server hello reached to the client interface but Client machine retransmitting the clienthello again and again could any one help on this what went wrong why the client not processing serverhello.

filezilla can't connect to vsftpd with TLS, but does work with unencrypted connection

I set up my server on centos7
From client side(not localhost), I can connect and transfer files to server with unencrypted connection but can't connect with TLS
It's my vsftpd.conf:
listen=YES
listen_ipv6=NO
pam_service_name=vsftpd
userlist_enable=YES
tcp_wrappers=YES
rsa_cert_file=/home/user/server/sync.crt
rsa_private_key_file=/home/user/server/sync.key
ssl_enable=YES
allow_anon_ssl=NO
force_local_data_ssl=YES
force_local_logins_ssl=YES
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
require_ssl_reuse=NO
ssl_ciphers=HIGH
pasv_enable=YES
pasv_min_port=50000
pasv_max_port=60000
pasv_address=1.1.1.1
and filezilla's errorcode:
Connection attempt failed with "ETIMEDOUT - Connection attempt timed out".
425 Failed to establish connection.
How do I solve this problem?
This kind of error typically happens when a data connection cannot be created to transfer files or directory listings. Such data connections are done using dynamic ports, where in case of PASV the port to use is announced by the server within the response to the PASV command.
Firewalls often employ helpers to scan the traffic and look for such responses announcing which port the client should use - and then temporarily allowing such access. In case of plain FTP without encryption the firewall can see the response and determine the port to open - then it works. But, in case of FTPS the control connection is encrypted and therefore the firewall only sees encrypted communication and cannot determine the port to open - then it fails.

TLS handshake fail, but communication is not closed

I have TLS program and I did some experiments on it.
I start confidential TLS server session and try to connect to it with pure Telnet client.
As expected, the handshake failed and the server is available to the next client but on the Telnet client side I didn't receive any indication that the handshake failed and that the server is accepting other clients.
I can see in Wireshark that even after the handshake failed the Telnet client can send strings; I see [PSH, ACK] from the client answered by [ACK] from the server.
Adding Wireshark snapshot, Telnet failed the handshake, Telnet keep sending messages, followed by success in the TLS handshake and more Telnet messages:
Why is the server ACKing the Telnet client if the handshake failed and he is accepting other clients?
As expected, the handshake failed ...
I cannot see a failed TLS handshake in the packet capture and I'm not sure how you come to this conclusion.
All I can see that the client on source port 60198 (presumable your telnet) is sending 3 bytes several times and the server just ACK'ing these without sending anything back and without closing the connection. Likely the server is still expecting data in the hope that at some time it will be a complete TLS record. Only then it will be processed by the TLS stack and then it might realize that something is wrong with the client.
... the server is available to the next client
It is pretty normal for a server to handle multiple clients in parallel. In contrary, it would be unusual if the server could not do this.

How to setup secure tunnel to allow a client to communicate to a websocket?

I need to allow client to connect to a websocket on server 10.0.4.160. The 10.0.4.160 server does not have SSL installed on it but it have a websocket that is running on port 8080.
I need to setup a secure tunnel to allow the client to connect to the websocket.
I installed the stunnel on my windows Server 2008 R2, And changed my stunnel.conf file to look loke this
[websockets]
accept = 8443
connect = 8080
verify = 2
CAfile = ca-certs.pem
client = yes
I am expecting to connect to the server on port 8433 and the stunnel will allow the connection to connect to port 8080
This is the code that I use in the client's console "Of course, the console is on a PC that is on my internal network"
var conn = new WebSocket('wss://10.0.4.160:8443');
conn.onopen = function(e) {
console.log("Connection established!");
};
conn.onmessage = function(e) {
console.log(e.data);
};
While on the server I open up a command line and I execute this
telnet localhost 8080
I get a command line and when I fire the code above from a console I see this in the server's command line
But few seconds later I get this error in the console
WebSocket connection to 'wss://10.0.4.160:8443/' failed: Error in connection establishment: net::ERR_TIMED_OUT
If I try to send a command using conn.sent('Hello') I get this error
VM289:2 Uncaught DOMException: Failed to execute 'send' on 'WebSocket': Still in CONNECTING state.
at Error (native)
at <anonymous>:2:6
at Object.InjectedScript._evaluateOn (<anonymous>:905:140)
at Object.InjectedScript._evaluateAndWrap (<anonymous>:838:34)
at Object.InjectedScript.evaluate (<anonymous>:694:21)
Additionally, I tried to turn on debugging in strunnel by adding debug = 7
This is what I got in the stunnel console. I don't understand what is wrong as the logs show that the client is connected but I can't send messages from the client to the server
2015.08.16 16:40:06 LOG7[36]: Service [websockets] started
2015.08.16 16:40:06 LOG5[36]: Service [websockets] accepted connection from 10.0.4.195:21963
2015.08.16 16:40:06 LOG6[36]: s_connect: connecting 127.0.0.1:8080
2015.08.16 16:40:06 LOG7[36]: s_connect: s_poll_wait 127.0.0.1:8080: waiting 10 seconds
2015.08.16 16:40:06 LOG5[36]: s_connect: connected 127.0.0.1:8080
2015.08.16 16:40:06 LOG5[36]: Service [websockets] connected remote server from 127.0.0.1:50891
2015.08.16 16:40:06 LOG7[36]: Remote socket (FD=668) initialized
2015.08.16 16:40:06 LOG6[36]: SNI: sending servername: localhost
2015.08.16 16:40:06 LOG7[36]: SSL state (connect): before/connect initialization
2015.08.16 16:40:06 LOG7[36]: SSL state (connect): SSLv2/v3 write client hello A
What am I doing wrong here?
How come the connection keeps failing?

netstat says 443 is open, but I cannot connect to it with telnet .. why?

I've built a self hosted wcf server, using wsHttpBinding. I'm running Win 2003 server R2 SP2.
If I configure it to listen on http://localhost:443/MyService, everything works fine. I can connect to http://localhost:443/MyService with Internet Explorer, and I get the standard "Bad Request" message
Now, if I try to switch to HTTPS, I'm witnessing a strange phenomenon.
Here's what I've done :
I've changed my wcf config file from http://localhost to https://localhost and from Security=None to Security=Transport (as explained in numerous wcf tutorials)
I've registered my HTTP port like this :
httpcfg delete ssl -i 0.0.0.0:443
httpcfg set ssl -i 0.0.0.0:443 -h ea2e450ef9d4...
Note that the certificate I've used is a "real certificate" (i.e. issued by a trusted CA, namely Comodo). The server responds to ping on the NS mentioned in the certificate.
Now, the following will timeout :
Microsoft Telnet> open localhost 443
Here's the output from netstat (The Pid '4' is the 'System' process):
netstat -nao
Proto Local Adress Remote Adress State Pid
TCP 0.0.0.0:443 0.0.0.0:0 Listening 4
And here's a screenshot from TCPView captured when I issued the open command in telnet :
alt text http://img26.imageshack.us/img26/3376/tcpview2si6.jpg
I'm a bit puzzled. To me, if netstat says the server is listening on 443, the telnet connection to 443 shouldn't timeout, and I should have at least a blank prompt, expecting me to type some encrypted stuff :)
So far I've tried to :
Redo all the steps from scratch following exactly the MSDN tutorial
Used port 10443 instead of 443
Disable the firewall
Use a self signed certificate
I don't know what to try next .. any ideas?
The telnet client is not going to know to send a properly constructed request to initiate an https handshake, so I imagine the ssl secured server is just waiting for more data.
The telnet client is certainly not going to know what to do with the response from a ssl secured server (it's certainly not going to prompt you for data to send along). Communication can only happen once the https handshake has completed.
You need to use a client that knows how to do a handshake. The openssl binary can do this out of the box.
Telnet cannot be used to comunicate with encrited webs.
Checkout this microsfot note. It says "NOTE: This example assumes that the Web server is configured to use the default HTTP port (TCP 80). If the Web server is listening on a different port, substitute that port number in the first line of the example. Also, this example does not work properly over an HTTPS/SSL connection (TCP 443, by default), because the telnet client cannot negotiate the necessary encryption commands to establish the SSL session. Although an initial connection is possible over the HTTPS/SSL port, no data is returned when you issue a GET request."
Update: Checkout this other note HOW TO: Determine If SSL Connectivity Is Not Working on the Web Server or on an Intermediate Device
As FerrariB said, telnet does not perform the negotiations necessary to open an SSL connection. Telnet knows nothing about certificates, nor encryption. Thus, you are guaranteed to not be able to communicate with HTTPS port 443 via telnet. You will have to find another way to do whatever you are trying to do.
Check out the Wikipedia page on TLS for example, where it says directly:
If any one of the above steps fails, the TLS handshake
fails, and the connection is not created.
This is precisely what you are seeing by trying to use telnet to communicate with an SSL endpoint.
in command prompt: netstat -nao |find "443"
the last columns show a number:
pic no.1
Now open task manager.find result number in 1st section in pid column (if pid wasn't enabled, choose it from view tab) program name show the program which uses the port.
disable the program that uses the port /in my case I stopped it from services