Support SSL/TLS for streaming

[mixxxbot]

Reported by: Pegasus-RPG
Date: 2015-11-17T15:21:06Z
Status: Confirmed
Importance: Wishlist
Launchpad Issue: lp1517087
Tags: broadcast, easy, hackathon

---

Libshout 2.4.0 adds support for TLS/SSL so we should add the ability to set it explicitly. The library defaults to 'auto' if not explicitly set, but users may need the ability to force it.

[mixxxbot]

Commented by: daschuer
Date: 2020-07-07T12:33:13Z

---

Since "auto" is broken we need a preferences option.

[roughnecks]

Hi, is this closed because it's fixed?
I'm running MIXXX under Windows and it can't connect to Icecast2 SSL..

[ronso0]

This issue is still open.

[roughnecks]

This issue is still open.

Any ETA? Thanks

[ronso0]

nope.
Feel free to start working on it.

[acolombier]

I'd like to get started on this.

Perhaps before I dive into my plan for the Icecast/Shoutcast+TLS user story, I just was wondering if we could consider upgrading libshout-idjc to 2.4.6? This isn't a trivial update for sure, but every single iteration (except 2.4.4) are bringing improvement on the security layer. (Note that the initial bug with UTF8 metadata leading to removing auto TLS seems to have been fixed)

Back the the issue at hand, here is the suggested UI changes

Kooha-2024-03-31-21-00-59.mp4

labels to be rephrased!

The feature will allow to :

• Use all supported TLS mode (except SHOUT_TLS_AUTO which represent a security vulnerability).
• Choose cypher set to use. Default to Mozilla "Modern" list but also allow the compatibility set also from Mozilla, as well as custom, where the user can specify a list of cipher in a prompt (e.g: ECDHE-ECDSA-AES128-GCM-SHA256:...:DES-CBC3-SHA). Note that the compatibility set of Mozilla sadly include weak cypher such as TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, so it would be best to keep the default to a secure set from a security standpoint)
• Allow custom CA, system root and unverified connection (default to system)
• Allow client certificate (default to none)

What are your thoughts on this? It might sounds like potentially too much but would also be a great way to have Mixxx leading by example on enforcing proper security standard, while still allowing enough flexibility to get every config feasible.

[daschuer]

I have an experimental branch that updates to libshout-idjc 2.4.6 #4723
But because of a history of regressions I would not merge it before we have a mandatory reason.

[daschuer]

The GUI is already overwhelming. Can can we hide the encryption settings when disabled?
Do we have a reference description for a streaming service? It would be nice if the Mixxx user finds the setting at with the same terms as discribed by such a service.

[acolombier]

Can can we hide the encryption settings when disabled?

Yes, I'm thinking of hiding all settings if Encryption=Disabled. Does that sound good?

[daschuer]

Yes.

We may also help the user to select a certificate.
Isn't it normally installed in the certificate store?

[Holzhaus]

• Choose cypher set to use. Default to Mozilla "Modern" list but also allow the compatibility set also from Mozilla, as well as custom, where the user can specify a list of cipher in a prompt (e.g: ECDHE-ECDSA-AES128-GCM-SHA256:...:DES-CBC3-SHA). Note that the compatibility set of Mozilla sadly include weak cypher such as TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, so it would be best to keep the default to a secure set from a security standpoint)

If we want to expose this, we can use a combobox with 3 values:

• Best Security (Recommended, default)
• Medium Security (better compatibility)
• Legacy (not recommended)

• Allow custom CA, system root and unverified connection (default to system)

I do not think this is needed, just use the system CA store. If you have a self-singned cert, just import it there.

• Allow client certificate (default to none)

I have doubts about this. Are there even shoutcast servers that support mutual TLS instead of username/password? If we do not have any example, let's leave this out.

What I'd suggest is that we add a button to auto-detect settings, similar to email clients nowadays. In the background it would try to make a TLS handshake with the server and tries the "best security" (modern) cipher suite list first. If the server does not support any cipher, try with medium security and if that doesn't work either we fall back to legacy.

This will help users who are overwhelmed by this while still allowing flexibility for more experienced users.

[acolombier]

I do not think this is needed, just use the system CA store. If you have a self-singned cert, just import it there.

This compromises the whole system trust chain. I don't think we should encourage use importing self signed certificate in their root chain. I'm not saying this isn't the right approach in some case, but I think we need to allow test setup to work without compromising the global security of our user (and potentially also teach them bad habits). I will keep Use system trust chain and Use custom CA (insecure is only available from 2.4.3 anyway)

I have doubts about this. Are there even shoutcast servers that support mutual TLS instead of username/password? If we do not have any example, let's leave this out.

A shoutcast server is an HTTP server, so it doesn't matter that *cast server support it or not. This is something that can be done on the proxy or ingress level easily (example).
Now I agree this is probably not the most used way (at least yet) but we should allow advanced user or professional broadcaster to work with best security standard as they exist today.

What I'd suggest is that we add a button to auto-detect settings, similar to email clients nowadays. In the background it would try to make a TLS handshake with the server and tries the "best security" (modern) cipher suite list first. If the server does not support any cipher, try with medium security and if that doesn't work either we fall back to legacy.

That's bad security practices and this will expose our user to trivial downgrade attacks. FYI, that's already what the AUTO libshout mode was doing previously.

This will help users who are overwhelmed by this while still allowing flexibility for more experienced users.

The default option remains "Disabled" as it used to be (and so other settings will be hidden) so I am not sure what is overwhelming here (cypher to modern, CA defaults to system, client CA to not used)?
If a user care about their security but don't know more than, they can select Auto.
If the connection fails, we can suggest our user to manually downgrade security, while also making them aware that if this used to work, they may be victim of a MITM+Downgrade attack.

