Password Required for Web Interface

This is intended. Running the interface without password is crazy.

closed

Why not leave the security decisions to the user as has been the case in every previous version of VLC? Security is a series of tradeoffs that are usually best evaluated by the user since they have knowledge of their own environment and threat model requirements.

In my opinion, making sweeping generalizations is "crazy".

I accept your unwillingness to fix this issue, but for me, the tradeoff in security vs convenience (HTTP basic auth vs one less required configuration option) would not have been worth making.

Replying to [comment:2 Guiser]:

Why not leave the security decisions to the user as has been the case in every previous version of VLC?

There was ample evidence that a large number of users were being mislead in enabling the HTTP interface unaware of the actual impact.

Security is a series of tradeoffs that are usually best evaluated by the user since they have knowledge of their own environment and threat model requirements.

In this particular case, there is ample evidence that, "the user" did not at all have proper knowledge of the environment and the threat model.

Replying to [comment:3 courmisch]:

Replying to [comment:2 Guiser]:

Why not leave the security decisions to the user as has been the case in every previous version of VLC?

There was ample evidence that a large number of users were being mislead in enabling the HTTP interface unaware of the actual impact.

courmisch, I get that there was a security issue you're trying to fix. In a business setting of any kind I agree that it's unwise to have open connections. One issue that I'd like to bring to your attention is that VLC is now unusable for Windows phones. I understand that I'm in the minority, but the only app I've found to connect to VLC and watch videos from Windows Phone does not have the option of setting or using a password. I'll be sending a request to that developer to update the application, but I have no guarantees that it will ever happen. For now my only option is to down-grade back to 2.0.9 and cross my fingers. I also don't have any real expectations that you'll take this issue back up again, but I'd certainly hope to persuade you to re-consider. Thank you.

Indeed this is very unfortunate. For example the Freebox V5 is able to control VLC through HTTP but cannot provide passwords ("freeplayer"). So now I have to find an alternate HTTP server without password that controls VLC somehow.

I am the user, and I would have liked to be able to make the choice about my systems and network security.

Original author: david cavallini

Replying to [comment:5 david cavallini]:

I am the user, and I would have liked to be able to make the choice about my systems and network security.

By the same line of reasoning, you should have the choice to not use (or not even have) a safety belt in your car because you will be driving it. And yet, in most countries, the safety belt is mandatory for obvious reasons.

Having your computer compromised via an unprotected VLC instance will not only hurt you, it will hurt others on the Internet too.

