TLS for VLC web interface
Apologies if this is already in the enhancements pool - I searched several ways and did not see it.
The VLC web interface does not seem to allow any meaningful form of security - that is, anything that can reach the host on which VLC is running can try to connect, and anything which can sniff on that network can trivially decode the base64 encoded password. As the remote interface by default allows browsing the whole file system, this seems like quite a large security vulnerability.
This enhancement request treats two areas:
-
By default, lock down what may be browsed through the web (And, really, all remote) interface(s) to a media-content-only directory, by default a new place which systems will NOT have, so that by default when any remote features are enabled NO content is effectively shared. e.g. {Windows} %USERPROFILE%\Videos\VLC\
-
Add SSL/TLS - preferably compatible with https://letsencrypt.org or something similar - to provide some degree of security for the web (and, again, really, all remote) interface(s) offered by VLC.
This is a dangerous world. VLC is widely used. The web/remote interfaces are great features from a usability and user perspective, which means they're very likely to be the subject of attack.
Activity
I don't really see how LetsEncrypt helps given that:
- Most hosts running the HTTP interface do not have a known stable domain name, or even a public IP address for that matter.
- VLC does not generally have access to the HTTPS port, and it is highly recommended to keep it that way.
- I am not aware of any lightweight embeddable client API native implementation for the service.
The VLC HTTP server has supported TLS/x509 for over a decade. In fact, up until VLC 2.0.0, the HTTP interface did support TLS. Nobody uses it because provisioning the certificate was so tedious. That does not excuse removing the working functionality (not me!). But to call that a solution for securing the HTTP interface is intellectually dishonest, in my opinion.
And restricting the file system access seems pretty vain. For common use cases, VLC would need access to the home directory and the optical drive mount points. This is as good as full user privileges already (e.g. it is enough to override
.bashrc).As far as I can tell, the only practical path to securing the HTTP interface is ironically to make it not HTTP.
Hi Rémi, Thanks for your quick feedback. I hope I can answer your concerns here, and persuade you and others that this is both desirable and achievable.
-
Since the web interface should only be used locally, or exceptionally in remote cases by more advanced users, for many use cases there should not be a need for any domain name other than .local. If a .local domain is undesirable or unworkable for whatever reason, a certificate can be either issued self-signed for a dynamic DNS hostname, or purchased through at least one dynamic DNS service: https://www.noip.com/support/knowledgebase/can-you-add-an-ssl-to-a-hostname-attached-to-no-ips-domain/ .. and it's quite easy and cheap to buy a domain name and small DNS hosting and set up a real domain and certificate, for those advanced users who want to set up access without self-signed certificate errors.
-
I'm not sure why "the HTTPS port" matters, since the HTTPS protocol may be used over any port, just as the HTTP "port" used by default by the VLC http server is the (commonly used, but still) non-standard 8080.
-
I believe that there are many HTTPS client libraries available, though I admit that the last time I actually programmed anything like this was 15 years ago... Here's one, specifically designed for much more lightweight than VLC's http server or a VLC remote mobile device client would need: https://www.insidesecure.com/Products/Data-Communication/Secure-Communication-Toolkits/GUARD-TLS-TK
-
File system - giving VLC access, explicitly, to %USERPROFILE%/Videos, and wherever else the %USER% wants his or her /Videos to be stored, with possibly multiple do-not-go-outside-of roots, is perfectly achievable. P2P programs offer this. And FTP servers. And others. ** http://www.coreftp.com/server/help/Account_Permissions.htm ** https://www.lifewire.com/steps-to-ensure-youre-safe-on-peer-to-peer-p2p-2487439 (search for "Don't share everything") Why would a common use case have the VLC remote server needing to server the home directory, rather than one or more specific media-only from-here-down-only root points?
I look forward to your further thoughts.
regards, Jay
-
-
Replying to [comment:2 Jay Libove]:
- Since the web interface should only be used locally, or exceptionally in remote cases by more advanced users, for many use cases there should not be a need for any domain name other than .local.
Wut? No! The whole point is to use it remotely. Locally, you can use the GUI.
The most common use case is VLC remote control third party apps.
If a .local domain is undesirable or unworkable for whatever reason,
Of course it is unworkable. VLC is not a DNS server.
a certificate can be either issued self-signed for a dynamic DNS hostname, or purchased through at least one dynamic DNS service: https://www.noip.com/support/knowledgebase/can-you-add-an-ssl-to-a-hostname-attached-to-no-ips-domain/
You cannot be serious.
.. and it's quite easy and cheap to buy a domain name and small DNS hosting and set up a real domain and certificate, for those advanced users who want to set up access without self-signed certificate errors.
You have a very personal notion of "easy and cheap". It is not easy, and any cost is unacceptable.
The argument that "any cost is unacceptable" should prove my point, which others have also been arguing for years, that because the current design bears a substantial security cost, it is unacceptable.
Okay, so the principal use case is remote. I just looked around a bit and was able to register a new .party domain for €5,25 for the first five years. I'm sure that, five years from now, I'd be able to find a cheap-enough renewal for the domain. And I didn't perform an exhaustive search to see which domains really are the cheapest over time. Others might be cheaper.
We know that free and cheap 'SSL' certificates are available.
For DNS, the providers Hurricane Electric, NS1, CloudFlare and others offer free low-volume plans.
As for not being easy, I argue that anyone who would set up a Dynamic DNS to be able to access their VLC truly remotely, or would arrange for a static IP address to be able to do so in the absence of Dynamic DNS, is already in the territory of the above being "easy" for them.
Regardless of whether it's "cheap" or "easy", it should be possible. At present, it is not possible to either "easily" (VPN? to quote you, "you cannot be serious") nor "cheaply" (because impossible is by definition not cheap) secure the VLC remote. Which is a real shame.
(And we mustn't forget the need to limit directory browsing, per the FTP, P2P, and other examples).
-
Replying to [comment:4 Jay Libove]:
The argument that "any cost is unacceptable" should prove my point, which others have also been arguing for years, that because the current design bears a substantial security cost, it is unacceptable.
Substantial development efforts and added usage complexity to replace an unacceptable design with another unacceptable design, no thanks.
Okay, so the principal use case is remote. I just looked around a bit and was able to register a new .party domain for €5,25 for the first five years. I'm sure that, five years from now, I'd be able to find a cheap-enough renewal for the domain. And I didn't perform an exhaustive search to see which domains really are the cheapest over time. Others might be cheaper.
We know that free and cheap 'SSL' certificates are available.
No, we do not. A free mechanism to obtain a valid x509 certificate for a host with neither known DNS name, nor a public IP address does not exist. It cannot exist by definition of how x509 certificates are validated in the context of HTTP/TLS.
For DNS, the providers Hurricane Electric, NS1, CloudFlare and others offer free low-volume plans.
That is totally irrelevant and inapplicable for most VLC HTTP users.
As for not being easy, I argue that anyone who would set up a Dynamic DNS to be able to access their VLC truly remotely,
I have no reasons to believe that most VLC HTTP interface users set up Dynamic DNS, so that is irrelevant.
or would arrange for a static IP address to be able to do so in the absence of Dynamic DNS, is already in the territory of the above being "easy" for them.
I think I mentioned not having a public IP address several times already.
Regardless of whether it's "cheap" or "easy", it should be possible.
Again, the problem is not theoretical possibility. The problem is (im)practicality.
We've gotten a bit lost in the details, which I responded to because they seemed to be points of concern for you. Okay, forget that. My proposals don't seem to be acceptable to you.
Everyone is a target. Automated weakness finders/ port scanners/ etc are everywhere, and this being a known weakness it likely is already being sought by the bad guys. "The bad guys only have to get lucky once. The good guys have to get it right every time". VLC remote is insecure. We're the good guys. We're not getting it right.
What CAN be re-designed/ implemented into VLC remote to allow this great functionality to be secure?
Untested patch available and submitted: https://mailman.videolan.org/pipermail/vlc-devel/2020-July/135747.html
added Difficulty::easy Type::patch labels
added Difficulty::guru Type::feature labels and removed Difficulty::easy Type::patch labels
changed milestone to %Features paradize
added Status::fixed label
changed milestone to %4.0
