I have ratchet webSocket server running and it works well.
the problem is that some of the connections are closing right after the handshake.
after searching stackOverflow and google I found out that I should use wss, because using ssl will prevent the connections from being closed. after some more reading I found that wss is not implemented yet in ratchet, and that the solution is to warp ratchet with stunnel. I searched again for help on how to implement this but found non .
how do I warp ratchet with stunnel? is there a better way to solve this problem?
I'm really a newbie will all the ssl issue.
thanks!
Set up your ratchet websocket to accept only local connections:
$webSock = new Server($loop);
$webSock->listen(8080, '127.0.0.1'); // local connections only
$session = $this->getContainer()->get('session.provider');
$server = new IoServer(new WsServer($session), $webSock, $loop);
Generate a server certificate. Nice instructions for ubuntu here.
Now install stunnel. Ubuntu instructions here.
Configure stunnel to use the new certificate and accept connections on a secure port and tunnel them to your websocket server:
cert = /etc/ssl/certs/server.crt
key = /etc/ssl/private/server.key
...
[websockets]
accept = 8443
connect = 8080
Start stunnel, and you should be off to the races.
Related
I am trying to use stunnel to turn a wss connection into a ws connection because wsServer doesn't support wss. The server is running Ubuntu, and the client I'm using is Chrome, if it matters.
This is my stunnel.conf file
foreground = yes
debug = info
output = /var/log/stunnel.log
[wsServer]
cert = /etc/letsencrypt/live/myurl.com/fullchain.pem
key = /etc/letsencrypt/live/myurl.com/privkey.pem
accept = 0.0.0.0:8443
connect = 127.0.0.1:8080
I'm trying to connect to it with a javascript call:
const socket = new WebSocket('wss://myurl.com:8433');
But I consistantly get a connection error:
(index):13 WebSocket connection to 'wss://myurl.com:8433/' failed: (anonymous) # (index):13
Here's what I've checked:
That my port forwarding/system firewalls aren't eating the connection. If I kill stunnel and setup a regular socket listening on either port 8080 or 8433, I can connect to that socket from the client machine.
wsServer accepts non-encrypted traffic, if I instead connect with ws://myurl.com:8080 it works fine
wsServer accepts connections from localhost just fine, which I understand is necessary when stunnel is running on the same machine as the server
Chrome accepts my cert when used for https pages under the same domain, so I don't think I have a cert signing error, but I don't know how to tell if the cert is related to the connection failing
Stunnel does not print any errors when starting up
Nothing gets printed to /var/log/stunnel.log, although the file was created after I added the output field to the .conf file
Any ideas about what else I can try? Is there some reason the cert that works for https wouldn't work with wss?
Do people recommend using ProxyPass through apache and avoiding stunnel altogether?
Not a solution, but a next troubleshooting step. Get yourself openssl and attempt to connect to 8443. This should spit back the certificate information and at least confirm stunnel is presenting the certificate.
openssl s_client -connect myurl.com:8443
It's been awhile since I configured stunnel, but IIRC you can't put a password on your key.
I have app (backend part) running e.g. on: https://bla.com:8443. I created a certificate for it via letsencrypt for domain bla.com.
When I tried to receive payments (webhook) from www.stripe.com I end up with TLS error. After some investigation I figure out that problem is with invalid certificate chain for https://bla.com:8443 and if I would run it on https://bla.com:443 everything would be ok.
I can't change it to port 443 because on https://bla.com:443 is running frontend part of the app.
I thought about 2 solutions, but my technical knowledge is quite limited so I am not sure if its possible:
create certificate for domain + port
run frontend & backend part on same port: https://bla.com:443 and configure apache2 to forward all /backend-api/* to https://bla.com:8443/backend-api/*
My question is, is any of the proposals possible and more importantly is there any better solution which I am missing?
Thanks for any suggestions!
A certificate is not bound to a port. It is perfectly fine to use the same certificate on port 443 and 8443. But the servers on port 443 and 8443 have a different configuration. If it works on 443 but not on 8443 this is likely due to some error in the configuration on port 8443. The fix is thus to have the correct configuration and not to work around with a different certificate or somehow to reverse proxy it from port 443.
Unfortunately details on how to exactly fix it cannot be given since the current configuration is not known.
Configuring the program to use fullchain.pem instead of cert.pem fixed it for me.
The Valhalla maps server docs assume that the server is always running on "http://[hostname]:8002"
(see https://github.com/valhalla/valhalla)
How can the server be configured to listen via SSL/https instead?
Is there any detailed documentation on how to do this?
Thnx.
To answer my own question:
After much reading & research I came to the conclusion that a practical way to achieve this is simply to hide the Valhalla port (port 8002) behind my Linux firewall and to expose port 443 (SSL) instead and have Nginx running on that port. Nginx then port-forwards the Valhalla request obj to the internal port 8002 and proxies the response back to the caller for the return journey on the encrypted channel.
Setting up Nginx to achieve this is fairly straightforward and the procedure is documented on many websites.
I'm trying to use tor, socksipy and ssl to proxy a ssl connection. My client looks like this:
import socks, ssl
s = socks.socksocket()
s.setproxy(socks.PROXY_TYPE_SOCKS5,"127.0.0.1", 9050)
ssl_sock = ssl.wrap_socket(s, ssl_version=ssl.PROTOCOL_TLSv1)
ssl_sock.connect(('127.0.0.1', 443))
The server just accepts connections and prints getpeername.
The peer name is always 127.0.0.1. It doesn't even matter if I give it a non-valid proxy. The client won't complain, it will connect anyway.
How do I make it connect through the proxy?
I managed to figure it out so I will leave the answer here for future reference.
The first problem was that I tried to connect to 127.0.0.1. As the request was proxied, the proxy would try to connect to 127.0.0.1, so it would try to connect to itself, not to me.
I had to configure my router to forward requests on port 443 to my laptop and then I replaced 127.0.0.1 with my routers IP.
After that was out of the way, I found out that socksipy doesn't play very well with ssl.
I had to call connect on the socket before wrapping it, otherwise I'd get a handshake failure. The code became:
import socks, ssl
s = socks.socksocket()
s.setproxy(socks.PROXY_TYPE_SOCKS5,"127.0.0.1", 9050)
s.connect(('127.0.0.1', 443))
ssl_sock = ssl.wrap_socket(s, ssl_version=ssl.PROTOCOL_TLSv1)
After that, everything was working fine.
I installed Wowza and is Streaming by this links:
HTTP:
http ://[my-ip]:1935/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
and also on
http ://[my-subdomain]:1935/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
When is config Wowza to be able to stream on port 80, it works again on these links:
http ://[my-ip]/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
http ://[my-subdomain]/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
but we must stream over SSL protocol.
means: HTTPS:
https ://[my-subdomain]/myapp/definst/mp4:00.Intro.mp4/manifest.mpd
We installed a wildcard SSL on our server and everything is working great. In general, port 1935 does not work over HTTPS! even when we add port 80 to Wowza, HTTPS connection is refused and we can't have streaming over https.
How can we stream over SSL on wowza? even with or without port 1935
Thanks
Yes, Wowza server supports streaming with SSL using StreamLock or your own SSL certificate.
You will need to set up a different port number for HTTPS. It could be that another process is using port 80. Port 443 is typically used.
From the Server tab, click Edit.
Click Add Host Port and fill in fields.
Check Enable SSL/StreamLock.
Save and re-start Wowza server.
Look in [install-dir]/logs/wowzastreamingengine_access.log for errors. It will give a clue as to whether there is a problem with the certificate, password or other.
I was recommend place a LB infront of my Wowza for SSL offloading so you can load the m3u8 over SSL. I was also told you can do that quite easily using HA Proxy for example. It is explained how to accomplish this here for RTMP but the same can obviously done with HTTP:
https://github.com/arut/nginx-rtmp-module/issues/457#issuecomment-250783255
Note, I have not tried this yet and I am unclear on exactly the proper use scenario. Nor, have I successfully enable StreamLock with my own cert nor the cert provided through Wowza. If I manage to do so I will update this thread. Hope this is helpful.