HTTPS connection not working

I don't know if it is the fault of the obs-websocket itself or the obs-websocket-js I'm using but I can't seem to get a working HTTPS connection (I need it because github.io pages are all HTTPS).
I tried to change the request from 'ws' to 'wss' but there is no respond.

obs-websocket currently doesn't support TLS connections. This isn't planned for now but certainly will be at some point.

Just a comment on this, if you attach a domain name to your github pages that doesn't support TLS then github will fall back to http. Otherwise it enforces the use of TLS with no way to disable it.

Yeah, I know that but I didn't want to get a domian for this because obviously it costs money and I think that's not worth it at the moment, maybe in the future :)

ngrok.io can help in the meantime. It can act as a proxy for non-secure traffic that can be secured.

The quickest solution is to probably put an stunnel in front of it to get at least basic TLS. This is not for beginners, you have to know about SSL certificates.

; Certificate/key is needed in server mode and optional in client mode
cert = /path/to/cert-or-cert-chain.pem
key = /path/to/private.key

; Protocol version (all, SSLv2, SSLv3, TLSv1)
sslVersion = TLSv1
; no, we don't want SSLv2
options = NO_SSLv2
; Some extra strong ciphers
ciphers = ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM

; Some security enhancements for UNIX systems - comment them out on Win32
chroot = /var/lib/stunnel4/
setuid = stunnel4
setgid = stunnel4
; PID is created inside the chroot jail
pid = /stunnel4.pid

; Some performance tunings
socket = l:TCP_NODELAY=1
socket = r:TCP_NODELAY=1
;compression = zlib

[https]
accept  = <local IP>:8443

; obs-websocket server listens on port 4040
connect = <local IP>:4040

Chrome may silently fail if the common name on the certificate does not match the DNS name you are connecting to. And before you think of using the IP rather than a dns name, some browsers implicitly reject the IP cert if it's not in both the commonName and subjectAltName because they didn't follow standards (cough, IE, cough).

Basically, don't expose obs-websocket to the public unless you REALLY know what you are doing, and you are going to do it right. It's not for "your friend to control obs cuz it'd be cool".

If this ever happens, it'll need either a way to plug in a certificate, or some way to tell the browser that a self-signed cert is acceptable. Easier is to set up a custom subdomain with GitHub Pages, which I've done for my websocket client. Don't need to buy an additional domain as long as you have a domain that you can create a CNAME under.

