Mirrors on fast HTTPS content delivery networks
This ticket is to document mirrors on fast HTTPS content delivery networks that are free for OpenSource Projects:
KeyCDN (Switzerland) https://www.keycdn.com/open-source-cdn
Fastly (US) https://www.fastly.com/open-source/
MaxCDN (US) https://www.maxcdn.com/open-source/
Cloudflare (US) with Galileo https://www.cloudflare.com/galileo/
Others need to be collected and, in the meantime, starting activating each of them and one by one providing as sponsored mirror as part of the VLC mirrors.
Activity
added Status::invalid label
@Courmisch why you (or someone else) deleted my comments listing the actual proprietary systems of commercial companies providing mirror services?
I've been suggesting to keep a coherent policy, if that's, to remove from your mirrors the many that are today the TOP per bandwidth as shown on https://get.videolan.org/vlc/last/win64/vlc-2.2.5.1-win64.exe?mirrorstats .
If by policy there should not be commercial companies and/or proprietary systems, then it's important to consider that cleanup.
Replying to [comment:2 naif]:
@Courmisch why you (or someone else) deleted my comments listing the actual proprietary systems of commercial companies providing mirror services?
Noone deleted your comments, else, they wouldn't be numbered starting by one.
However, our spam filter can be a bit aggressive.
@JB thanks.
I may suggest, if there's a policy of the organisation, to make it clear on the mirror web page, so that mirror contributors may know what's acceptable and what's not acceptable https://www.videolan.org/videolan/mirrors.html
-
Replying to [comment:4 naif]:
@JB thanks.
I may suggest, if there's a policy of the organisation, to make it clear on the mirror web page, so that mirror contributors may know what's acceptable and what's not acceptable https://www.videolan.org/videolan/mirrors.html
I already explained to you the reasoning: legally, we cannot use a root for the mirrors that is not in France. And we must have mirrors that are just syncing to us, not that we are pushing to. This rules out all the major CDNs.
As for the above list, only KeyCDN seems to match our ideals.
See our CoC.
@JB Ok, ok, let's try to be practical.
Let's say that a Linux User Group or OpenSource Advocacy Association in France or in Italy or somewhere in Europe, signup to the maximum number of CDN providers around the world for the goal of providing their own "VLC mirrors" and satisfy those requirements: a) The organisation that does the sync between VLC repository and the CDN is not in the US and is not VideoLan b) HTTPS download functionalities c) Free unlimited resources for opensource project
With that approach, would the VideoLan project be willing to accept a mirror service sponsored by such Association?
Because if so, it maybe quite easy to triage the problem and achieve one-shot big geo-distributed pipes for HTTPS downloads.
-
Replying to [comment:7 naif]:
@JB Ok, ok, let's try to be practical.
Let's say that a Linux User Group or OpenSource Advocacy Association in France or in Italy or somewhere in Europe, signup to the maximum number of CDN providers around the world for the goal of providing their own "VLC mirrors" and satisfy those requirements: a) The organisation that does the sync between VLC repository and the CDN is not in the US and is not VideoLan b) HTTPS download functionalities c) Free unlimited resources for opensource project
With that approach, would the VideoLan project be willing to accept a mirror service sponsored by such Association?
Because if so, it maybe quite easy to triage the problem and achieve one-shot big geo-distributed pipes for HTTPS downloads.
The answer is still maybe, as explained already, because unless it is our servers, we can never guarantee integrity/safety.
-
See #18492 (closed)#comment:5
Well, let me allow to be very practical.
The actual situation of software distribution security without HTTPS is quite poor.
I agree that having all on your own managed server would the perfect solution at all, but then looking at the reality of underfunded opensource projects, there's the need to find a solution in-between.
Like said by Voltaire "Perfect Is the Enemy of the Good" [1] so i really invite you to focus on the Good, looking in the perspective future at the Perfect solution.
-naif
[1] https://en.wikipedia.org/wiki/Perfect_is_the_enemy_of_good
-
Replying to [comment:12 naif]:
Well, let me allow to be very practical.
The actual situation of software distribution security without HTTPS is quite poor.
I agree that having all on your own managed server would the perfect solution at all, but then looking at the reality of underfunded opensource projects, there's the need to find a solution in-between.
That's quite ironic to be honest, seeing your past actions and sayings all over the net...
So i really invite you to focus on the Good, looking in the perspective future at the Perfect solution.
Yet, you claimed that using HTTPS on mirrors would solve all our issues...
Replying to [comment:14 jb]:
Also, some mirrors have very very poor HTTPS security or are in very difficult countries where the gov is intercepting all HTTPS traffic, so what would we do with those mirrors?
I'd suggest to write down a "mirror security policy" that say that the mirror should have:
- HTTPS enabled
- HTTPS passing at least rating "A" on https://www.ssllabs.com
The government can't intercept the HTTPS traffic, unless the CA that released the signed certificate it's under the governmental control (either directly or indirectly trough coercitive power).
Here you can take a political position, and allow allow "democratic countries issues CA", or just limit the uses of those mirrors by end-users that are already in the country (i.e.: China) considering that international-traffic is often explicitly shaped to favour national internet resources.
But as long as you have some piece of high bandwidth HTTPS pipes available where to drop files (directly or trough an intermediary organisation disconnecting the legal liability of VideoLan no-profit entity), I'd go for using.
Replying to [comment:13 jb]:
Replying to [comment:12 naif]:
Well, let me allow to be very practical.
The actual situation of software distribution security without HTTPS is quite poor.
I agree that having all on your own managed server would the perfect solution at all, but then looking at the reality of underfunded opensource projects, there's the need to find a solution in-between.
That's quite ironic to be honest, seeing your past actions and sayings all over the net...
All of the public actions are specifically focused on enabling HTTPS with the available resources for opensource projects, that are abundant on the internet.
Some folks that joined the campaign has been more "aggressive", but please consider that in none of my tickets and none of my tweet i ever insulted anyone of VLC project.
I feel to be operating in good faith, hope you get it.
So i really invite you to focus on the Good, looking in the perspective future at the Perfect solution.
Yet, you claimed that using HTTPS on mirrors would solve all our issues...
I confirm that vision, HTTPS on your website first and on the mirrors is going to solve all of the MITM problems.
-
Replying to [comment:17 naif]:
All of the public actions are specifically focused on enabling HTTPS with the available resources for opensource projects, that are abundant on the internet.
Totally untrue.
Some folks that joined the campaign has been more "aggressive", but please consider that in none of my tickets and none of my tweet i ever insulted anyone of VLC project.
Some folks, or your friends and colleagues?
I feel to be operating in good faith, hope you get it.
Sorry, but no. Your actions clearly disagree with this. You never tried to understand our constraints and discuss in good faith or just use the proper security discussion channels.
And your twitter account and retweets show the opposite.
So maybe now you want to discuss, but you did not want before. So let's start from here...
So i really invite you to focus on the Good, looking in the perspective future at the Perfect solution.
Yet, you claimed that using HTTPS on mirrors would solve all our issues...
I confirm that vision, HTTPS on your website first and on the mirrors is going to solve all of the MITM problems.
But the problem is not only MITM, it is about securing the first installation of VLC. And I don't see how your solution solves the issue.
Replying to [comment:18 jb]:
So maybe now you want to discuss, but you did not want before. So let's start from here...
Like Allen Gunner from Aspiration Tech (https://aspirationtech.org) say during the Tor Developers Meeting "I agree to disagree" and there's no problem on that.
But the problem is not only MITM, it is about securing the first installation of VLC. And I don't see how your solution solves the issue.
Ok, let me try to get a common ground on the steps where security can go in "securing the first installation of VLC" when the endusers wish to download VLC.
- Endusers find out where to download VLC
- Endusers connect to VLC website and click download
- Endusers are redirected to mirrorbits get.videolan.org
- Endusers are redirect to a mirror that serve the file
Each of this step may have it's own issue.
What I'm really focusing on is that to protect specifically against MITM attacks operated by an attackers with access to the network between the end-users and the file to download that's the most common and technically easy attack to be carried on, if point 2+3+4 are done in HTTPS, the first installation is protected.
Then you may argue that there is ALSO the risk of point "1" where there are websites clones of VLC spreading malware around, but that's a different taxonomy of risk, to be handled with multiple, different approach.
Then you may argue that there is ALSO the risks that the mirrors could be compromised or serve infected/modified files on-purpose, but somewhere i read that you are already checking automatically at regular intervals that the file on the mirrors match the checksum.
So while the "Perfect" solutions for 2+3+4 is to have your own high bandwidth servers, the "Good" solutions that effectively mitigate that specific MITM network-based attack protecting 2+3+4 steps, is adding HTTPS on videolan.org/get.videolan.org/mirrors while keeping your actual file integrity check of what's on the mirror.
Is this a reasonable split of the problems that we may try to address?