By the same line of reasoning, there would be no free Internet at all. Unfortunately some freedom comes at the cost of some risk. Anyway my VLC/computer was not compromised as my scripts in --http-src=/x/y are simple and stupid enough to not allow anything except the box to play the film. So no: HTTP without password is not as such a security risk (furthermore, I don't think adding a password without encryption protects against anything apart legitimate use).

Original author: david cavallini

I agree that this is one of the big stupidities that I have experiences from VLC.

Is an annoyance that the choice is not left to the user. I am running all this on a LAN and I want to be in power of what my software does. If VLC chooses not to provide me with that I will purge the program. It is a huge inconvenience now that half my software that was feeding from the web interface for VLC would not work properly.

Replying to [comment:7 david cavallini]:

By the same line of reasoning, there would be no free Internet at all. Unfortunately some freedom comes at the cost of some risk.

No. This is about mandatory safety only. Functionally, not a single feature was removed from the HTTP interface while enforcing the password.

Anyway my VLC/computer was not compromised as my scripts in --http-src=/x/y are simple and stupid enough to not allow anything except the box to play the film. So no: HTTP without password is not as such a security risk (furthermore, I don't think adding a password without encryption protects against anything apart legitimate use).

If you can modify the source code, then you can disable the password anyway. This is about the other 99,9% of users who do not modify the HTTP back-end scripts, and are thus exposed.

Hum I don't think people complain here without reasons. My lost functionality is called FreePlayer and was working with VLC HTTP server for almost 10 years. Of course there are plenty of workarounds. Mine is to pick another HTTP server (no matter which because no other HTTP server I know implements basic authentication as a mandatory safety to run scripts). This is far more complicated though because you must control VLC from libvlc or another interface.

Regarding patching VLC source code to undo this mandatory safety, of course this is trivial for you. But personally usually I still find it a level of magnitude easier to use the command line and configuration screens (even VLC's).

Finally of course there would be plenty of other solution that would protect the standard user without breaking this stuff for power users.

Original author: david cavallini

Replying to [comment:6 courmisch]:

Having your computer compromised via an unprotected VLC instance will not only hurt you, it will hurt others on the Internet too. what if it would accept only local connections?

how this control http interface compares to wanted DLNA server in VLC?

users might find weird that it's not possible to define user name...

services.webserver

Replying to [comment:9 courmisch]:

Replying to [comment:7 david cavallini]:

By the same line of reasoning, there would be no free Internet at all. Unfortunately some freedom comes at the cost of some risk.

No. This is about mandatory safety only. Functionally, not a single feature was removed from the HTTP interface while enforcing the password.

Anyway my VLC/computer was not compromised as my scripts in --http-src=/x/y are simple and stupid enough to not allow anything except the box to play the film. So no: HTTP without password is not as such a security risk (furthermore, I don't think adding a password without encryption protects against anything apart legitimate use).

If you can modify the source code, then you can disable the password anyway. This is about the other 99,9% of users who do not modify the HTTP back-end scripts, and are thus exposed.

Ha I agree that open source is good, however, if I want a program to work I would not waste the time to re-program / re-code and modify it to that extend. Anything mandatory is not good. there should be an easy option to disable the MANDATORY HTTP back-end script which required the password. Why would Microsoft (Windows) / Apple (OS X), any major company give the option for automatic login! Is it mandatory??? I don't think so. highly suggested - yes. Everything is about approach here. People don't just complain without a reason.

Replying to [comment:12 skyrebel]:

Why would Microsoft (Windows) / Apple (OS X), any major company give the option for automatic login!

VLC does not require any login for local usage, only for HTTP (so remote) access. Sorry but you're not making any sense.

I'm having problems with this "feature", just because the empty user. I can't simply specify a URL containing a password and an empty user, as stated on rfc1738. Both username and password are optional on a URL, and you can specify a username without password, but not a password without a username.

So I can't check anymore the VLC playlist from my (awesome) hackish scripting system, because neither wget nor curl will accept an empty user with a password.

I'm forced now to fallback to the rc interface by issuing commands with telnet.

Just my two cents on this matter as a user.

Perhaps the UI should accept any username, but really that is a different problem than requiring a password.

Also RFC1738 is obsolete. RFC3986 does not forbid an empty username (in fact, it discourages passing credentials in URLs).

Oh, right. That RFC states that "The userinfo subcomponent may consist of a user name and, optionally, scheme-specific information about how to gain authorization to access the resource" so yes, the username is mandatory.

Anyway, the problem here is that I can only access the web interface by using Firefox or Chromium, but not any other CLI tool, because all of them are using the username:password syntax, even when sending the userinfo inside the digest, not in the URL.

VLC is rejecting any of my attempts of empty username with these tools. So yes, it perhaps should accept any username, or let the user configure it at least.

So should I open a new ticket?

I just found a way to get access to the http interface within php scripts:

<?
// run this script while playing a song with vlc and the http interface enabled
// the original script is part of netjukebox (netjukebox.nl)

//vlc-client configuration
$cfg['player_host'] = "192.168.1.11";
$cfg['player_port'] = "8080";
$cfg['player_pass'] = "secret";

echo("<pre>" . vlc("pl_pause") . "</pre>");

function vlc($command) {
    global $cfg;
    $request  = 'GET /requests/status.xml?command=' . $command . ' HTTP/1.1' . "\r\n";
    $request .= 'Host: ' . $cfg['player_host'] . ':' . $cfg['player_port'] . "\r\n";
    $request .= 'Connection: Close' . "\r\n";
    $request .= 'Authorization: Basic ' . base64_encode(':' . $cfg['player_pass']) . "\r\n\r\n";
    
    $soket = @fsockopen($cfg['player_host'], $cfg['player_port'], $error_no, $error_string, 1) or die();
    @fwrite($soket, $request) or die();
    $content = stream_get_contents($soket);
    fclose($soket);
	
    $temp = explode("\r\n\r\n", $content, 2);
    if (isset($temp[1])) {
        $header = $temp[0];
        $content = $temp[1];
    }
    
    return $content;
}
?>

For my part I'm happy to use netjukebox again with vlc.

mentioned in issue #15578 (closed)

Password Required for Web Interface

Child items ...

Activity