Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2019-07-04T20:20:25Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2323m3u/xspf/vclt files do not support SSL2019-07-04T20:20:25ZGitlab Botm3u/xspf/vclt files do not support SSLRegardless of the settings within the config file, the url created in the m3u/xspf/vclt files is still in HTTP.
It looks to be due to the following lines in /src/fserve.c (lines 476 till 493) where the http is hardcoded:
```
if ...Regardless of the settings within the config file, the url created in the m3u/xspf/vclt files is still in HTTP.
It looks to be due to the following lines in /src/fserve.c (lines 476 till 493) where the http is hardcoded:
```
if (host == NULL)
{
config = config_get_config();
snprintf (httpclient->refbuf->data + ret, BUFSIZE - ret,
"http://%s:%d%s\r\n",
config->hostname, config->port,
sourceuri
);
config_release_config();
}
else
{
snprintf (httpclient->refbuf->data + ret, BUFSIZE - ret,
"http://%s%s\r\n",
host,
sourceuri
);
}
```Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2318icecast fails to build against openssl-1.1 that lacks deprecated features2019-04-24T17:23:49ZGitlab Boticecast fails to build against openssl-1.1 that lacks deprecated featuresicecast-2.5_beta1 (and 2.4.3 as well) fails to build against openssl-1.1 that lacks deprecated features. This is the case when openssl-1.1 was built with either "--api=1.1.0" or "no-deprecated" option. The build issues look like this:
`...icecast-2.5_beta1 (and 2.4.3 as well) fails to build against openssl-1.1 that lacks deprecated features. This is the case when openssl-1.1 was built with either "--api=1.1.0" or "no-deprecated" option. The build issues look like this:
```
i686-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I./common/ -Wall -ffast-math -fsigned-char -I/usr/include/libxml2 -I/usr/include -pthread -march=native -O2 -pipe -c -o connection.o connection.c
connection.c: In function ‘get_ssl_certificate’:
connection.c:195:5: warning: implicit declaration of function ‘SSL_load_error_strings’ [-Wimplicit-function-declaration]
SSL_load_error_strings(); /* readable error messages */
^
connection.c:196:5: warning: implicit declaration of function ‘SSL_library_init’ [-Wimplicit-function-declaration]
SSL_library_init(); /* initialize library */
^
connection.c:198:12: warning: assignment discards ‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
method = SSLv23_server_method();
^
```
And later in the linking part:
```
libtool: link: i686-pc-linux-gnu-gcc -pthread -march=native -O2 -pipe -Wl,-O1 -Wl,--hash-style=gnu -Wl,--sort-common -o icecast cfgfile.o main.o logging.o sighandler.o connection.o global.o util.o slave.o source.o stats.o refbuf.o client.o xslt.o fserve.o admin.o md5.o format.o format_ogg.o format_mp3.o format_midi.o format_flac.o format_ebml.o format_kate.o format_skeleton.o format_opus.o event.o event_log.o event_exec.o acl.o auth.o auth_htpasswd.o auth_anonymous.o auth_static.o format_vorbis.o format_theora.o format_speex.o auth_url.o event_url.o yp.o -L/usr/lib -Wl,--as-needed common/net/.libs/libicenet.a common/thread/.libs/libicethread.a common/httpp/.libs/libicehttpp.a common/log/.libs/libicelog.a common/avl/.libs/libiceavl.a common/timing/.libs/libicetiming.a -lcurl -lnghttp2 -lidn2 -lssl -lcrypto -lspeex -ltheora -lvorbis -logg -lxslt -lxml2 -lz -ldl -lm -pthread
connection.o: In function `connection_accept_loop':
connection.c:(.text+0x736): undefined reference to `SSL_load_error_strings'
connection.c:(.text+0x73b): undefined reference to `SSL_library_init'
collect2: error: ld returned 1 exit status
make[3]: *** [Makefile:512: icecast] Error 1
```
Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2311Parametrize TLS/SSL Protocol in Icecast config file2021-09-28T12:50:45ZGitlab BotParametrize TLS/SSL Protocol in Icecast config fileWe currently have the option of enabling SSL, defining ciphers and certificate files. Would you please add the option to define the protocol.
Example could be:
```
<SSL_Protocol>SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1|SSL_OP_NO_SSLv2|SSL_OP_...We currently have the option of enabling SSL, defining ciphers and certificate files. Would you please add the option to define the protocol.
Example could be:
```
<SSL_Protocol>SSL_OP_NO_TLSv1|SSL_OP_NO_TLSv1_1|SSL_OP_NO_SSLv2|SSL_OP_NO_SSLv3</SSL_Protocol>
```
The current ability to define ciphers is great but some ciphers are backwards compatible. From a security standpoint, it would be great to be able to control the protocols available.
Is there a workaround for me without needing to recompile as I've installed from Xiph repository.
Thank you so much for your time!Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2310re-license to "GPL-2. with OpenSSL exception"2018-06-16T20:52:48ZJamiere-license to "GPL-2. with OpenSSL exception"The debian version of icecast2 doesn't ship with openssl, which means we can't embed streams in https pages without a mixed-content warning.
The debian maintainers report that [it is due to a openssl licensing conflict](https://bugs.deb...The debian version of icecast2 doesn't ship with openssl, which means we can't embed streams in https pages without a mixed-content warning.
The debian maintainers report that [it is due to a openssl licensing conflict](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744815#15) that could be resolved if icecast2 could be re-licensed to include an exception for openssl (among other options).
Is that option viable? Other options?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2283Streaming over SSL disconnects2020-02-26T00:04:46ZBrendonStreaming over SSL disconnectsI reported this via IRC but wanted to make sure a proper bug report gets filed before moving on.
I'm building a streaming radio service for Newgrounds.com. More than one application has an embedded radio player and these applications ar...I reported this via IRC but wanted to make sure a proper bug report gets filed before moving on.
I'm building a streaming radio service for Newgrounds.com. More than one application has an embedded radio player and these applications are all served over SSL.
In order to avoid mixed content warnings, I built Icecast 2.4.3 with SSL support so I could get status info and serve the stream over SSL as well.
(None of the Debian or Ubuntu packages have been built with SSL yet for some reason.)
I'm using Debian 8 x64. libssl is 1.0.1t (which is the latest 1.0.1 LTS version). liquidsoap 1.1.1 is the source and connects to Icecast via port 80 on localhost (both liquidsoap and icecast are on the same VM).
I have six mounts configured all the same. liquidsoap is re-encoding the mp3s at a constant bitrate of 128k. I've uploaded a stripped down Icecast config.
Here is what happens: normally, streaming over SSL works perfectly fine. But sometimes, either right at stream start or at some seemingly random amount of time later, one of the mounts becomes "corrupted." The web player (using a simple <audio> tag) quickly buffers and disconnects. VLC reconnects and gets disconnected over and over.
I've tested this on my local network over wifi using the web player, VLC, and iTunes, and with ServeStream on Android over cellular. All same result.
If I connect to the stream via port 80, I do not get disconnected. I get disconnected from the stream ONLY when streaming over SSL and ONLY when the mount becomes corrupted.
Observations:
- This happens on every mount seemingly at random, but it seems that only ONE mount becomes corrupted at a time.
- Doesn't seem to be triggered by any one song, a track change, or anything else station related that I can find.
- Happens if I use ogg or mp3.
- Shutting down the liquidsoap instance for the corrupted mount, waiting a minute or so (a quick restart doesn't seem to fix it) and then restarting liquidsoap seems to resolve the issue (at least temporarily).
- Nothing in the logs that I can see, even with debug logging on:
[2016-08-21 20:30:08] DBUG stats/modify_node_event update "/electronic" listeners (1)
[2016-08-21 20:30:08] DBUG format/format_check_http_buffer processing pending client headers
[2016-08-21 20:30:08] DBUG client/client_send_bytes Client connection died
[2016-08-21 20:30:08] DBUG source/source_main Client removed
[2016-08-21 20:30:08] INFO source/source_main listener count on /electronic.mp3 now 0
These cycle over and over again as the client disconnects and reconnects. I can find nothing else in any of the logs on the system.
- This happens on both staging and production which is on two separate servers.
I was asked to run Icecast using valgrind. We saw lots of SSL errors, so one possible issue could be a buggy system libssl (which I do not think is the case at this point). I even got the latest OpenSSL 1.0.2h built and then built Icecast against that to rule out 1.0.1t causing a bunch of errors.
I will upload the Valgrind output for both 1.0.1t and 1.0.2h.
I simply started Icecast and then shut it down via ctrl-c. This was NOT running while experiencing a corrupted mount.
That's about as much information as I think I have at this point. I have decided to abandon using SSL for the streams as it simply does not seem to be production ready at this point. This will cause mixed content errors in our applications, but streaming over http seems much more stable.
I'd be happy to help provide more information if requested.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2245Move TLS options out of <paths>2018-06-15T20:50:30ZPhilipp SchafftMove TLS options out of <paths>The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?The TLS options (<tls-certificate>, <tls-allowed-ciphers> (maybe more in future?)) are in <paths>. Should they be moved outside? If so where to?Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2180SSL for admin only2020-10-15T09:24:19ZMelvyn SopacuaSSL for admin onlyHi,
I've tried the configuration below to setup SSL for the admn. This doesn't work and the documentation is too tierse to give me any hints.
Goal: Force and use SSL for /admin mountpoint. This needs to be a different URL (certificate ...Hi,
I've tried the configuration below to setup SSL for the admn. This doesn't work and the documentation is too tierse to give me any hints.
Goal: Force and use SSL for /admin mountpoint. This needs to be a different URL (certificate has limited hostnames)
Configuration tried:
```
<mount>
<mount-name>/admin</mount-name>
<ssl>1</ssl>
<stream-url>https://www.example.com:8000/admin</stream-url>
</mount>
```
Result:
1. Admin is accessible through HTTP
2. No secure connection can be established through HTTPS.
Note: firewall is not in play, because of 1), but verified regardless.Icecast 2.5.0Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2134Please add SSL support for Master -> Slave relay connections2021-11-10T08:58:41ZJordan EricksonPlease add SSL support for Master -> Slave relay connectionsIn considering a secure end-to-end Icecast communication chain, it would be wonderful to have the ability for SSL enabled master -> slave relay connections.In considering a secure end-to-end Icecast communication chain, it would be wonderful to have the ability for SSL enabled master -> slave relay connections.Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2070openSSL configuration overhaul in Icecast2023-01-03T10:26:01ZThomas B. RückeropenSSL configuration overhaul in IcecastI'd like to propose we update Icecast's openSSL configuration to have safer defaults and disable broken protocols and features completely.
Most recent vulnerabilities have been addressed by openSSL and should be up to date on people's sy...I'd like to propose we update Icecast's openSSL configuration to have safer defaults and disable broken protocols and features completely.
Most recent vulnerabilities have been addressed by openSSL and should be up to date on people's systems, but still we should do our part to prevent bad things from happening.
There will be dependent tickets filed for certain aspects.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2159RFC 2817 "Upgrading to TLS Within HTTP/1.1" Support2018-03-06T12:49:47ZPhilipp SchafftRFC 2817 "Upgrading to TLS Within HTTP/1.1" SupportRFC 2817 should be supported.
This will also be helpful with libshout. See #2152.RFC 2817 should be supported.
This will also be helpful with libshout. See #2152.Icecast 2.5.0Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2354Improve way of what URI is sent to YP2022-03-21T23:14:53ZPhilipp SchafftImprove way of what URI is sent to YPAt this point the URI sent to YP servers is based on the hostname and global port setting. However this does not work with TLS enabled and may not work for more complex setups with internal-/external-split (including different hostnames)...At this point the URI sent to YP servers is based on the hostname and global port setting. However this does not work with TLS enabled and may not work for more complex setups with internal-/external-split (including different hostnames).
An attribute to the `<directory>` tag should be added that takes the ID of a `<listen-socket>` on which behalf the YP submission should be made. That `<listen-socket>` may be `type="virtual"`.
See: #2171Marvin ScholzMarvin Scholzhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2355DoS vector using incorrect TLS teardown2018-12-07T13:48:18ZPhilipp SchafftDoS vector using incorrect TLS teardownWhen in a TLS SOURCE connection the socket is closed without TLS teardown Icecast will read from the socket in a tight endless loop. This locks up the corresponding thread.
Affected at least: Icecast 2.4.4, Icecast 2.5 beta 2.
May be re...When in a TLS SOURCE connection the socket is closed without TLS teardown Icecast will read from the socket in a tight endless loop. This locks up the corresponding thread.
Affected at least: Icecast 2.4.4, Icecast 2.5 beta 2.
May be related to OpenSSL version. Tested with version 1.0.1t.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2356Icecast does not handle HTTP Upgrade as to RFC2018-12-14T03:48:15ZPhilipp SchafftIcecast does not handle HTTP Upgrade as to RFCCurrently Icecast 2.5.x does not handle HTTP upgrades correctly. It does not send the final reply to the request doing the upgrade.Currently Icecast 2.5.x does not handle HTTP upgrades correctly. It does not send the final reply to the request doing the upgrade.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2364https stream play 1 second and stop2019-05-13T11:56:47ZMichelhttps stream play 1 second and stopWe have sometimes a problems with playing in https on Icecast v 2.4.3 it starts playing and stops after a second.
But only an issue on https, the http streams are fine. When we restart the Icecast it works fine for days.
Yesterday i bul...We have sometimes a problems with playing in https on Icecast v 2.4.3 it starts playing and stops after a second.
But only an issue on https, the http streams are fine. When we restart the Icecast it works fine for days.
Yesterday i bult a new RPM for Icecast 2.4.4 on the last version of CentOS Linux release 7.6.1810 (Core) include the openssl update. (OpenSSL 1.0.2k-fips 26 Jan 2017)
I run it on the debug mode (4). Tonight i have the same problem on https on mount /live a mp3 192k stream. It play 2 seconds and stop. (when i try to use include .m3u so https.../live.m3u he go to http in the software player)
Here is the debug error log. I hope you find them useful (see /live) :
```
[2018-12-09 21:29:07] DBUG auth/add_authenticated_listener client authenticated, passed to source
[2018-12-09 21:29:07] DBUG source/source_main Client added for mountpoint (/live)
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 1
[2018-12-09 21:29:07] DBUG format/format_check_http_buffer processing pending client headers
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (15)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global connections (52301)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (16)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global connections (52302)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/flac.flac" total_bytes_read (18373627904)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/flac.flac" total_bytes_sent (82768157916)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global client_connections (50480)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/live" listeners (1)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listeners (12)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listener_connections (11687)
[2018-12-09 21:29:07] DBUG client/client_send_bytes Client connection died
[2018-12-09 21:29:07] DBUG source/source_main Client removed
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 0
[2018-12-09 21:29:07] DBUG auth/add_listener_to_source max on /live is 400 (cur 0)
[2018-12-09 21:29:07] DBUG auth/add_listener_to_source Added client to /live
[2018-12-09 21:29:07] DBUG auth/add_authenticated_listener client authenticated, passed to source
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global listeners (11)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global clients (15)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update "/live" listeners (0)
[2018-12-09 21:29:07] DBUG stats/modify_node_event update global client_connections (50481)
[2018-12-09 21:29:07] DBUG source/source_main Client added for mountpoint (/live)
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 1
[2018-12-09 21:29:07] DBUG format/format_check_http_buffer processing pending client headers
[2018-12-09 21:29:07] DBUG client/client_send_bytes Client connection died
[2018-12-09 21:29:07] DBUG source/source_main Client removed
[2018-12-09 21:29:07] INFO source/source_main listener count on /live now 0
```
Best regards,
Michelhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2365Discussion on the handling of portless Host:-headers2020-10-11T15:59:37ZPhilipp SchafftDiscussion on the handling of portless Host:-headersKarl updated Icecast in 64d2fc1faa46cf98b0576521c4975d3ae43ff252 to ignore Host:-headers that do not include a port. This was done due to the fact that winamp and foobar2000 do send invalid Host:-headers. They do not include the port eve...Karl updated Icecast in 64d2fc1faa46cf98b0576521c4975d3ae43ff252 to ignore Host:-headers that do not include a port. This was done due to the fact that winamp and foobar2000 do send invalid Host:-headers. They do not include the port even if non-default ports are used. When this header is used this results in invalid playlists to be generated. (Other (future) uses such as vhosting may also be affected).
foobar2000 seems to have fixed this. This was the result of a quick test with @laama. Thanks to him.
Winamp 5.53 1898 Beta from 2008 as well as Winamp 5.8 as downloaded today are still affected.
The following solution and workarounds come to mind:
* Nullsoft fixes their software. (Judge yourself if this is going to happen.) This is the only solution. It is the only correct way to do this.
* Keep ignoring Host:-headers that do not include a port. This may break legitimate clients.
* Try to match Host:-headers against listen sockets. This may break vhosting.
* Implement a way to list valid vhosts and set default vhosts per listen socket.
* Ignore Host:-headers without a port but implement a per listen socket default vhost setting.
Note that we can not accept/reject Host:-headers without port based on if we listen on a default port socket or not without type="virtual" listen sockets. This will otherwise break all kinds of redirects.
This ticket is mostly for discussion.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2379Consider adding fallback support for WolfSSL2024-01-21T02:16:56ZUnit 193Consider adding fallback support for WolfSSLHowdy,
WolfSSL has an OpenSSL compatibility layer, so if a distribution can't offer Icecast linked with OpenSSL, using WolfSSL might be a possibility. I've made and tested a minimal patch, and with git master of WolfSSL Icecast is full...Howdy,
WolfSSL has an OpenSSL compatibility layer, so if a distribution can't offer Icecast linked with OpenSSL, using WolfSSL might be a possibility. I've made and tested a minimal patch, and with git master of WolfSSL Icecast is fully functional.
Would you consider adding support for it? It was mentioned that this might be more fitting for the 2.4 series.
Example patch attached (note this is not the version I was testing).
[icecast-wolfssl.patch](/uploads/5690621487ec0fc7ee689d161032b5ef/icecast-wolfssl.patch)
~Unit 193Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2391Found memory leak problems on ubuntu 20.04 tls2024-01-21T02:16:55ZChaichanaFound memory leak problems on ubuntu 20.04 tlsubuntu 20.04tls icecast2 use abnormal memory, unlike ubuntu 18.04 that doesn't use memory much
Must use the command service icecast2 restart memory to return to normal But before long, it will be leak same.
- Installation of all applica...ubuntu 20.04tls icecast2 use abnormal memory, unlike ubuntu 18.04 that doesn't use memory much
Must use the command service icecast2 restart memory to return to normal But before long, it will be leak same.
- Installation of all applications
https://mediarealm.com.au/articles/icecast-https-ssl-setup-lets-encrypt/
- IMAGE
Top in image ubuntu 18.04 tls
Bottom in image ubuntu 20.04 tls
![ฟ](/uploads/d236d04fa7fc56f7c97c7d47e7937a12/ฟ.jpg)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2403HTTP 409 on reconnect2024-01-20T23:53:52ZGlenn SimsHTTP 409 on reconnectI recently updated our Icecast software from 2.4.4 to 2.4.99.2 (built via source). The internet at my station goes out sometimes and shuts off the stream. Our program, Broadcast Using This Tool, is designed to automatically reconnect t...I recently updated our Icecast software from 2.4.4 to 2.4.99.2 (built via source). The internet at my station goes out sometimes and shuts off the stream. Our program, Broadcast Using This Tool, is designed to automatically reconnect to the server if the connection dies. However, when the internet comes back on, the log says "server answered with 409!", which means an HTTP conflict.
Icecast is hosted on AWS EC2 running on ports 80 and 443. It is forwarded through my subdomain has an A record with an SSL certificate in the `icecast.xml` file. Since then I have not made any changes to the DNS. This issue had started happening after the upgrade to 2.4.99.2.
This is my BUTT log open in Notepad++ showing the error:
![Screenshot_2020-11-06_191540](/uploads/815c58d23d7cea1510d9fa0184b3d155/Screenshot_2020-11-06_191540.png)Icecast 2.5 rc1Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2406Icecast SSL stream information2022-04-20T09:19:24ZAlain SeysIcecast SSL stream informationNot realy a issue rather a question we have a icecast server if we listen (vlc)to the http stream we can get the current track information if we listen to the https stream(vlc) we only can hear the stream but no track information is serv...Not realy a issue rather a question we have a icecast server if we listen (vlc)to the http stream we can get the current track information if we listen to the https stream(vlc) we only can hear the stream but no track information is served.
is there a way to also give the track information trough ssl ?
on our website we use a php script to get the trackinformation from a https stream but in vlc we cant get it to work.
please advise mehttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2410URL auth does not work with HTTP/2 servers2023-01-03T10:21:48ZMarvin ScholzURL auth does not work with HTTP/2 serversUsing URL auth with a HTTP/2 capable sever does not work properly:
```text
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "HTTP/2 200 .."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "...Using URL auth with a HTTP/2 capable sever does not work properly:
```text
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "HTTP/2 200 .."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "date: Sun, 25 Apr 2021 11:40:34 GMT.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "server: Apache.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "x-icecast-auth-result: ok.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "x-icecast-auth-alter-action: redirect_permanent.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "x-icecast-auth-alter-argument: https://stream.example.com/hits/highquality.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: "content-type: application/json.."
[2021-04-25 13:40:34] DBUG auth_url/handle_returned_header Got header: ".."
[2021-04-25 13:40:34] EROR auth_url/handle_returned_header__complete Can not parse auth backend reply.
```https://gitlab.xiph.org/xiph/icecast-server/-/issues/2413Latest git server stops responding to HTTP requests and signals with TLS enab...2024-01-20T23:54:15ZRob McAuleyLatest git server stops responding to HTTP requests and signals with TLS enabled after some timeUsing the latest git version of Icecast, every month or two my Icecast server stops responding to HTTP requests and e.g. `kill -hup` / `kill ` signals.
With the logs being set to `WARN`, there is nothing particular in the access or erro...Using the latest git version of Icecast, every month or two my Icecast server stops responding to HTTP requests and e.g. `kill -hup` / `kill ` signals.
With the logs being set to `WARN`, there is nothing particular in the access or error logs. I've set the logs to `DEBUG` now for the next time in hopes of having some more insight.
Some more details:
- The server has between 150-250 listeners per day and 15 sources
- CPU usage is nominal, 0-1%
- RAM usage also nominal, about 50MB (a fresh start is 30MB)
I'm using the latest git so that I can `SIGHUP` the server when I refresh my LetsEncrypt certificates, but the timing of these reloads seems completely disconnected from the server hanging. The timing, at this point, seems random.
I will update this ticket the next time this happens, hopefully with log details.
Please instruct me if there's anything I can do to probe the issue on my end, such as enable particular compile flags for debugging, etc. Also please instruct me if there's any further information you need, such as distribution, GCC version, etc.Icecast 2.5 rc1Rob McAuleyRob McAuleyhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/24322.4.99 beta 3 - OPENSSL - still support for TLS 1.0 and TLS 1.1 - compared t...2024-01-20T23:54:11ZTom Zet2.4.99 beta 3 - OPENSSL - still support for TLS 1.0 and TLS 1.1 - compared to 2.4.4The current **2.4.99 beta 3** still offers TLS 1.0 and TLS 1.1. The SSL test on https://www.ssllabs.com/ shows the following result
![Image_2022-03-18_at_11.28.01_PM](/uploads/dfa1d62d8672e72cf0bcb167575ddbff/Image_2022-03-18_at_11.28.01...The current **2.4.99 beta 3** still offers TLS 1.0 and TLS 1.1. The SSL test on https://www.ssllabs.com/ shows the following result
![Image_2022-03-18_at_11.28.01_PM](/uploads/dfa1d62d8672e72cf0bcb167575ddbff/Image_2022-03-18_at_11.28.01_PM.jpeg)
On a Debian sid System with `OpenSSL 1.1.1n 15 Mar 2022` the icecast has been compiled with `./configure --prefix=/home/zumbi/icecast-2.4.99-beta-3 --with-curl --with-openssl`
The following ciphers are configured in the xml. at the end I excluded `!TLSv1:!TLSv1.1`.Even if standard in openssl, this cyphers has not been ignored.
`<ssl-allowed-ciphers>ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:!TLSv1:!TLSv1.1</ssl-allowed-ciphers>`
While on a productive Debian 11 with `OpenSSL 1.1.1k 25 Mar 2021` and **icecast 2.4.4** the test on https://www.ssllabs.com/ shows the following result
![Image_2022-03-18_at_11.30.33_PM](/uploads/43b55bf7d48f5dcda944f398c48200b5/Image_2022-03-18_at_11.30.33_PM.jpeg)
The following ciphers are configured in the xml
`<ssl-allowed-ciphers>ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256</ssl-allowed-ciphers>`
I tried to change the source code in the file `src/tls.c` on row 91 from `TLS1_VERSION` to `TLS1_3_VERSION` but get a compile error
**Original code**
```
#if OPENSSL_VERSION_NUMBER < 0x10100000L
ctx->ctx = SSL_CTX_new(SSLv23_server_method());
ssl_opts = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3; // Disable SSLv2 and SSLv3
#else
ctx->ctx = SSL_CTX_new(TLS_server_method());
SSL_CTX_set_min_proto_version(ctx->ctx, TLS1_VERSION);
#endif
```
**Compile (make) error**
```
In file included from tls.c:18:
tls.c: In function ‘tls_ctx_new’:
tls.c:91:45: error: ‘TL1_3_VERSION’ undeclared (first use in this function); did you mean ‘TLS1_3_VERSION’?
91 | SSL_CTX_set_min_proto_version(ctx->ctx, TL1_3_VERSION);
^~~~~~~~~~~~
```
**Proposal**
1. Change the code this way, that TLS 1.0 and 1.1 (and older) are not offered anymore. Only offer TLS 1.2 and newer. Same way as in 2.4.4
and/or
2. Implement an option as used in advanced webservers like nginx, that the TLS version can be set in the config.
Example for nginx `ssl_protocols TLSv1.2 TLSv1.3;`. Even if the icecast developers move from openssl to another solution, such a option will be helpful and shows best practice.Icecast 2.5 rc1Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2441Icecast 2.5 beta 3 stops after 3 seconds2023-01-03T10:08:01ZMichelIcecast 2.5 beta 3 stops after 3 secondsThe ssl/https output stops after 3 seconds. The http output is okay. I have already report this on 2.4.
I use Debian 10 for OS.
Best regards,
MichelThe ssl/https output stops after 3 seconds. The http output is okay. I have already report this on 2.4.
I use Debian 10 for OS.
Best regards,
Michel