Azuracast: Azuracast m3u stream does not open in iTunes

[gammaw]

Hi,

we'd like to provide our listeners a m3u with the stream URL also to work around the player instability in the browser (https://github.com/AzuraCast/AzuraCast/issues/1420). When I download the m3u file from Azura's station profile page and double click on it, an empty playlist will open in iTunes and nothing will be played. It can well be an iTunes issue but we found that other URLs work also with iTunes. To be fair, we were able to play the Azura m3u with VLC for example. So in general it seems to be ok but we have to deal with iTunes for its wide usage. Strangely enough, iTunes plays the stream as well when the URL is entered directly via Open Stream... from the menu.

We run Azuracast on a custom port and via HTTPS (via Let's Encrypt) and have a stream URL structure similar to this:
https://www.xyz.com:8083/radio/8000/radio.mp3

Any idea? Can it be the port or the https? Other URLs where iTunes worked were simpler (no custom port, no https).

Thanks.

PS: the found this issue on a macOS Mojave and with iTunes 12.9.2.5.

[btoplak]

If you can play the stream URL with VLC then it is not the link/server issue. I don't use iTunes so I don't know if the player plays non-standard HTTP/S ports... it's worth more investigation on your side.

Port: I prefer to proxy all streams to port 80. It just circumvents each and every firewall or any other protection scheme.

HTTPS; I simply don't see any security benefit for a standard public radio stream to be pushed through the encrypted channel. What is there to hide and protect? And it puts extra load to CPU's on both side (server and clients) the whole en/decoding of HTTPS traffic. With modern machines that is probably a minor load, but still - why?
Only if someone is making a password protected stream which uses some POST credentials then I could say that is a valid reason to use HTTPS encrypted connection.

[gammaw]

@btoplak I don't think (and I hope) that the stream itself is encrypted. @SlvrEagle23 @Vaalyn can you please confirm the letsencypt-create command (https://www.azuracast.com/docker_sh.html#available-commands) will not cause the stream to be encrypted? We need a https URL to be able to embed the stream on a https site.

[Vaalyn]

@gammaw @btoplak When using HTTPS via Let's Encrypt for the streams they too will be transported over an TLS encrypted HTTPS channel like normal requests will do. There is no special "extra" encryption only for the audio stream it's just the normal HTTPS you know from web servers. This does indeed increase the CPU load marginally but it gives you the ability to embed the stream on a web site that already uses HTTPS without causing browsers to display the "mixed security" warning in the search bar and you get to keep the "lock" icon there. Having this security indicator is something that you should care about because it can effect your SEO ranking and also how much the more tech illiterate users trust your site.

In theory this will also protect you from your ISP sniffing on the content you consume and selling that data to advertisers, if you have an ISP that does such shady things, which is at least in the EU pretty uncommon since it would violate the GDPR but I've read that this can happen in the US.

[btoplak]

@gammaw HTTPS means that all data is transferred encrypted, be it HTML webpage or the stream or a file.
And yes, as @Vaalyn told, embedding a stream link to a browser player on a HTTPS webpage is a valid reason to use HTTPS.

@Vaalyn I know all of that. But, if one doesn't do the embedding, just (for example) a playlist download file for a desktop player, then one doesn't need HTTPS overhead at all. Everything works just perfectly for years via old HTTP. And ISP or other eavesdropper can just take a HTTPS link and analyze the content anyway (it's not that a listener and ISP would get different content) if we are talking about the publicly accessible links (as I've already mentioned before).

[Vaalyn]

And ISP or other eavesdropper can just take a HTTPS link and analyze the content anyway (it's not that a listener and ISP would get different content) if we are talking about the publicly accessible links (as I've already mentioned before).

Yes they can but automated systems can't get the stream URL from the HTTPS channel only the domain that is called. HTTPS is by no means secure against sophisticated attacks on singular people but automated systems will not do these kind of attacks. This point of mine was more of a "I don't want everything I do to be tracked by my own ISP" than a general "I want to be protected against all hackers". =)

[gammaw]

And ISP or other eavesdropper can just take a HTTPS link and analyze the content anyway (it's not that a listener and ISP would get different content) if we are talking about the publicly accessible links (as I've already mentioned before).
@btoplak what do you mean, can you elaborate? It's my lack of knowledge of security :(

[btoplak]

@Vaalyn @gammaw my whole point is - what is so secret in a music stream to care about ISP taking a peak? It's not that stream owner shares some secrets. Apart of the obvious requirement of the stream link being HTTPS when integrated into HTTPS, from my point of view there is no other reason to put a stream into HTTPS.

[Vaalyn]

@btoplak The point is that it is not the business of anybody who is not explicitly allowed by myself to know what I'm watching, listening or reading on the internet.

It may not directly cause harm for most people but let's say as an example you live in a country with an oppressive regime and you want to listen to a podcast that is hosted on a platform that is not blocked by this regime but hosts many podcasts. Just by knowing that you use the platform nobody will prosecute you for using the platform but if the data that is send to you is send plain and unsecure then you could automatically become a target.

This is definitely an extreme example but I hope it gets the point across. It's not about direct harm but about data control. Something that many people don't really value as much as they probably should. You may have "nothing to hide" but that doesn't mean everybody who can snoop on my traffic needs to know what I watch, listen or read.

[btoplak]

@Vaalyn mate, trust me, I completely understand your points and they are absolutely valid. It seems you didn't quite get my point, and that was "If it's Beatles or Marylin Manson what someone is casting - who cares, use HTTP". Any valid reason to hide your content makes HTTPS one of the possible steps. But then again, I hope those who have reason to hide their media content know better than to use casting... Now I feel we are waaaay gone off topic :D

[SlvrEagle23]

@btoplak The issue is not that there is anything "secret" about the audio stream, but that browsers are getting increasingly strict with allowing "mixed" content on web pages that are themselves served over HTTPS. AzuraCast itself, for example, handles user login and active sessions and has plenty of valid reason to be secured, but if not for either a direct HTTPS connection or its own internal nginx proxy, it wouldn't be possible to listen to the insecure radio stream.

As for the original issue at hand, I'm honestly not sure what's causing it, and I don't really have a Mac or any Apple product around to test with. :/

[Vaalyn]

@SlvrEagle23 @gammaw I have tested opening a .pls and .m3u from my AzuraCast installation in iTunes. I manually tested multiple versions of these files, I tested with these stream URLs:

• http://radio.bronyradiogermany.com/radio/8000/stream
• http://radio.bronyradiogermany.com:8000/stream
• https://radio.bronyradiogermany.com/radio/8000/stream
• https://radio.bronyradiogermany.com:8000/stream

The non HTTPS streams both work correctly, iTunes opens the streams and plays them. When using the HTTPS streams both don't work.

I couldn't find any error logs regarding to iTunes and the playlist not playing so not sure what exactly is the problem.

If someone has an IceCast stream that is not hosted through AzuraCast that uses HTTPS I'd like to test if this works or if this also fails.

[ivellios1988]

Some time ago I had my radio set up in a way that all streams used HTTPS (I utilized IceCast as well as Shoutcast) and a lot of my listeners complained that they could not listen to my radio because their apps couldnot read the streams (including iTunes, Xiialive, some people even complained about my station not playing correctly in Winamp...). I use Centova Cast on my streaming server. So the issue with HTTPS streams not being played in iTunes and other apps seems to be unrelated to whether you use AzuraCast or other software.

[Vaalyn]

@ivellios1988 Thank you for that information. To me it seems that these players all have a problem with HTTPS itself or maybe with Let's Encrypt certificates.

[ivellios1988]

@Vaalyn It's quite possible. Given that even in the documentation for iTunes (https://support.apple.com/guide/itunes/listen-to-internet-radio-itns2946/mac) it is clearly stated: "Be sure to include the http:// or https:// prefix when you enter the URL". So, theoretically, all HTTPS streams should be played fine. Someone should try playing streams protected by non-Let's Encrypt certificates.

[Vaalyn]

@ivellios1988 That information would be really helpful. If anyone can provide some input on that I'd really appreciate it. Maybe also from someone who uses CloudFlare. Theoretically their certificate should be accepted by most things.

[gammaw]

Strangely enough, iTunes plays the stream as well when the URL is entered directly via Open Stream... from the menu.

@Vaalyn like I said in my original post iTunes works as well via Open Stream.. but not directly from m3u files. So https streams don't seem to be a problem for iTunes in general.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.