Skip to content

Discussion: VLC HTTP interface: security, remote control and announcement

VLC HTTP interface: security, remote control and announcement

Context

This follows up the discussions resumed during VDD 2023 regarding the VLC web interface.

Based on these previous discussions, ideally, VLC web interface could be improved:

  • Be more secure
  • Be more friendly for remote controling (ie. LAN announcement through mDNS)

This non-exhaustive study tries to describe the VLC web interface general security status and tries to propose security enhancement.

Pretty much any part/proposition is open to discussion/suggestion/improvement.

Apologizes in advance: this is far longer to read (and write) than I anticipated.

TL;DR

  • If we want to add LAN announcement for remote control, we need to increase web interface security
  • If we want to increase web interface security, we need to switch sensitive info & actions to HTTPS
  • out-of-the-box HTTPS on VLC web interface seems to imply self-signed certificate generation
  • non-browser clients should be fine
  • browser users will have to deal with the self-signed exception acceptance

Current status

Current web interface usage

VLC interface is (mainly) used for:

  • Browser remote access
  • Remote controling VLC

Current web interface security

  • VLC Web interface is in plain HTTP
  • The authentication is based on basic auth (option --http-password), without the user credential.

A little bit of risk management

What VLC is supposed to protect (sensitive assets)

Basicaly, VLC should avoid to be the initialization of attacks that could leak (confidentiality) or alter (integrity) the user environment on the machine VLC is installed. This includes:

  • files on desktop environments
  • personal information, credentials, etc.
  • the machine integrity/availability

This does NOT mean VLC should be the only one responsible for the security of these assets, of course.

Example: if the machine-local user is leaking data (even VLC-related info) through another way, this is not VLC's responsibility...

Attack scenario(s)

Typical scenario for the web interface:

  • VLC web interface is enabled and VLC is running on a machine/device
  • the VLC machine/device is connected to a LAN
  • VLC web interface "client" (browser or remote control) is connected on the same LAN
  • Given the type of LAN, other devices are connected on the LAN and can be controled by attackers

Examples:

  • low chance of attacks:
    • home LAN (I hope for your sake)
    • heavy-controled/administrated entreprise LAN
  • high chance of attacks:
    • connected on a public/hotel/fast food Wifi,
    • a badly administrated LAN (ie. no-to-low budget University LAN sysadmin, usually focused on University services security, not judging of course).
    • Basically, any network with too many users and not enough money spent on security.

One of the common (and probably worst) cases for starting an attack is ARP spoofing/poisoning, although this is not the only one, of course.

  • attacker forces machines MAC/IP table changes to create a MitM (man-in-the-middle) attack
    • in short, the attacker can be in the middle of the discussion between the browser/remote and VLC web interface/machine
    • mitigations exist, most of them on the switching devices (Wifi access point, ethernet switch, etc.), usually on entreprise-grade devices.
    • this is absolutely not guaranteed on a public wifi/open network...

Current Risk estimation

  • Probability is low to very high, 100% based on the network administration: HTTP allows a lot of attack surfaces
    • easy service spoofing
    • easy data sniffing (eavesdropping)
  • Impact: extremely high: web interface has a lot of capabilities
    • local filesystem listing
    • exporting/downloading (through stream output)
    • potential harmful actions (overriding local files/etc.)

So risk (Probability * Impact) is... Well, there could be room for improvement.

Mitigation

LAN Trust estimation is hard

A simple idea would be to detect if the machine is connected to a "trusted" LAN, where attackers (should?) are not likely to be connected.

Unfortunately, just for Desktop machines on a wired LAN scenario, it looks like a nightmare (no "home" SSID to detect, network IP ranges could be the same, etc.)

(Advanced?) users could estimate that more accurately, but they would have to be guided (Example: display a big DISCLAIMER).

Mitigation proposal: split the web interface in two