[daschuer]

For me it is unclear whether libshout-idjc 2.4.6 is mandatory for this issue or not.
At one point we will switch anyway. So we may do the switch now and ask for feedback from broadcasters during beta.
Do we want to take the hassle now, or postpone it because the Qt 6 switch is enough to test.

[daschuer]

Do we have a user request, that rectifies the update?

[acolombier]

For me it is unclear whether libshout-idjc 2.4.6 is mandatory for this issue or not.

Technically, we don't. Only feature we get staring from 2.4.3 is "allow insecure cert", but I don't think it is blocker to already get system chain+custom CA working.

[Holzhaus]

I do not think this is needed, just use the system CA store. If you have a self-singned cert, just import it there.

This compromises the whole system trust chain. I don't think we should encourage use importing self signed certificate in their root chain. I'm not saying this isn't the right approach in some case, but I think we need to allow test setup to work without compromising the global security of our user (and potentially also teach them bad habits). I will keep Use system trust chain and Use custom CA (insecure is only available from 2.4.3 anyway)

This does not compromise the whole system trust chain. When you use a self signed certificate, you usually delete the CA private key immediately after signing, so unless you use a really short key size that makes it possible to derive the private key from the pub key, this does not impact your system security.

And to be honest, using self signed certificates for anything other than development is bad practice anyway, since we have Let's Encrypt for self hosted stuff nowadays.

I agree that we shouldn't encourage self signed certificates, that's why I think the additional complexity is not needed at all. But in case you really want to use self-signed certs, it is possible via the system trust store.

I have doubts about this. Are there even shoutcast servers that support mutual TLS instead of username/password? If we do not have any example, let's leave this out.

A shoutcast server is an HTTP server, so it doesn't matter that *cast server support it or not. This is something that can be done on the proxy or ingress level easily (example).
Now I agree this is probably not the most used way (at least yet) but we should allow advanced user or professional broadcaster to work with best security standard as they exist today.

I really doubt someone is doing this, and this config option just adds complexity. All shoutcast implementation I know require username/password for client auth. Sure, you can add a proxy in front of it that requires it, but is that really realistic that someone does it? I'm not strictly against this, but I would rather not accumulate technical debt and make the UI more confusing when there are zero potential users we know of.

What I'd suggest is that we add a button to auto-detect settings, similar to email clients nowadays. In the background it would try to make a TLS handshake with the server and tries the "best security" (modern) cipher suite list first. If the server does not support any cipher, try with medium security and if that doesn't work either we fall back to legacy.

That's bad security practices and this will expose our user to trivial downgrade attacks. FYI, that's already what the AUTO libshout mode was doing previously.

No, it's not the same. As far as I know the auto mode detected it on a per-connection basis. What I was suggesting is to auto-detect it once after configuration. Sure, there can be a downgrade attack if the attacker manages the intercept the connection in thr exact moment when the user first configures the connection. Afterwards, the values are fixed and a downgrade attack is not possible (unless the user goes back to the config and hits the "Detect settings" button again). And in the unlikely case that the attacker actually performs this attact in the right moment, this just affects autoselection and the user can still select higher security settings manually.

To be honest, I suspect that this aforementioned downgrade attack at configuration time will work exactly the same in 99% of the cases even if we don't add such an "autodetect" button:

1. User select higher security settings, saves the config and closes preferences
2. User tries to broadcast -> connection error occurs because attacker intercepts the TLS handshake
3. User thinks "oh, I must have misconfigured it", goes back to preferences, selects slightly lower security settings, saves and closes the preferences window
4. User tries to broadcast -> connection error occurs because attacker intercepts the TLS handshake
5. User thinks "yikes, still misconfigured", goes back to preferences, selects lowest TLS settings, saves and closes the preferences window
6. User tries to broadcast -> connection error occurs because attacker intercepts the TLS handshake
7. User thinks "I don't care anymore", goes back to preferences, selects "Disable TLS", saves and closes the preferences window
8. Attacker can eavesdrop on any connection because they are not secured at all.

So we don't really lose anything here IMHO, just make configuration less cumbersome and make it possible to select secure defaults (see below).

This will help users who are overwhelmed by this while still allowing flexibility for more experienced users.

The default option remains "Disabled" as it used to be (and so other settings will be hidden) so I am not sure what is overwhelming here (cypher to modern, CA defaults to system, client CA to not used)?
If a user care about their security but don't know more than, they can select Auto.
If the connection fails, we can suggest our user to manually downgrade security, while also making them aware that if this used to work, they may be victim of a MITM+Downgrade attack.

If we leave the default on "TLS Disabled" the vast majority of users will not use it and just use insecure connections. For these user, all these changes we discuss here would have no benefit at all and just make UI more complicated.

Security needs to be usable and enabled by default. Otherwise people just not use it. Hence my suggestion that after typing in the server connection data, we auto-detect security settings once (as described above) so that all users will use the highest TLS security setting supported by their shoutcast server by default.

They can still modify these settings, but we avoid that people accidently expose their credentials over an insecure connection because they have no idea what TLS is or what settings their server supports. This would really bring a practical benefit for a large number of users (given that their servers support TLS - but it's 2024 after all, so I guess they do).

[Holzhaus]

Don't get me wrong, I really appreciate your push on this. And I'm not really against stuff like support for TLS Client Certs or custom certificates. But there are many more options: supporting certificate pinning, configuring OCSP stapling, etc.

All of them might have some benefit for a few users, but the security improvement will be tiny and only affect a small group of people. In contrast, enabling TLS by default without requiring manual configuration will drastically improve security for a large number of users. This is why I think we should focus on that first.