I have a project runs on intranet, so I didn't buy any SSL certificate or domain name. Instead, I created self-signed certificate. I have two layer one of which is web service/websocket and the other is view. Everything is OK for all https connections, hence all pages, but browser could not make connection with ws or wss links(was tried ports 8443,443,8080). If I write link with localhost instead of my ip, it works perfectly, but then I cannot use it from another device. I created certificete as RSA/2048. My project runs on Ubuntu 18.04. Serverside was written in Java-Spring Boot.
If someone else need an answer, I got it from here. As summary, the problem is about Firefox, not about other browsers. Main reason is that Firefox do not accept certificate of wss link, in fact it is also the same certificate for the first connection link start with https. Solution is to go to the link started with wss by chancing wss to https and accept privilege of that link, and everthing works fine :)
Related
I'm trying to make a secure websocket.
When i try with ws:// it's working fine but not with wss://
I've enabled mod_proxy and mod_proxy_wstunnel.
Added those line to Apache httpd.conf
ProxyPass /wss ws://127.0.0.1:8090
ProxyPassReverse /wss ws://127.0.0.1:8090
But still not working.
The website is using https, so FireFox won't allow a connexion to ws on https (for security reasons).
I'm not very use with wss and i wonder what should i do next ?
SSL Certificate is not auto-signed, but made with Let's Encrypt.
I'm managing socket with PHP and Javascript.
Looking for hours to a solution... can't find yet... still trying...
Thanks in advance for your help...
Fey
EDIT :
I'm now using WebSocketD : http://websocketd.com/ as a service. I installed it and configured it with systemCTL (so it starts with the server).
Very easy to use and reliable, works perfectly for wss :) .
I tried to use Google Calendar API with Javascript, provided by a local Apache webserver.
Google provides a sample, which should work out of the box:
https://developers.google.com/google-apps/calendar/quickstart/js
Unfortunately, this sample works only, if I run my webserver on Port 8000, but not on Port 80.
If I run the webserver on Port 80, somewhere in the api.js from Google it throws an undefined exception, which I cannot catch or get any details on.
My OAuth Client ID is restricted to localhost:8000, localhost, localhost:80. Always with http:// in front of it.
Here is a screenshot of it. At the top, webserver runs on Port 8000 and it works fine. At the bottom, Webserver runs on Port 80 and it does not.
I did not modify the sample of Google, only inserted my Client ID. I am using Apache on Debian.
Does anyone have any ideas on that?
Since you didn't change any part of the code, the resolution I would suggest for your problem is to stay away from ports below 1024 as this opens up all kinds of security vulnerabilities. Use 4 digits ports: 8888,9999,4567,etc and you should be fine. Also, I'm assuming you've specified the ports in your clientID uri_origin in Google Dev console.
I have a web app in javascript that connects to a socket using socket.io and a Chrome Extension which connects in the same way and to the same server.
Everything works fine in most computers and internet connections, but one of my customer's computer is failing to have the Chrome Extension connected (the web app connects successfully).
By inspecting the extension's console for background.js (the script within the extension creating the socket connection) I see that it is not trying to connect to the right URL (my socket server) but to an unknown URL which seems to be a proxy: https://gateway.zscloud.net/auT?origurl=http%3A%2F%2Fmy_socket_server_domain...
Since this is happening only in that specific computer (from the 10 or so that I have tried with so far) using different internet connections (corporate network, guests network, mobile hotspot) and since other computers in those same networks DID succeed in connecting, I assume something installed or configured in the problematic computer is catching the connection request before it happens and tries to redirect it through a proxy.
Again, this happens only in the context of the Chrome Extension. The very same computer using the same internet connection DOES succeed in connecting from a web page in the same browser (Google Chrome).
Does anybody know what the problem could be? The client is not aware of having a security software (firewall, antivirus, etc...) that could be causing this, but it's a computer managed by his company so an admin could have done that for him. If that was the case, however, shouldn't the connection from the webpage be captured too? Is there anything specific to socket connections in Chrome Extensions that differ from regular web apps?
Thanks!
WebSocket connections differ from normal HTTP requests; they require a protocol upgrade after establishing that (some!) proxies may be unable to support.
I was at some point behind one such (transparent) proxy at work; however, it does not attempt to intercept HTTPS, which means I could use wss: WebSockets but not ws: WebSockets.
..which you should be using, anyway! With Let's Encrypt on the market, the barrier of entry for HTTPS is very low. If any sensitive data at all is sent through that connection, it's in your best interest.
For the record, that particular proxy is part of ZScaler which is a security solution. Sadly, it includes HTTPS MITM, so the above is unlikely to solve the problem (but should be implemented anyway!). It's set up as an OS-level proxy - if that setting is possible to change, or override with Chrome's proxy settings, that would fix it. However, that's going to piss off network security!
If you can't do that, then your client is a SOL and should complain up the chain about the security solution breaking legitimate applications.
Edit: I looked around and found this, which seems to claim that using SSL (that is, wss:) is enough. But that's from 2012 - perhaps before ZScaler was able to MITM all HTTPS traffic.
It should be possible to test whether wss: switch will work using https://www.websocket.org/echo.html - if it can connect then everything will work over wss:
I'm running a game which contains a server.js backend (which is hosted and run on my localhost), and the frontend is on a github website. The github page connects to the server on my localhost through the config which points to 127.0.0.1. I realize that I will be able to play this from my localhost this way, but will other people be able to?
Basically the index.html connects to the visitor's localhost to look for the running server.
A visual representation (sort of):
[nullwalker.github.io/index.html] ----> [localhost(127.0.0.1)/server.js]
What should I do to allow myself to play from the computer that's hosting the server backend as well as others being able to play?
You would need to host it in a live environment. There are ways via port forwarding to use your computers ip (gateway) to allow others to connect, however typically ISP's will try to stop you from using your dynamic IP statically. Safest bet is to launch a cheap VPS and host it there.
http://www.howtogeek.com/66214/how-to-forward-ports-on-your-router/
This article seems to explain port forwarding well enough.
As for the VPS, you can find extremely cheap ones really easily, if you do not expect a lot of players it should be fine, if you expect more then using your own connection is dangerous.
unless they have the same server running on their localhost, no. And they almost surely don't. You should get a host (digitalocean.com is very popular and good, but there are many others), and then run it there and connect to that instead of localhost
Is it possible to allow "insecure" https connection to load a kml file from server? Because now if it gets https error it does not load kml. Google Earth loads kml but asks for approval, api just does not do anything...
Nope.
This is one of my major gripes with the plugin. It'll only pull data off an HTTPS connection if there are no errors. This means that:
The SSL certificate must be valid
The SSL certificate must be trusted
There can be no authentication prompts
Passthru authentication that produces no prompting works fine
The only workaround I've found is to go in and manually trust the certificate on the client's machine. Make sure you trust the certificate in each browser that will be used (Chrome, IE, Firefox).
After speaking with Google directly about this -- I wonder if this is something that can be solved, or if it's just one of the "brutal realities" put it place by the web browser container.