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.
Related
I am new to mitm.
https://mitmproxy.org/
AppServer1 (A windows 2016 server) has our IIS website application (WebApp1) running (its running fine without any problems currently).
I have added an SSL certificate as well, and it is loading fine without any issues.Chrome shows that it is trusted ("Connection is secure" when navigating from inside and outside AppServer1 server but "within the LAN". So far we havnt allowed access to internet users as of yet until the app is completely ready.)
We have a business requirement where
we need to intercept all traffic/requests from users from outide AppServer1
and send them to another application that we created (UserRequestDashboardApp),
and ALSO we need mitm to send it to WebApp1 as well.
I have read the articles multiple times and from what I understand, reverse proxy mode is the correct option to for our requirement.
WebApp1 is running on url - customappservice1.com, port - 443
I then started mitm (version 4.0.4) with the following CMD command
.\mitmdump -p 8080 --mode reverse:https://customappservice1.com
I get the status proxy server listening at http://*:8080
I dont seem to see any traffic in the terminal when I type customappservice1.com on AppServer1 chrome browser or any server browser outside AppServer1.
The WebApp1 pages load fine from outside and inside AppServer1 server but no traffic at all on the terminal
Can anyone please help me to capture the traffic on the terminal as an initial step before sending the traffic/requests to UserRequestDashboardApp AND WebApp1?
I have tried running mitm normally and it works fine(I can see traffic/requests fine in the terminal)
I launched mitm in CMD (It says Proxy Server listening at http://*:8080)
I set the
Windows server proxy to = localhost
Port = 8080
Did you try configuring your requests to use the mitmproxy's address ?
Also, web browsers may have use a separate proxy configuration from the operating system's. So you may try configuring Chrome's proxy settings.
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)
We use a secure connection (HTTPS) for our site, and we need the client to communicate with a program running in background (made with Qt), which the user installed previously. We intended to do that using websockets, using a certificate signed by the company.
The CA is installed in Windows and Mozilla databases.
Since the websocket runs on the client side, and the websocket server also runs on the client's machine, the connection is perfromed on localhost. Also, because we use HTTPS, we must also use WSS. We chose port 2424.
The problem is, Chrome, Firefox and IE consider the connection to be untrusted because it is on localhost (I think). If I open a new tab on https://127.0.0.1:2424, an error message appears; the browsers say the certificate is only valid on localhost, and that this could mean that someone may be trying to intercept data sent to the server (Firefox error code: ssl_error_bad_cert_domain).
The problem was that the certificate was issued to localhost, not 127.0.0.1. The websocket connected using the IP, not covered by the certificate, so changing the socket address from wss://127.0.0.1:2424 to wss://localhost:2424 worked, at least for Chrome and IE, but the connection is still refused in Firefox.
I'm using Fiddler2 to trace the https sharepoint calls. After starting the fiddler and browisng the https site it throws the error:
Access Denied (connect_method_denied):
....
This is typically caused by an HTTPS URL that uses a port other then the default of 443.
Any suggestion to resolve the issue will be very helpful.
Thanks,
Mac
That message is coming from your upstream proxy server. The question is why you're not seeing it in IE itself. Try disabling proxy chaining inside Tools > Fiddler Options > Connections and see if that helps.
I need to monitor HTTP traffic in my dev env which is PHP/Apache/Windows. But Apache seems to refuse the HTTP requests coming from fiddler which sits between the browser and Apache.
Error is No connection could be made because the target machine actively refused it
I suppose there should be some configuration on Apache which allows traffic via Fiddler. Can any one help me with it?
What windows version are you using?
What browser are you using?
Does the Apache reside on localhost?
Try disabling IP6 support (in the Fiddler options -> General -> uncheck "Enable IPv6 if available")
If apache is on localhost try http://machinename:port instead of http://127.0.0.1:port or http://localhost:port
Also check Fiddler know issues
I'm going to assume that your browser and Fiddler are installed on the same machine and the deve enviroment is remote. I would install Wireshark and capture the native browser requests, and the ones proxied through Fiddler. See what is different between them. I would seem they would be comming form the same src IP, so I would look at the various HTTP request headers, and see what is different.