Error on Google Chrome when connecting to Websocket proxy - google-chrome

I Have a simple back-end Kotlin application that runs a Netty server on a Google cloud virtual machine. It receives websocket connections and sends some simple messages to clients. I also have nginx server running on same machine, it listens to 443 port and redirects requests to my application (127.0.0.1:8080). Here is nginx configuration:
server {
listen 443 ssl;
server_name www.mydomain.com;
ssl_certificate /etc/nginx/certs/my-cert.crt;
ssl_certificate_key /etc/nginx/certs/my-key.key;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_read_timeout 86400;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $connection_upgrade;
proxy_set_header Host $http_host;
}
}
Ssl certificate in config is valid and certified by real CA.
Now I'm trying to write a simple front-end Angular app that connects to my proxy:
return webSocket({
url: `wss://www.mydomain.com/${path}`,
closeObserver: {
next: (event: CloseEvent) => { console.log(event) }
}
}).multiplex(() => {}, () => {}, () => true)
I am subscribing to an Observable returned by this method and printing incoming messages.
All this works fine in every browser except Google Chrome. (I tried Firefox, Opera, Chromium, Edge). Also everything works in chrome extension Smart Websocket Client. It even works fine in Chrome's incognito mode, but fails in ragular mode.
On chrome I get
WebSocket connection to 'wss://mydomain.com/something' failed.
CloseEvent that I log isn't very helpful, it just says that the code is 1006, the field reason is empty.
When I bypass the proxy and connect directly to my app with ws://www.mydomain.com:8080/something, it works fine on chrome.
I guess something is wrong in my nginx config, buy I cant really tell what. All the guides for configuring nginx for websockets say that this is how it should be configured.
I spent 2 days searching for information about this and didn't find any real answers to why this is happening and what can I do to fix it.
Does anyone have any ideas why is this happening?
UPDATE
Here is another interesting thing. I wrote a simple script that connects to my proxy, just like my Angular app, but using standard api.
let ws = new WebSocket("wss://mydomain.com/something");
ws.onmessage = (ev) => {
console.log(ev.data);
document.getElementById("result").innerHTML += ev.data
};
ws.onerror = (err) => {
console.log(err)
}
When I just open this file in chrome using file://, everything works. It connects to my ws server and prints incoming messages on screen. But when I run local Apache server and serve the same file on localhost:80, I get the same error as before in Chrome. (Other browsers and Incognito mode still work fine when the file is accessed through localhost)
So this issue doesn't have much to do with Angular.

You mentioned that in private/incognito mode it works, have you tried to disable all extensions and connect to websocket?

Related

Insecure forms and proxy servers?

I have a web application written in Apache Tomcat 8.5 that is proxied behind NGINX. i.e. I am using NGINX to offload SSL and serve static images etc. The app has been working reliably for years.
Now, the Chrome 87 update is causing a warning "The information that you’re about to submit is not secure" on every form submission. I've gone through the code with a fine-toothed comb and I can't figure out what could be triggering it.
The user gets to NGINX on https and the certificate is valid. NGINX forwards the request to Tomcat on port 8080. See config below.
The forms are submitted on the tomcat server as HTTP. But NGINX should prevent the browser from knowing that. It's https as far as the browser knows...
All tags are written as relative links or implied to be the same URL. e.g.
<form action="/login/login.do" method="post"> or <form method="post">.
Can anyone please point out something to look for? Am I missing a header or something?
Thanks in advance
from NGINX conf.d/site.conf:
location ~ \.(do|jsp)$ {
proxy_pass http://127.0.0.1:8080;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
}
Seems like there was a change in Chrome 87 to give warnings for mixed forms, so that is probably why those errors are appearing.
Perhaps there are some stray absolute links within your application which are still http, and are not being automatically converted when proxied by nginx?
If you are sure all your content is served over https, you can try enabling this header Content-Security-Policy: upgrade-insecure-requests (more info here) to force browsers to upgrade insecure connections automatically.
Had a similar issue, and in my case was the response from my app server being a redirect to a different scheme (http) than the one used by the client (https).
If it's your case as well, adding this to your location definition should do the trick. Assuming your app/app server respects this header, then it should respond with the proper scheme (https) on the Location header.
proxy_set_header X-Forwarded-Proto $scheme;
For completeness, excerpt for X-Forwarded-Proto from MDN docs:
The X-Forwarded-Proto (XFP) header is a de-facto standard header for identifying the protocol (HTTP or HTTPS) that a client used to connect to your proxy or load balancer.

Is someone also getting this error in Chrome 87.0.4280.88?

"The information you’re about to submit is not secure
Because the site is using a connection that’s not completely secure, your information will be visible to others."
We have started receiving this error today. I thought that this is a certificate problem, but it's secure
[]
Also there no warnings and errors in console page
What do you advise to do?
Same problem from today on chrome 87.0.4280.88.
Cert is ok and all assets are loaded over https.
My login forms are triggering this warning message, the form action url is relative so it's supposed to be sent over https too, don't know why this message is triggered...
Maybe try with absolute https action url.
[edit]
Check this tread -> https://support.google.com/chrome/thread/88331714?hl=en
For me it was the scheme on the location header when redirecting after successful login that was misconfigured on the reverse proxy, the app was sending back on http.
Fixed by adding these headers on reverse proxy conf on Nginx :
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Port 443;
Make sur that your app is aware of these headers too.
For example in a symfony app -> https://symfony.com/doc/current/deployment/proxies.html
This problem disappeared. I think they solved this problem, and now we don't have it)

NET::ERR_CERT_AUTHORITY_INVALID in Chrome not incognito and Firefox locally with valid certs on nginx

A couple of weeks ago we implemented the SameSite cookie policy to our cookies. If I want to develop locally, I needed a certificate to get the cookies.
We're running a Node express server and that is reversed proxied to an nginx configuration where we add the cert.
# Server configuration
#
server {
listen 443;
server_name test-local.ad.ourdomain.com;
ssl_certificate /home/myname/.certs/ourcert.crt;
ssl_certificate_key /home/myname/.certs/ourkey.rsa;
ssl on;
ssl_session_cache builtin:1000 shared:SSL:10m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4;
ssl_prefer_server_ciphers on;
location / {
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://localhost:9090;
proxy_read_timeout 90;
proxy_redirect http://localhost:9090 https://test-local.ad.ourdomain.com;
}
}
Now to the wierd part. We updated to Chrome 80 today, and all of a sudden I got an HSTS issue. I was unable to access site even if I wanted to (no opt in possibility). I tried to clear that inside chrome://internals/#hsts, and that worked. However, I still get NET::ERR_CERT_AUTHORITY_INVALID but I now have the opt in alternative.
Accessing it from Chrome Incognito mode works like a charm, no issues there. Same with Firefox, no issues there either. It says Certificate is Valid, green and pretty. Checked here as well: https://www.sslshopper.com/certificate-decoder.html and its 100% green.
I'm running Ubuntu 19.10 using Regolith.
My colleagues are using same cert, also Chrome 80, but they're running Mac, no issues there in Chrome.
Any idea? I tried to clear Browser settings, no change.
I have some great news!
We're using the same cert on our cloud dev environments (however, they are in pfx form). Locally I run Linux as mentioned, and I had to convert the pfx to a RSA file and a CRT file.
I entered our dev domain on this site: https://whatsmychaincert.com/ and it downloaded a *.chain.crt file. Together with my old crt file, and this command:
cat example.com.crt example.com.chain.crt > example.com.chained.crt
In Nginx I then referenced the .chained.crt file.
Now Chrome accepts my local, secure webpage.
We had the same issue and fixed it following petur 's solution.

chrome.proxy doesn't work for HTTPS

I am trying to route all requests using:
var config = {
mode: "fixed_servers",
rules: {
singleProxy: {
scheme: "https",
host: "localhost"
},
bypassList: ["foobar.com"]
}
};
chrome.proxy.settings.set(
{value: config, scope: 'regular'},
function() {});
This works wonderfully for all http:// websites but not https://. It seems that Chrome doesn't even connect to the proxy in those cases but simply returns ERR_EMPTY_RESPONSE (no packets in the VPN from chrome)
https proxies differ from http proxies. It is HTTPS protocol, not HTTP.
https://en.wikipedia.org/wiki/HTTPS
As i understand you run proxy on local machine, so you need https proxy software.
Smth like this https://www.npmjs.com/package/https-proxy-agent
http:// and https:// means protocol. So is ftp, pop, smtp, ed2k, bitcoin... an so on.
Don't use "https" scheme instead use "http"
If proxy server protocol is "https" then "http" scheme will work like "https"
Google Chrome version 103.0.5060.114 64 bit

Fiware - How to integrate Keyrock IdM, Wilma PEP Proxy and Orion Context Broker?

I read all the documentation of Keyrock and Wilma and I watched all the videos in the FIWARE Academy, but I still do not get success in this integration. I am searching for this since a few days ago, but without success. I think the FIWARE documentation could have tutorials, hands on...
I have a VM with Orion Context Broker and a container with Keyrock IdM and Wilma PEP Proxy. I am trying to generate an access token to grant access for an application, but I still did not get it. Besides, I would like to know how can I securely exchange messages between the Orion Context Broker and some IoT devices. Indeed, it is complicated to think about IoT devices having to access a screen and put their credentials to authenticate and to be authorized like the Keyrock IdM examples show. What do you sugest?
Seeing the answer of #albertinisg here, I found a bash script for token request. I changed it to use with my local instances and it worked.
After registering my application at FIWARE Portal (more information here), I had to make a POST request to http://idm:8000/oauth2/token (idm is my local instance of Keyrock). With this valid token, I can access the content in Orion.
import requests, json, getpass
TOKEN_URL = "http://idm:5000/v2.0/tokens"
USER = raw_input("Username: ")
PASSWORD = getpass.getpass("Password: ")
PAYLOAD = "{\"auth\": {\"passwordCredentials\": {\"username\":\""+USER+"\", \"password\":\""+PASSWORD+"\"}}}"
HEADERS = {'content-type': 'application/json'}
RESP = requests.post(TOKEN_URL, data=PAYLOAD, headers=HEADERS)
PEP Proxy (Wilma) configuration (config.js):
config.app_host = 'my_orion_ip'; //change to your Orion address
config.app_port = '1026'; //change to your Orion port
config.username = 'pep_proxy_credential_obtained_at_portal';
config.password = 'password_obtained_at_portal';
With the valid token and the PEP Proxy (Wilma) server running with this configuration, it is possible to control the access to Orion doing a request to PEP Proxy address. The PEP Proxy will redirect this request to IdM (Keyrock) so that IdM can verify the user/device credentials. If the credentials are valid, the user/device will receive a valid token and now PEP Proxy can allow the access to Orion.
For HTTPS communication, I configured a Nginx server to act like a reverse proxy (.conf file):
server {
listen 443;
server_name orion;
ssl on;
ssl_certificate /etc/nginx/ssl/orion.crt;
ssl_certificate_key /etc/nginx/ssl/orion.key;
...
...
location / {
#root orion:1026; #/var/www/yourdomain.com;
#index index.php index.html index.htm;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# Fix the “It appears that your reverse proxy set up is broken" error.
proxy_pass http://orion:1026;
proxy_read_timeout 90;
proxy_redirect http://orion:1026 https://orion;
}
}
I made a simple tutorial about the integration of FIWARE Orion, Wilma and Keyrock: https://www.slideshare.net/daltoncezane/integrating-fiware-orion-keyrock-and-wilma
I hope this answer can help someone else.
Regarding Orion, it depends on the interface to be secured, either the service API (i.e. the listening REST server that Orion runs typically at port 1026), the notification API or both:
Regarding service API:
Authentication & authorization: it can be implemented through PEP.
The following documentation introduces two PEP alternative
implementations. However, note that PEP doesn't work standalone, as it
also needs the IDM and Access Control to work. I understand that #Alvaro
can explain this topic in detail (with regards to Wilma PEP). It is out
of my knowledge.
Encryption: it can be implemented by a proxy acting as HTTPS-to-HTTP
bridge (e.g. ngnix) or by Orion itself using the -https CLI
parameter (which works in combination with -key and -cert). This
section of the documentation elaborates on it.
Regarding notification API:
Authentication & authorization: the current implementation of
custom notifications (see "Custom notifications" section in the NGSIv2 specification) allows you to include custom HTTP headers that
could be used for authentication (e.g. the X-Auth-Token header needed
by a PEP instance protecting your endpoint). Note that
this is currently done in an static way, i.e. Orion is not able
to interact directly with IDM/AccessControl to set the X-Auth-Token
value dynamically after expiration, etc. However, it would be possible to develop a
process able to do this and set the proper header (if you are interested
in this I'd recommend to check "How to add a custom header in outgoing notifications with Orion?" post).
Encryption: it can be implemented relaying in Rush component. This
section of the documentation elaborates on it.
UPDATE: since verion 1.7.0, Orion implements native HTTPS notifications (i.e. without needing Rush).
The following presentation shows you step by step how to create a FIWARE-Based IoT Platform and to secure it using a PEP Proxy, Keystone and Keypass.
https://docs.google.com/presentation/d/18LaWZSK4h2wncPF6hNAwK5MToLvJesR3XLrzsqrsmrw/edit?usp=sharing
I hope this helps
thanks