Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Live broadcasting only supports unencrypted streams #763

Open
synthead opened this issue Mar 3, 2019 · 5 comments
Open

Live broadcasting only supports unencrypted streams #763

synthead opened this issue Mar 3, 2019 · 5 comments

Comments

@synthead
Copy link

synthead commented Mar 3, 2019

Is your feature request related to a problem? Please describe.
Live broadcasting doesn't support encryption

Describe the solution you'd like
Live broadcasting should support encryption

Describe alternatives you've considered
I've attempted to use proxies with Apache to SSL-ify incoming streams, but clients don't seem to understand how to connect to it this way

@hairmare
Copy link
Member

This should be implementable, at least in theory. As far as I can tell the incoming and outgoing streams are similar enough to treat them in roughly the same manner.

We would need a liquidsoap build that supports SSL by being compiled against ocaml-ssl. This would need at least ocaml-ssl >= 0.5.2 which does not seem to be available on Debian or CentOS based Linux distros. So you would need to install using the opam instructions.
With CentOS ocaml-ssl will get bumped to a usable version in CentOS 8. I'm not sure what the state of ocaml-ssl is on Debian based distros and would have to defer to @paddatrapper on that. I checked pkgs.org and there doesn't seem to be a package for any Debian based distro yet.

To allow TLS support on the Master/DJ stream endpoints we would need to allow configuring the keys and certs as well as optionally using the input.harbor.ssl if the cert/keys are configured.

# liquidsoap.cfg
# configure TLS for streams
set("harbor.ssl.certificate", "/path/to/fullchain.pem")
set("harbor.ssl.private_key", "/path/to/privkey.pem")

https://github.com/LibreTime/libretime/blob/9b9832ee4e95833a657549d7e3999651f4eec7ee/python_apps/pypo/liquidsoap/ls_script.liq#L266-L299

The changes to LibreTime to support streaming to an icecast instance with TLS would mostly be passing protocol = 'https' to the various output.icecast and output.shoutcast calls in ls_lib.liq.

https://github.com/LibreTime/libretime/blob/9b9832ee4e95833a657549d7e3999651f4eec7ee/python_apps/pypo/liquidsoap/ls_lib.liq#L119-L143

https://github.com/LibreTime/libretime/blob/9b9832ee4e95833a657549d7e3999651f4eec7ee/python_apps/pypo/liquidsoap/ls_lib.liq#L168-L190

We might also need to allow configuring trust for a certificate if folks use an internal root-CA or a self-signed certificate.

Given that all of this is rather complex to set up, I'm pretty sure it won't happen soon. There are some rough edges that we would ideally want to sort out before releasing this into the wild that aren't quite in the scope of LibreTime.

  • Icecast needs to support reloading certs on the fly without dropping client connections, this will presumably be in icecast 2.5
  • Clients like Mixxx and butt need to be tested and possibly updated to support TLS

The fact that an opam install of liquidsoap is currently needed for all of this it hasn't been high up on our priorities. There is also #88 which I guess is more pertaining to the web-server parts so I'm putting this into the 3.0.0 release stuff for now. We might remove it from there again if it turns out not implementable.

The proxy workaround you mentioned should work but it is not recommended by upstream icecast developers. For incoming streams you might have better results using a workaround using stunnel or similar.

@hairmare hairmare added the TLS label Jul 28, 2019
@hairmare hairmare added this to the 3.0.0 milestone Jul 28, 2019
@paddatrapper
Copy link
Contributor

paddatrapper commented Jul 28, 2019

Unfortunately I won't be able to release a version of the Liquidsoap package linking against openssl due to the Liquidsoap license. The GPL is incompatible with the OpenSSL licence (see https://lintian.debian.org/tags/possible-gpl-code-linked-with-openssl.html). The only way to fix this would be to have Liquidsoap add the SSL exception to their licence

@hairmare
Copy link
Member

ocaml-ssl is under the lgpl and has this exception:

https://github.com/savonet/ocaml-ssl/blob/9dd1cbf71839195e115b8e2438554c530e0f0ed0/COPYING#L1-L3

I'm not sure if ocaml-cry and liquidsoap itself also need the exception since I haven't checked how liquidsoap and ocaml-cry get linked if ocaml-ssl is available. Otherwise we could investigate using GNUtls instead.

@paddatrapper
Copy link
Contributor

Hmm... Good point. I'll check with Debian legal and see. My thought would be that they do need, but I could well be wrong about that. ocaml-ssl is in Debian, but needs updating to the latest version (https://tracker.debian.org/pkg/ocaml-ssl). That I can do no problem

@paddatrapper
Copy link
Contributor

I've spoken to a couple people and had a look at the ocaml-ssl licence. The ocaml-ssl licence has an exception that allows any work linked against it to be released under any licence terms. So liquidsoap and ocaml-cry would be fine linking against ocaml-ssl. I'll do so in the next upload for each

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants