All of this is well and good as long as we remember that digital signing of anything only provides security in processes which verify the signature. Installation through Linux software repositories verifies the signature. Installation on Macs verifies the signature provided the user does not click through warnings (which is common practice). Installation on Windoze verifies the signature provided the user does not click through warnings (which is a required practice in almost all cases). VLC's internal update system presumably verifies the signature. Hence, VLC's security model only provides satisfactory protection in maybe 50% of cases. Despite the comparative weakness of the web browser's WoT compared to possibly the software signing WoT, adding TLS would considerably lock down the number of attack vectors. Windoze is likely already vulnerable to state actors in a hundred other ways such that VLC's installation process isn't the highest priority, but the vast majority of attacks are not from state actors and protecting against smaller attacks is important.


Yours sincerely,

Bardi Harborow
Software Engineer
Mobile: +61481816153
Web: bardiharborow.com

I acknowledge the Wurundjeri people, who are the custodians of the land upon which I live and work. I pay respect to their elders past and present.

On Tue, Jul 4, 2017 at 12:24 AM, Steve Kinney <admin@pilobilus.net> wrote:


On 07/03/2017 08:36 AM, Fabio Pietrosanti - Lists wrote:
> Hello,
>
> as we move to improve the status of encryption of the internet and at
> all levels internet companies diffuse the uses of HTTPS encryption and
> integrity protection methods there are still a variety of massively
> diffused pieces of software that can be subject to malware injection
> trough MITM techniques.
>
> VLC, Videolan Client, the most used opensource video player have their
> entire website in HTTP, their download page in HTTP and the mirror
> providing the downloading in HTTP.
>
> However they are refusing to implement HTTPS arguing that because their
> .exe are digitally signed with authenticode they are safe
> https://trac.videolan.org/vlc/ticket/18472 .

From the post @ videolan.org:  "VLC trust and diffusion has been also
being exploited by CIA."  And:  "So VLC is responsible to let attacks
inject malware bundled with the software package, because it's only VLC
project maintainer responsibility to use HTTPS as the only method to
prevent a third party attacker to hijack VLC website content and files."

Against hostile State actors, HTTPS only provides a false sense of
security.  If your threat model includes the CIA, reliance on HTTPS is a
fundamental error in the "game over" category.

The HTTPS procotol implemented in web browsers relies on digital
signatures by 3rd parties called Certificate Authorities to
transparently verify that the key used for the "secure" connection
belongs to the website in question.  Any actor who owns a copy of any
one of the numerous Certificate Authorities' signing keys can sign an
SSL certificate in any website's name, and it will be accepted as
authentic by any web browser.

The HTTPS trust model is broken at the foundation.  This does not make
HTTPS useless; smaller criminal organizations and hostile individuals do
not normally have access to Certificate Authority signing keys, and so
can not effectively do man in the middle attacks against HTTPS
connections.  In most cases implementing HTTPS is worth doing - as long
as it is understood that this provides no protection against large, well
funded adversaries.

> Please help me explain them how digital attacks works, or please someone
> make a MITM video-screencast to show them how urgent and important is to
> upgrade all of the connections to HTTPS.

See above:  It seems likely that the people at videolan.org have a basic
understanding of how digital attacks work, more so than someone who
believes that HTTPS can interfere with attacks by State actors.

If it is urgent and important for videolan.org to use HTTPS, preventing
MITM attacks by State actors (or other criminal gangs with substantial
resources) is not the reason.

A more effective way to protect against malware injection via
substitution of executables in transit, is for the distributor to
digitally sign the installers themselves.  This method is not 100%
reliable - nothing is - but at present it's the best method we have.
And note that it is already implemented in the Linux software repositories.