VLC’s updating mechanism still uses HTTP over HTTPS

Last week, a bug was reported to the VLC bug tracker that all the connections to the update server are still done in HTTP instead of HTTPS. One of the VLC developers replied back asking the bug reporter for a threat model, and when he did not submit it, the VLC developer closed the bug and marked it as “invalid”.

This is not the first time this bug has been reported. In a bug reported in 2017, a user said, “It appears that VLC's updating mechanism downloads a new VLC executable over HTTP (ie, in clear-text). Please modify the update mechanism to happen over TLS (preferably with Forward Secrecy enabled).”

What are some of the implications of using HTTP over HTTPS?

One of the Hacker News users said, “As a trivial example, this is a privacy leak - anyone on the network path can see what version you're upgrading to. It doesn't sound like a huge deal but we are moving to a 100% encrypted world, and it is a one character change to fix the issue. If VLC wants to keep the update over plaintext then they should justify why they want to do that, not have users justify why it should be over https. Instead, it feels like the VLC devs are having a kneejerk defensive reaction.” Along with this, there are several security threats related to software that updates over HTTP, some of which are described here:

An attacker can see the contents of software update requests. They can then modify these update requests or responses to change the update behavior or outcome. They can also intercept and redirect software update requests to a malicious server.

Attackers can respond to the client request with a huge amount of data that will interfere with the client’s system resulting in endless data attacks.

Clients can be prevented by the attackers from being aware of interference with receiving updates by responding to client requests so slowly that automated updates never complete resulting in endless data attacks.

Attackers can trick a client into installing software that is older, which is known to have critical bugs.

Why VideoLAN does not see it as a big problem?

Jean-Baptiste Kempf, the President, and lead VLC developer, said that some of these attacks described above are the case for nearly all download systems, “I'm sorry, but some described attacks (Slow retrieval attacks, Endless data attacks) are issues that are the case for all download system like most Linux Distributions, and that will not be fixed. Mirrors are HTTP and will stay HTTP for a few obvious reasons. Moreover, they will install binaries, so there is no security issue. Moreover, downloads are never done automatically, without user intervention.”

As Kempf said, this is not just the case with VLC. A Hacker News user said, “it seems to be a common practice for highly-loaded services to outsource as many cryptographies to clients as possible.” A general-purpose package manager like Pacman uses HTTP because there is not much value in using transport-level security when the payload is cryptographically signed. Even Tesla’s firmware updates are not encrypted in transit as their updates are cryptographically signed. Oracle also followed the same policy with VirtualBox distributions and that's been fine because they signed packages.

You can read more in detail on the VLC bug tracker website.

dav1d 0.1.0, the AV1 decoder by VideoLAN, is here

Presenting dav1d, a new lightweight AV1 decoder, by VideoLAN and FFmpeg

dav1d to release soon with all features of AV1, and better performance than libaom