Project

General

Profile

Bug #5601

haproxy can only authenticate via plaintext

Added by Kim Steglin over 5 years ago. Updated over 5 years ago.

Status:
New
Priority:
Normal
Category:
Streaming
Target version:
-
Start date:
2019-04-12
Due date:
% Done:

0%

Estimated time:
Found in version:
4.3-1789~g6bfeca6c0
Affected Versions:

Description

I have set up HA-proxy to be able to stream any content from anywhere, without complicating the setup with vpn clients an such.
I do have vpn but all the clients does not support it or is a hassle to set up, so keep that option not an option.
On travels i use android tv with kodi and thveadend pvr ( HTSP )
In my home i have set up paswordless access, and from anywhere else i have password access.
To benefit from this im using the option "PROXY protocol & X-Forwarded-For:" along with haproxys option forwardfor to ge the client ip.

If i dont use X-Client-IP the source will be my internal haproxy seeing it as local network and the user will not need to authenticate, ie the headend server is wide open...
Therefor im useing the client ip to determen the access control.
This is not a critical issue as i have ssl termination on the proxy, but it is disturbing.
As im unaware how the HTSP protocol works and set to plaintext auth i fel unsecure... Is this a critical issue or not?

The bug:
In this setup, i can only have plaintext authentication, digest authentication just sends 401 back to the client without a http auth request.

Thvhedend settings,
user * allowed networks 192.168.0.0/16 no password
user user1 allowed networks 0.0.0.0/0 with password
user user2 allowed networks 0.0.0.0/0 with password
...

working with ONLY plaintext authentication set ( digest and plain, does not work )

HAproxy settings,
defaults
mode http
option forwardfor except 127.0.0.0/8

frontend http
bind *:80
redirect scheme https code 301 if !{ ssl_fc }

frontend https
bind *:443 ssl crt /valid/certificate.pem
http-request set-header X-Forwarded-Port %[dst_port]
http-request add-header X-Forwarded-Proto https if { ssl_fc }
redirect scheme https code 301 if !{ ssl_fc }

backend tv_ssl
server tv 192.168.1.11:9981 check

History

#1

Updated by Kim Steglin over 5 years ago

Client:
VLC 3.0.7

#2

Updated by Jaroslav Kysela over 5 years ago

Show the TCP communication (HTTP protocol) between your proxy and tvheadend for the digest authentication. You may use wireshark - TCP decode.

#3

Updated by Flole Systems over 5 years ago

As far as I know VLC (at least 3) doesn't support digest auth. If it works with a Webbrowser that's most likely the issue.

#4

Updated by Kim Steglin over 5 years ago

If that is an issue with VLC then this is a non issue.

I thought it might be VLC spooking aswell.
Then i have to rethink the setup to make it as secure as i feel comfortable.

Im fine with the resolution.
Thanks for the time

#5

Updated by Flole Systems over 5 years ago

This just came to my mind and might help you: I noticed a while ago that when allowing digest and plain auth you can specify the data in the url like https://user:[email protected]/mystream to get around this issue.

#6

Updated by Kim Steglin over 5 years ago

Yeah,

you are correct.
And this is an VLC issue not a tvheadend one.

Thanks once again.

Also available in: Atom PDF