(FWIW, it's a remote volume controller.)

Agreed. Doesn't matter what domain it is either; $1 a year or less if you find a sale.

You can use nginx as reverse-proxy that supports HTTPS

I would also love this feature. Has there been plans on revisiting this request?

+1 for SSL.

Is this feature still on the list?

+1 for SSL support

Edit: I changed my mind, some documentation might be a better solution: #26 (comment)

Needs SSL support for web integration.

I don't think it's right for obs-websocket to try to support SSL, because it would require setting up a certificate and having the appropriate private key - which is going to have to be readable by the OBS process. Much better, IMO, to do this externally. Maybe what we need is a simple recipe (for each of several OSes) showing how to set up an encryption proxy?

@Rosuav

After testing some solutions, I have to agree with @Rosuav. It might be useful to add something like this to the Readme:

Running remote or over a TLS connection

If you want to expose the websocket connection remotely and/or use a secure TLS connection, the easiest approach is to use ngrok or pagekite. Here is an example how to expose the OBS websocket port with pagekite:
$ python pagekite.py 4444 NAME.pagekite.me
Then, use wss://NAME.pagekite.me/ to connect to your OBS instance from anywhere in the world.

I submitted a PR to add WSS support to obs-websocket-js here: obs-websocket-community-projects/obs-websocket-js#201. It should be easy to add to obs-tablet-remote as well.

Edit: it's already working in obs-tablet-remote, example URL: https://t2t2.github.io/obs-tablet-remote/#!auto&host=wss://NAME.pagekite.me/

That seems pretty simple. Have you checked that those two services work happily with websockets, and don't, for instance, disconnect idle connections after five seconds?

Yes I did, I'm using it myself on 1h+ livestreams. Pagekite is open source so you can also run your own managed instance.

@Rosuav

After testing some solutions, I have to agree with @Rosuav. It might be useful to add something like this to the Readme:
Running remote or over a TLS connection

If you want to expose the websocket connection remotely and/or use a secure TLS connection, the easiest approach is to use ngrok or pagekite. Here is an example how to expose the OBS websocket port with pagekite:
$ python pagekite.py 4444 NAME.pagekite.me
Then, use wss://NAME.pagekite.me/ to connect to your OBS instance from anywhere in the world.
I submitted a PR to add WSS support to obs-websocket-js here: haganbmj/obs-websocket-js#201. It should be easy to add to obs-tablet-remote as well.

Works perfectly! It wasn't working at first as I was adding port 4444 to the wss:// address, but works once I removed it. Thanks!

@Niek

@Niek done! 612bd99

For LAN usage, pagekite and (I think) ngrok are both massive overkill, and also they force traffic to go out over the internet (which opens up potential password attacks). To enable encrypted access but keep things local, I tried to get something really simple:

https://github.com/Rosuav/obs-remote-volume/blob/master/proxy.py

Would it be worth migrating that into this repo and providing it as a recommended way to encrypt the connection?

For LAN usage, pagekite and (I think) ngrok are both massive overkill, and also they force traffic to go out over the internet (which opens up potential password attacks). To enable encrypted access but keep things local, I tried to get something really simple:

https://github.com/Rosuav/obs-remote-volume/blob/master/proxy.py

Would it be worth migrating that into this repo and providing it as a recommended way to encrypt the connection?

Is there really a use-case for TLS encryption inside a LAN? To acquire a LetsEncrypt certificate you need a public-facing IP anyway (or use DNS-level authentication). I'd argue that Wireguard LAN setup would be an easier setup in such a case.

The use-case is that you can't use https://t2t2.github.io/obs-tablet-remote/ with anything other than localhost unless you encrypt the websocket. Because according to browser manufacturers, it's better to encrypt nothing at all than to encrypt some of it without all of it. Even if the unencrypted part is on your own LAN. Thanks, browsers, brilliant job.

The use-case is that you can't use https://t2t2.github.io/obs-tablet-remote/ with anything other than localhost unless you encrypt the websocket. Because according to browser manufacturers, it's better to encrypt nothing at all than to encrypt some of it without all of it. Even if the unencrypted part is on your own LAN. Thanks, browsers, brilliant job.

You can enable mixed content in your browser (in Chrome even on a site-specific level), but yeah - it's not ideal.

Closing since we have the tls tutorial in the docs.

Navigation Menu

Repository navigation

HTTPS connection not working #26

1 remaining item

Running remote or over a TLS connection

Running remote or over a TLS connection

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

HTTPS connection not working #26

Description

Activity

Palakis commented on Jan 9, 2017

haganbmj commented on Jan 16, 2017

Hardy535 commented on Jan 16, 2017

jnovack commented on Feb 16, 2017

jnovack commented on Apr 26, 2017

Rosuav commented on Jul 3, 2017

haganbmj commented on Jul 3, 2017

andreymal commented on Mar 10, 2018

eddedre commented on Mar 8, 2019

Jaxel commented on May 27, 2019

1 remaining item

aumer-amr commented on Apr 17, 2020

Niek commented on May 28, 2020

bestlane commented on Jun 3, 2020

Rosuav commented on Jun 3, 2020

Niek commented on Jun 3, 2020

Running remote or over a TLS connection

Rosuav commented on Jun 3, 2020

Niek commented on Jun 3, 2020

bestlane commented on Jun 3, 2020

Running remote or over a TLS connection

Palakis commented on Jun 4, 2020

Rosuav commented on Jun 5, 2020

Niek commented on Jun 5, 2020

Rosuav commented on Jun 5, 2020

Niek commented on Jun 5, 2020

tt2468 commented on Feb 2, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions