Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2024-01-20T23:54:11Zhttps://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/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/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/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/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/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/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/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/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ücker