During VDD 2023, one of the suggestion was to split the web interface in two:

  • one with "low" security and low capabilities
    • Example: keep plain http with password, but limit to player controls only (play, pause, next, stop, etc.), but without any information on media played (so no track selection, etc.)
    • Add a disclaimer inviting to swith to the "strong" interface (and redirecting to it)
    • this could be used for "retro-compatibility" with VLC3 remote users
  • one with "strong" security and high capabilities, that could lead to a potential LAN announcement.

This seems a good compromise, at least for VLC3 -> VLC4 switch compatibility reasons.

HowTo stronger security on VLC HTTP Interface (at least trying to)

Recap: clients of VLC web interface

There are two types of clients:

  • browsers
  • other clients (mobile apps, remote controls, etc.)

First things first: avoid HTTP

  • Plain (HTTP) transmissions implies too many "easy" attacks (password leak, info leak, spoofing, etc.)
  • The natural solution is to provide an HTTPS service
  • Based on this secure connection, add methods to share secrets between the client and VLC
    • password (already exists)
    • pin code or QRCode displayed on VLC device local display, or any communication layer that does not imply the LAN.

But...

HTTPS is not that simple

The most straightforward solution to provide an HTTPs interface for VLC is to generate a self-signed certificate:

  • No third-party service dependency
  • Can be generated easily during VLC Installation process.

