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.
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.
Problem: Since Chrome updated a while back (version 58?), I'm not able to access my computer's development Express web server with HTTPS from a remote machine on the same private LAN.
I have created a self-signed certificate on the server (my laptop), and it works great from the same machine via https://localhost:8383 (the local SSL port).
In the past I could bypass the warning on a remote machine on the same network but it has stopped working.
I've gone through the steps of creating a local secure DNS server on my own router with DD-WRT, and self-signed a new certificate with SAN so I could use a DNS host name to access it without specifying an IP address.
I'm able to get to the page after bypassing the message that warns the site's SSL certificate could not be verified. But that's not good enough because while the site will load, the underlying websocket service I'm using on the same port does not work, and so the application loads but is broken on the remote machine. Still works on the local machine because the certificate is valid.
It seems the issue centers around Websockets within Express.
Any guidance would be greatly appreciated! This is a strictly secure environment that's meant to be used on a private network and it makes no sense for me to spend a bunch of money on a public certificate if that even matters.
Thank you.
It appears that the issue is with mobile Chrome and Safari on IOS -- I can get untrusted SSL certificates to work with websockets from another computer on the same network with the latest versions of Chrome and Safari. But on IOS (ipads and iphones), the page will load after being prompted, but Websockets FAIL to function whatsoever.
I've found a couple other people finding this issue.
My workaround for this problem was to revert away from SSL for my private network and completely avoid self-signed certificates.
In a private environment this is OK.
I'm trying to upgrade a websocket connection ws:// to wss:// using a nginx reverse proxy https://github.com/nicokaiser/nginx-websocket-proxy/blob/master/simple-wss.conf
but I seem to be having trouble with the certificate part. My server is located on the same network as the client. So Ideally I would want my users to log in to "https://example.com" and then the client makes a connection to "wss://192.168.1.xxx:xxxx".
As of now the browsers are blocking it because of NET::ERR_CERT_COMMON_NAME_INVALID. I don't really know to produce a self signed certificate that the browsers will trust on the local network. Googling only gives me answers on how to do it if my server would be accessed using a domain name but I will always connect to a local network IP. Help is appreciated!
To anyone coming across this I managed to solve it using this post outlining the architecture https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/
What ended up happening was that we set up a url pointing to a server running nginx which parsed the subdomain and redirected the connection to that url. For example: wss://192-168-1-142.mydomain.com redirects to ws://192.168.1.142 which makes the browser trust the connection
Does this work?
Your post is a year old now and browsers have become stricter since then. Usually, a browser will produce 'mixed content' errors if you access HTTP content from a HTTPS page, and the only way to get round this is to change the site settings to allow insecure content, which is scary for users in the face of a big warning message.
If accessing an HTTPS web address redirects to an HTTP local IP address, won't the browser still complain about mixed content?
I have a similar situation to you. I am writing a Progressive Web Application (PWA) to control network music players on a home network. The players only support HTTP but a PWA requires HTTPS for services workers to work and to allow the app to be 'installed'.
My solution is to run a local server on the home network which can talk to the players over HTTP. Then I can access this server over HTTPS from my browser so that the browser itself is not making any HTTP calls.
This works fine if the server is on localhost because localhost is a special case where security rules are relaxed. But if the server is on another machine, how can I create an SSL certificate since (1) it seems that local IP addresses are not allowed in the Subject Alternative Name (SAN) section of the certificate, and (2) I won't know in advance what the IP address of the server will be.
If your workaround works, then the local server can use HTTP instead so I won't need a certificate. The local server can register itself with a web server, and then the browser can connect over HTTPS to the web server, which would redirect to the IP address of the local server over HTTP.
But does this trick work?
My Azure VM (Win 2008 R2 Datacenter) runs IIS 7.5 and hosts a half-dozen Web sites. I obtained and installed a certificate to enable SSL on one site. I tested the certificate with the downloaded SSL Diagnostics tool, and all appears great. The tool sent a sample SSL handshake with perfect results (diagnostic info along with the contents of the tiny test web page).
However, the web page is unobtainable using https://... from a browser on either the server or client. Localhost:443 or the server IP address:443 in a browser on the server also fails. No error messages are received, the browser just waits and waits.
What could it be?
If I use a browser on the server and input https://ip address without 443, I get this error in the browser: ERR_CERT_COMMON_NAME_INVALID. "Your connection is not private. Attackers might be trying to steal your information..." and it shows the info from the certificate, like the issuer etc. What's the deal?
Ugh. I needed to open port 443 in the Azure Portal, in my Network Security Group. Another question on StackOverflow steered me to that solution!
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.