I have configured the Websocket on my live server and I'm using SSL on live server. When I used following code on my localhost, websockets were fine.
ws://localhost:8080/server.php
Once I moved the file to the live server I have changed the code to the following
wss://IP:PORT/server.php
I have created a seperate port for web socket and configured on firewall TCP IN and OUT. However, I'm receiving the following error on console
WebSocket connection to ............ failed: Error in connection establishment: net::ERR_SSL_PROTOCOL_ERROR
Can anyone suggest me some solutions to overcome this issue
Basically when you are using wss you are just serving the WebWocket over SSL/TLS.
Meanwhile using a simple ws does not require a particular setup, wss does. Indeed you have to create a secure connection using a valid SSL Certificate when opening the communication.
If you certificate is missing or invalid the connection cannot be enstabilished therefore an error will be raised while attempting to start the communication.
So you can't just switch from ws to wss but also have to make a proper implementation.
You can find more details here, hope that helps!
here is what I did, I never able to install ssl in local, so I started using the w3cwebsocket client
https://www.npmjs.com/package/websocket
and test it in console using
node index.js
var W3CWebSocket = require('websocket').w3cwebsocket; var client =
new W3CWebSocket('wss://127.0.0.1:7000/'); console.log(client)
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.
please be patient with me because this is my first question ever on this platform. Thanks.
This is the code for a minimal server using the secure websocket protocol wss:// in godot (GDScript):
Gist on github
It works as expected when i connect from my home to my Virtual Private Server hosted in Germany or via VPN from other locations (e.g. US or Europe).
It does not work as expected when friends connect from India or Australia or if i reproduce it with a VPN (e.g. Argentina or Australia).
index.js:8 WebSocket connection to 'wss://(hidden):port/' failed: Error in connection establishment: net::ERR_SOCKET_NOT_CONNECTED.
I looks like the connection fails only if the physical distance between server and client is that long.
The problem might be related to SSL because everything works as expected when i use the normal websocket protocol. I tested the openssl -connect command from home and via VPN: both are good. I also checked my ssl configuration on https://decoder.link/sslchecker/. No issues detected.
This problem might be related to godot because I set up a nodejs secure websocket server, this works, even when i connect from Australia.
Now i dont really know how to proceed to fix this issue so i ask you to point me in the right direction.
Useful documentation on godot docs: WebSocketServer WebSocketClient
Edit 1:
After more tests it got more confusing:
When connecting from India with traffic on the internet connection:
WebSocket connection to 'wss://myDomain:port/' failed: Connection closed before receiving a handshake response
connnetion error
connection close request from server received... client will close the connection
disconnected unexpected
sometimes it even works (when network is not busy)
When connection from Australia: sometimes the ERR_SOCKET_NOT_CONNECTED or the Connection closed before receiving a handshake response connnetion error error comes up.
Edit 2:
only Firefox works, Chrome or Native client don't. I seems Firefox can establish the connection better if the distance is very big between server and client.
I'm setting up a WebSocket between a standard web page and a Tomcat v7.0.62 server. The connection works fine with Tomcat SSL turned on/off on Firefox, Edge and IE11. However, in Chrome (v66.03), the websocket only connects when I've turned on SSL on the server and connect via https. In Chrome, when I turn SSL off on the server and try to connect via http, it throws an error.
Here's the error Chrome throws when trying to connect via http with SSL turned off on Tomcat...
Error in connection establishment: net::ERR_PROXY_AUTH_REQUESTED_WITH_NO_CONNECTION
Here's my WebSocket connection code on the client...
var wss = "wss://";
if (document.location.protocol === "http:") {
wss = "ws://";
}
var wsURL = wss + document.location.host + "/status?sessionId=<%=session.getId()%>";
Is this something Chrome specific that needs special code on non-https websocket connections?
This is a Chrome specific behavior. Chrome doesn't allow unsecure websocket (ws) connections to localhost (only wss, so you should setup a TLS certificate for your local web/websocket server). But the same should work without any issues in Firefox and other browsers.
Please refer the Chrome bug report on Chromium regarding this issue. This particular problem is intentional, and they have made this change to make
Chrome more secure by preventing attacks against internal network devices and processes listening on localhost.
https://bugs.chromium.org/p/chromium/issues/detail?id=378566
Error in connection establishment: net::ERR_PROXY_AUTH_REQUESTED_WITH_NO_CONNECTION
It seems you might have a proxy with authentication in the middle, between the clients and the service. Depending on the proxy and clients configuration, it might let through SSL connections, but plain http will get filtered.
I can not confirm your issue. You can try the Echo Test here: http://www.websocket.org/echo.html
The website supports http and https, you can specify ws://echo.websocket.org and wss://echo.websocket.org. I have tried all combinations and they all worked for me.
My guess is that it is a configuration issue with your server or a problem with your browser extensions.
I have been trying to connect my Node.js Public Bluemix app to a DB2 server which is behind a firewall using the secure gateway service of Bluemix. When I try that by just using TCP everything works fine. I am now trying to use the TLS:Mutual Auth option and I can't make it work.
I followed this tutorial (https://developer.ibm.com/bluemix/2015/04/17/securing-destinations-tls-bluemix-secure-gateway/) and the tunnel seems to be created (I can see that at logs of the gateway client) but no data is coming through.
In the object Options which is a parameter of tls.connect, if I set rejectUnauthorized: true then I get "UNABLE_TO_GET_ISSUER_CERT" while I am using the generated certificates of the destination. If I set rejectUnauthorized: false, then it seems to work and the connection opens but nothing comes through, it just hangs. In both cases, I am using the same code that works when TLS is not set up and is based on the ibm_db node driver for DB2.
Has anyone experience with this, I have been struggling with it for some days now and any help would be much appreciated.
After some discussion, we determined that part of the problem was explicitly stating a piece of the cert chain in the CA, causing the UNABLE_TO_GET_ISSUER_CERT error to be emitted. This can be resolved by either adding the full chain to the CA or not explicitly adding anything to the CA (as the cert is publicly signed).
An underlying issue that was identified is that the ibm_db node driver for DB2 does not appear to work as expected for TLS connections.
I am unable to connect to socketcluster server from Firefox and chrome for android. Is there any solution?
The 'Socket hung up' error can mean either: The server was disconnected abruptly (e.g. the connection was lost for whatever reason). OR the client could not find the target server while trying to connect - It could be because the wrong arguments were passed to the client (E.g. don't match the server host, port, ...) or a network connection issue.
Are you trying to connect over 3G? Some 3G ISPs and some corporate networks block raw WebSocket traffic. If that's the case, the solution is to serve SocketCluster over wss:// - Proxies won't be able to block it if the connection is encrypted.
To make it work, you just need to provide a TLS key and certificate to the main SocketCluster constructor. Or you can put the raw SC server behind a TLS-enabled load balancer like AWS CloudFront, CloudFlare or similar (make sure it supports proxying WebSocket traffic).