Problem with self-signed certificates

  • They are natively considered harmful by every browser - for a good reason: a big part of the trust chain on the Internet (so non-local networks) is based on CA (Certificate Authority, see https://en.wikipedia.org/wiki/Certificate_authority), considered safe and the only entities able to deliver certificates automatically trusted by browsers.
  • As there is no link to trusted CAs, anyone can generate a self-signed certificate, and if the user or client does not check the certificate identity (signature/hash), it will not prevent MitM attacks
Client trusting IP + certificate --HTTPS(self-signed but not the good one)--> Attacker --HTTPS(self-signed, the good one)--> VLC(HTTPs Interface)

Providing a non self-signed certificate to VLC

Trying to provide a proper valid CA-based certificate seems very tricky.

Adding a single valid certificate in VLC installer

Technically, this could work:

  • generating a CA-signed (ie. LetsEncrypt) wildcard certificate on *.lan.videolan.org (not caring about deadline validity here)
  • provide a DNS resolution service that resolves deterministic entries based on the local IP address.
    • example: 192-168-0-42.lan.videolan.org resolved to 192.168.0.42
  • including the public certificate and private key in VLC packages
  • client connects to VLC web server to https://192-168-0-42.lan.videolan.org

BUT

  • This does not resolve anything regarding MitM attacks, as the certificate private and public parts are accessible to anyone
  • The domain would probably be banned extremely fast by browser or root CA (this could be used for other spoofing attacks)
Provide one valid certificate to any installed VLC (Plex style)

Plex has some interesting way to provide valid certificate to local Plex instances: https://words.filippo.io/how-plex-is-doing-https-for-all-its-users/

The idea is to:

  • generate a CA-signed wildcard certificate on *.<id>.<domain>, where:
    • <domain> is a static domain
    • <id> is a user and/or server identifier
    • example: *.aaaa-bbbb-cccc-dddd-1242.plex.lol
  • the local instance retrieve the private/public part of the certificate (through user account local registry)
  • plex.lol DNS domain resolves to the same deterministic entries based on local IP address (like in previous section).
  • example 192-168-0-42.aaaa-bbbb-cccc-dddd-1242.plex.lol resolves to 192.168.0.42

BUT

This seems very difficult to apply to VLC:

  • All of this suppose VideoLAN provides a service that provides such certificates to VLC instances all over the world
    • this would imply being able to generate at least millions of certificates to a CA (ie. LetsEncrypt)
    • I fear this would be considered as a DDoS from the CA...
  • VLC does not include any user/account identification, nor VLC installation uniqueness
    • as a consequence, if a VLC instance is able to ask for a certificate to VideoLAN service, then... anyone can ask for one, not just VLC
    • if <id> uniqueness is somewhat guaranteed, this would resolve the MitM problem (an attacker would get a certificate with another <id>)... But domain ban would probably be fast as well...
Conclusion on public CA-signed certificate

I cannot see any proper way to provide some for a VLC installation...

Using an trusted intermediate

See: https://code.videolan.org/-/snippets/1789

The idea would be to use a "trusted" url (ie. an HTTPS url with a valid public domain, like "https://checkmylan.videolan.org" to

Short answer

This does not work for browser.

Longer answer

  • browsers enforces having a direct connection workflow for self-signed certificate exception (which is not surprising)
  • The webpage has no access to the underlying connection security details: no certificate details, no self-signed or non-self-signed/exception info, etc.
  • So there is no real way to add a user check (through a visual representation for example)

Theoretically speaking, there could be a way to have a valid "hybrid" (local/remote) version of the web interface:

  • have a link to a valid public domain and some local server connection info included in a QRCode or an URL provided locally by VLC
  • example: https://lan.videolan.org/?local_ip=...&local_cert=...
  • serve static files (js, css, html) through this domain (here https://lan.videolan.org)
  • create another (secure) channel for local communication. This can be done:

But adding these (HUUUUGE) network stacks inVLC just for some local communication seems UNreasonable (please no).

Conclusion

HTTPS with a self-signed certificate locally generated at VLC installation process (or provided by the VLC user) seems the only proper solution.

The only real (big) drawback is to help the user properly perform a check on the self-signed certificate public signature and after that accept it.

Example of VLC web interface authentication

Here is a "simple" authentication that can be done on top of trusted HTTPS connection.

Any smarter protocol or workflow improvement suggestion is welcome.

Sharing secrets with another physical channel

At first connection, VLC provide a local display with:

  • a visual representation of the self-signed certificate signature (through Hash visualization1 for example, like ssh randomart), either in asciiart or picture
  • a shared secret, like a pincode
  • OR a QRCode with both previous information (certificate signature + pincode)

Check server identity

  • The certificate signature should be sufficient to provide verification for server identification
  • For native app/remote control client, the client should:
    • retrieve the server certificate signature used within the HTTPS connection
    • display the visual representation of the certificate and ask the user to check the similarity with VLC local visual representation
    • if the client is able to use the QRCode, check directly with the QRCode info
  • For browsers... The user needs to add the self-signed certificate as a trust exception in good conditions
    • If VLC asks the user to take a risk, this could be a good idea to provide some guideline to do so
    • example: provide a videolan.org web page (and/or a link from VLC UI) explaining certificate exception should be:
      • NEVER accepted on a public wifi or widely open network
      • ONLY accepted unless fully verifying the signature OR be on a 100% trustful network (ISP home LAN, mainly)
      • and add a link redirection to local (VLC) URL.

This would ensure that the HTTPS connection is direct (no way for an attacker to trigger a MitM if the client is sure the server connection is built on top of a specific certificate)

Note: This step is even more crucial, given the fact the code that will be executed by the browser is provided... By the server itself.

Provide a challenge to the client

Naive strategy:

  • the client asks for an authentication challenge
  • the server provides random bytes data (to avoid replay)
  • the client combines the random data and the PIN code, and send a (strong) hash to the server
  • the server compute the same operation on its side and verify the result is the same. There should be a maximum (small) number of tries.
  • for the rest of the connection lifetime, the server can consider the client is authenticated
  • I suppose this could be persisted with a (randomly generated) cookie provided by the server.

Notes:

  • "secure" context (https) enables WebCrypto API in the browser, so strong digest function can be used
  • if the cookie & VLC certificate is stored on client, this could be a persistent way for the client to reconnect, as long as VLC IP server does not change
  • however, this naive strategy would imply the server stores the cookie locally. This could be stored the same way as credentials for VLC connections (keystore, etc.)
  • the cookie providing context probably needs to be restrictive:
    • Secure (https)
    • SameSite=Strict
    • with max age (mandatory for cookie persistence)

  1. see "A. Perrig and D. Song, Hash Visualization: a New Technique to improve Real-World Security, 1999, International Workshop on Cryptographic Techniques and E-Commerce (CrypTEC '99)." ↩

Edited by Simon Latapie
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

VideoLAN code repository instance