XirSys WebRTC secure connection - ssl

Setting up my simplewebrtc.html video chat room
Google Chrome browser decides http connections are no longer supported (https only)
I get my SSL certificate - and end up with this problem...
Mixed Content: The page at 'https://myURL.com/xsdk-master/examples/simplewebrtc.php?roomName=767' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://endpoint02.uswest.xirsys.com:8080/socket.io/1/?t=1450578074425'. This request has been blocked; the content must be served over HTTPS.
Seems self-explanatory I need to use a secure endpoint on XirSys end, but
I tried getting in touch with experts#xirsys.com - and they're out until December 28th, 2015. Anybody know if a secure endpoint exists? Please any and all help is appreciated!

You need to update the port on the endpoint to 443. The 8080 port you are using won't work on a secure page.
Regards,
Lee

Related

Do the webhook callback urls have to be https?

I'am currently trying to get messages from circuit working in my kotlin environment.
Registering a webhook works fine but circuit is not triggering my local webserver.
Does it have to be ssl/tls and if yes does the sandbox accept self signed ceritificates?
My Webserver seems to work if I call it myself local or over internet.
Does it have to be a certain port?
Thanks!
It can be http or https and if it is https, self signed certificates are accepted.
It has to be the default port for http (80) and https (443), you can not specify 8080 or 3000 or any other "local ports".
If you have a problem with that, I would recommend working with ngrok

How to fix "We're sorry HTTPS required" in Keycloak with reverse proxy?

When I try to hit Keycloak 6 behind an Azure gateway (reverse proxy) using SSL/HTTPS I get a "We're Sorry HTTPS Required" error in my browser. In the Keycloak log I see
[org.keycloak.events] (default task-2) type=LOGIN_ERROR, realmId=master, clientId=null, userId=null, ipAddress=x.x.x.x, error=ssl_required
I'm assuming I misconfigured something along the way but I can't figure out what it is.
I followed these instructions to set up SSL in Keycloak 6 behind a reverse proxy:
https://www.keycloak.org/docs/latest/server_installation/index.html#setting-up-https-ssl
I did NOT do any certificate creating/importing because the guide says "If you are not using a reverse proxy or load balancer to handle HTTPS traffic for you, you’ll need to enable HTTPS for the Keycloak server. This involves
Obtaining or generating a keystore that contains the private key and certificate for SSL/HTTP traffic
Configuring the Keycloak server to use this keypair and certificate."
My question is, do I need to do the certificate creating/importing anyway, even if I'm behind the reverse proxy? If not, any other ideas?
Please note: I am running the Keycloak stand alone server, not using it as an overlay on any other server container like Wildfly
Found the answer on this thread.
why is keycloak removing the SSL in the redirect uri?
Bottom line, you don't need to generate/install the cert AND there is an undocumented attribute
proxy-address-forwarding="true"

Stream with Wowza over SSL, Connection Refused or invalid response

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.

WebSocket with SSL

Is it possible to have WebSockets with HTTPS?
When switching to HTTPS, my WebSocket returns a security error and works perfectly with regular HTTP.
Below, a snippet;
socket = new WebSocket("ws://my_www:1235");
The WebSocket connection starts its life with an HTTP or HTTPS handshake. When the page is accessed through HTTP, you can use WS or WSS (WebSocket secure: WS over TLS) . However, when your page is loaded through HTTPS, you can only use WSS - browsers don't allow to "downgrade" security.
You can't use WebSockets over HTTPS, but you can use WebSockets over TLS (HTTPS is HTTP over TLS). Just use "wss://" in the URI.
I believe recent version of Firefox won't let you use non-TLS WebSockets from an HTTPS page, but the reverse shouldn't be a problem.
1 additional caveat (besides the answer by kanaka/peter): if you use WSS, and the server certificate is not acceptable to the browser, you may not get any browser rendered dialog (like it happens for Web pages). This is because WebSockets is treated as a so-called "subresource", and certificate accept / security exception / whatever dialogs are not rendered for subresources.
To support the answer by #oberstet, if the cert is not trusted by the browser (for example you get a "this site is not secure, do you want to continue?") one solution is to open the browser options, navigate to the certificates settings and add the host and post that the websocket server is being served from to the certificate provider as an exception.
for example add 'example-wss-domain.org:6001' as an exception to 'Certificate Provider Ltd'.
In firefox, this can be done from 'about:preferences' and searching for 'Certificates'

HTTPS Web(only)Proxy

I just read over node-tls-proxy (http://code.google.com/p/node-tls-proxy/), a https proxy. I like the idea of it, but I'm not getting why this proxy needs a local http server (see the local-proxy.js script).
So I was wondering if this is necessary?
My idea of the proxy was actually like this: Client -> HTTPS Connection to trusted Server/Proxy -> Internets
In this case network sniffing between the Client and the Server wouldn't (hardly) be possible because it would be ssl encrypted.
Thanks,
Seb
If I get the idea correctly, the goal is to set up a "remote" proxy in a location that one trusts to be secure. Your client shall only communicate with this remote proxy using TLS, the remote proxy is then allowed to do the actual (no longer encrypted) HTTP requests.
What you do on the client side now is this: you configure the "local" proxy in your browser. Since you type "http://..." in your browser even when using the proxy, your browser will initiate an unencrypted HTTP connection to the local proxy first. Then the local proxy will open an encrypted TLS connection to the remote proxy and forward your request over a secured channel.
This means you need the local proxy for the purpose of "transforming" HTTP into HTTPS requests because your browser will dutifully only use HTTP when asked to make an actual HTTP request.