Christian Stoller
2020-Jun-16 13:25 UTC
[Icecast] Empty username and password for stream_auth
Hi, we are using Icecast with url authentication for some days now. This generally works quite well. But our web service that provides the authentication check sometimes gets requests with the following parameters: { "action":"stream_auth", "mount":"/stream", "ip":"xxxxx", "server":"xxxx.yyyy.de", "port":"12345", "user":"", "pass":"", "admin":"1" } The passed username and password is empty. Why does this happen and what should our authentication provider response to such a request? Currently we response with HTTP status code 403 and the header "Icecast-Auth-Message: No username provided". Icecast logs the following at the time of the request:> [2020-06-11 10:08:57] INFO auth/auth_stream_authenticate request source auth for "/stream" > [2020-06-11 10:08:57] INFO auth/queue_auth_client auth on /stream has 1 pending > [2020-06-11 10:08:57] WARN auth/stream_auth_callback Failed auth for source "/stream"I hope you can help me. Best regards Mit freundlichen Grüßen aus Paderborn Christian Stoller Web-Entwicklung LEONEX Internet GmbH Technologiepark 6 33100 Paderborn Tel: +49 (5251) 4142-526 Fax: +49 (5251) 4142-501 HRB 8694 AG Paderborn Geschäftsführer: Stephan Winter ________________________________ LEONEX ist Google Premier Partner. Mit der staatlichen Förderung Go-Digital in die Digitalisierung. Wir sind Ihr Ansprechpartner für erfolgreiche Webauftritte, E-Commerce, individuelle Softwarelösungen, Online-Marketing und Hosting. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200616/16025270/attachment.html>
Philipp Schafft
2020-Jun-17 07:55 UTC
[Icecast] Empty username and password for stream_auth
Good morning, On Tue, 2020-06-16 at 13:25 +0000, Christian Stoller wrote:> Hi, > > we are using Icecast with url authentication for some days now. This > generally works quite well. But our web service that provides the > authentication check sometimes gets requests with the following > parameters: > > { > "action":"stream_auth", > "mount":"/stream", > "ip":"xxxxx", > "server":"xxxx.yyyy.de", > "port":"12345", > "user":"", > "pass":"", > "admin":"1" > } > > The passed username and password is empty. Why does this happen and > what should our authentication provider response to such a request?This is perfectly correct and totally expected: HTTP does the auth in two steps: First a request is sent with no credentials. In this step the request will pass (no credentials needed) or the server will reply parameters on how to provide them. This is important as otherwise the client would send credentials blindly, allowing a wide range of attacks (both passive and active). If asked by the server, the client will then retry again with credentials. Which will then let Icecast ask the backend again. Why does Icecast forward both requests? Very simple: Not all auth setups require username:password. E.g. some are only for logging and accounting. Some auth using the IP address, which is already known in the first request. (That said, Iecast 2.5.x (current development versions) can be configured to reject those request without asking the backend.)> Currently we response with HTTP status code 403 and the header > "Icecast-Auth-Message: No username provided".If you require username:password for auth, then reject those requests to let Icecast tell the client. Generally you should reply with a positive status code to Icecasts requests. The status code you send is about the request from Icecast to your backend server, not for the request from the client to Icecast.> Icecast logs the following at the time of the request: > > [2020-06-11 10:08:57] INFO auth/auth_stream_authenticate request > source auth for "/stream" > > [2020-06-11 10:08:57] INFO auth/queue_auth_client auth on /stream > has 1 pending > > [2020-06-11 10:08:57] WARN auth/stream_auth_callback Failed auth for > source "/stream" > > I hope you can help me.Hope that helped. :)> Best regards > > Mit freundlichen Grüßen aus PaderbornMit freundlichen Grüßen aus Südhessen, -- Philipp Schafft (CEO/Geschäftsführer) Telephon: +49.3535 490 17 92 Löwenfelsen UG (haftungsbeschränkt) Registration number: Bickinger Straße 21 HRB 12308 CB 04916 Herzberg (Elster) VATIN/USt-ID: Germany DE305133015 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 490 bytes Desc: This is a digitally signed message part URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200617/a9d68155/attachment.sig>
Christian Stoller
2020-Jun-17 08:37 UTC
[Icecast] Empty username and password for stream_auth
Hi Philipp, Thanks for your reply. It really helped. Did I understand you correctly that we should respond to those requests sent by Icecast without username and password with HTTP status code 200 and the header "Icecast-Auth-Message: No username provided"? Best regards, Christian> Good morning, > > On Tue, 2020-06-16 at 13:25 +0000, Christian Stoller wrote: >> Hi, >> >> we are using Icecast with url authentication for some days now. This >> generally works quite well. But our web service that provides the >> authentication check sometimes gets requests with the following >> parameters: >> >> { >> "action":"stream_auth", >> "mount":"/stream", >> "ip":"xxxxx", >> "server":"xxxx.yyyy.de", >> "port":"12345", >> "user":"", >> "pass":"", >> "admin":"1" >> } >> >> The passed username and password is empty. Why does this happen and >> what should our authentication provider response to such a request? > > This is perfectly correct and totally expected: > HTTP does the auth in two steps: First a request is sent with no > credentials. In this step the request will pass (no credentials needed) > or the server will reply parameters on how to provide them. This is > important as otherwise the client would send credentials blindly, > allowing a wide range of attacks (both passive and active). > > If asked by the server, the client will then retry again with > credentials. Which will then let Icecast ask the backend again. > > > Why does Icecast forward both requests? Very simple: Not all auth setups > require username:password. E.g. some are only for logging and > accounting. Some auth using the IP address, which is already known in > the first request. > > (That said, Iecast 2.5.x (current development versions) can be > configured to reject those request without asking the backend.) > > >> Currently we response with HTTP status code 403 and the header >> "Icecast-Auth-Message: No username provided". > > If you require username:password for auth, then reject those requests to > let Icecast tell the client. > > Generally you should reply with a positive status code to Icecasts > requests. The status code you send is about the request from Icecast to > your backend server, not for the request from the client to Icecast. > > >> Icecast logs the following at the time of the request: >> > [2020-06-11 10:08:57] INFO auth/auth_stream_authenticate request >> source auth for "/stream" >> > [2020-06-11 10:08:57] INFO auth/queue_auth_client auth on /stream >> has 1 pending >> > [2020-06-11 10:08:57] WARN auth/stream_auth_callback Failed auth for >> source "/stream" >> >> I hope you can help me. > > Hope that helped. :) > > >> Best regards >> >> Mit freundlichen Grüßen aus Paderborn > > > Mit freundlichen Grüßen aus Südhessen, > > -- > Philipp Schafft (CEO/Geschäftsführer) > Telephon: +49.3535 490 17 92 > > Löwenfelsen UG (haftungsbeschränkt) Registration number: > Bickinger Straße 21 HRB 12308 CB > 04916 Herzberg (Elster) VATIN/USt-ID: > Germany DE305133015Mit freundlichen Grüßen aus Paderborn Christian Stoller Web-Entwicklung LEONEX Internet GmbH Technologiepark 6 33100 Paderborn Tel: +49 (5251) 4142-526 Fax: +49 (5251) 4142-501 HRB 8694 AG Paderborn Geschäftsführer: Stephan Winter ________________________________ LEONEX ist Google Premier Partner. Mit der staatlichen Förderung Go-Digital in die Digitalisierung. Wir sind Ihr Ansprechpartner für erfolgreiche Webauftritte, E-Commerce, individuelle Softwarelösungen, Online-Marketing und Hosting. ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.xiph.org/pipermail/icecast/attachments/20200617/ce6ed154/attachment.html>
On Wed, Jun 17, 2020 at 07:55:05AM +0000, Philipp Schafft wrote:> Why does Icecast forward both requests? Very simple: Not all auth setups > require username:password. E.g. some are only for logging and > accounting. Some auth using the IP address, which is already known in > the first request.Indeed. One of my streams has requested geoblocking, which uses exactly the mechanism you describe. -- Paul Martin <pm at nowster.me.uk>