Map all the existing VLC mirrors that already support HTTPS
This ticket is to map all the existing VLC mirrors that already support HTTPS in order to have a detailed and precise view on how much of them can starts serving VLC related files over a secure channel since tomorrow.
Once that mapping has been done, it's useful to analyse those mirrors for how much (in % percentage) of the total download traffic account, because if those represent =>80% of download traffic, it would maybe reasonable to think to cut the remaining 20% unless they enable HTTPS within few months.
Activity
List all mirrors that provide the last windows version of VLC using the parameter mirrorlist: https://get.videolan.org/vlc/last/win64/vlc-2.2.5.1-win64.exe?mirrorlist
For sake of curiosity see which are the top mirrors: https://get.videolan.org/vlc/last/win64/vlc-2.2.5.1-win64.exe?mirrorstats
Going on http://www.convertcsv.com/url-extractor.htm and load url
Extract file into mirror.txt
extract all URIs containing the filename vlc-2.2.5.1-win64.exe and put in miror-list.txt
$ grep exe mirror.txt > mirror-list.txt
count them
$ wc -l mirror-list.txt 78 mirror-list.txt
count how many are already HTTPS
$ grep -c https mirror-list.txt 26
So 26 out of 78 are already with https, with remaining 52 to be evaluated.
extract the 52 non-https mirrors to test if they have https
$ grep -v https mirror-list.txt > mirror-http-cleartext.txt
swap http with https string
sed -e 's/http:/https:/g' mirror-http-cleartext.txt > mirror-http-to-https.txt
starts logging all of our https download test
script test-download.out
start testing download directly to the existing mirrors
for mirror in
cat mirror-http-to-https.txt; do echo $mirror ; wget -O /dev/null --timeout=5 --tries 1 $mirror ; doneAs soon as I have the result, will post the log file and the analysis
The following are the "Excluded mirrors" that will be tested manually:
OK https://videolan.c3sl.ufpr.br/
OK https://mirrors.ustc.edu.cn/videolan-ftp/
OK https://mirrors.tuna.tsinghua.edu.cn/videolan-ftp/
HTTPS OK but wrong certificate http://vlc.viem-it.no/
HTTPS OK but wrong certificate http://mirrors.neusoft.edu.cn/videolan/ H
NO http://ftp.crans.org/videolan/ NO HTTPS
NO http://vlc-mirror.connect.net.pk/
NO http://mirror.isoc.org.il/pub/videolan/
NO http://videolan.mirror.neology.co.za/
NO http://videolan.nautile.nc/videolan/
NO http://www.gtlib.gatech.edu/pub/videolan/ (unreachable)
NO http://mirror.fibergrid.in/videolan/ (unreachable)
The following are the ones listed as HTTP but tested as HTTPS that works (so can be modified immediately as HTTPS):
OK ftp.icm.edu.pl - tested https://ftp.icm.edu.pl/pub/video/vlc
OK mirror.aptus.co.tz - tested https://mirror.aptus.co.tz/pub/videolan/vlc/2.2.5.1/win64/vlc-2.2.5.1-win64.exe
OK mirror.downloadvn.com - tested https://mirror.downloadvn.com/videolan/vlc/2.2.5.1/win64/vlc-2.2.5.1-win64.exe
OK mirror.kku.ac.th - tested https://mirror.kku.ac.th/videolan/vlc/2.2.5.1/win64/vlc-2.2.5.1-win64.exe
OK mirror.lstn.net - tested https://mirror.lstn.net/videolan/vlc/2.2.5.1/win64/vlc-2.2.5.1-win64.exe
OK mirror.ng - tested https://mirror.ng/videolan/vlc/2.2.5.1/win64/vlc-2.2.5.1-win64.exe
OK mirror.sfo12.us.leaseweb.net - tested https://mirror.sfo12.us.leaseweb.net/videolan/vlc/2.2.5.1/win64/vlc-2.2.5.1-win64.ex
OK mirror.zetup.net - tested https://mirror.zetup.net/videolan/vlc/2.2.5.1/win64/vlc-2.2.5.1-win64.exe
OK mirrors.netix.net https://mirrors.netix.net/vlc/vlc/2.2.5.1/win64/vlc-2.2.5.1-win64.exe
So out of 91 mirrors of which 3 not working, so 88 mirrors there are:
- 26 already working over https
- 9 saved as http but that works over https (so it's possible to change it)
So at 3-07-2017 there are 35 mirrors working with https out of 88 functioning.
This is completely stupid, as explained many times over and over, and on https://github.com/etix/mirrorbits/issues/59#issuecomment-312465869
We don't control those certificates at all. This does not solve any issue at all.
added Status::will not fix label
@JB do you see the technical analysis that benefit end-users?
Those certificates of those hosts are valid, recognised by Chrome and those download links, if accessed/clicked from a new videolan.org upgraded with HTTPS-default, cannot be attacked with a MITM.
That's not trolling, it's just a technical security analysis that for some kind of reasons you are not willing to accept.
I'm very worried that you don't want to acknowledge the security and trust model behind that, it's science, not an opinions.
-
Replying to [comment:7 naif]:
@JB do you see the technical analysis that benefit end-users?
Those certificates of those hosts are valid, recognised by Chrome and those download links, if accessed/clicked from a new videolan.org upgraded with HTTPS-default, cannot be attacked with a MITM.
That's not trolling, it's just a technical security analysis that for some kind of reasons you are not willing to accept.
I'm very worried that you don't want to acknowledge the security and trust model behind that, it's science, not an opinions.
Security of the HTTPS delivery of the binaries cannot be done unless you control all the servers.
Also, we cannot trust the CA model more than our GPG signature.
Our binaries are Windows Authenticode signed (similar on Android, iOS and macOS) and this works whatever the medium of download, be it HTTP, HTTPS, FTP or even USB key...
Case in point: https://www.vlc.de/
All downloads are done with VALID https servers, and yet, this page installs malware.
Your analysis of security on https is totally incorrect...
@JB hemmmm but you are trolling me or you really are not understanding what we are speaking about?
The normal scenario is as follow:
-
End users goes to videolan.org, and that's the root of trust because it's the brand advertised, will then follow a series of links by clicking around your website.
-
If all the links are in HTTPS and are using a valid certificate (also if not controlled by you), a third party will not be able to mount a MITM attack.
That's a point, full stop, don't deny this by speaking about Authenticode that have really nothing to do with what we are speaking about, because when a MITM attack happen, your signed binary will not even be downloaded by the end-user that's convinced to be speaking to videolan.org but instead is speaking to a nasty MITM attacking them.
Then, separately, if you have a branding problem because someone stole your name and use HTTPS to increase their outreach on search engine https://mainehost.com/google-starts-giving-ranking-boost-secure-httpsssl-sites/ but that's a very different problem, you are in low-ranking compared to a fake website because they are using HTTPS (and google boost them) but you are not using it.
-
-
Replying to [comment:9 naif]:
The normal scenario is as follow:
- End users goes to videolan.org, and that's the root of trust because it's the brand advertised, will then follow a series of links by clicking around your website.
End users goes to google, and types "vlc" and gets the 20 fake VLC website that buy adwords and other ads. Then gets virus.
- If all the links are in HTTPS and are using a valid certificate (also if not controlled by you), a third party will not be able to mount a MITM attack.
So you prefer to trust the tons of HTTPS and CA certificates compared to OUR signature?
Then, separately, if you have a branding problem because someone stole your name and use HTTPS to increase their outreach on search engine https://mainehost.com/google-starts-giving-ranking-boost-secure-httpsssl-sites/ but that's a very different problem, you are in low-ranking compared to a fake website because they are using HTTPS (and google boost them) but you are not using it.
OK, you go too far. Please don't use VLC and please go away with your hatred. We don't want people insulting our work like you around us.
You are now banned.
@JB You may re-read this tomorrow morning with a cup of coffee and discover that I never insulted you, but tried to help.
But if you do not wish to acknowledge the reality (including google boosting the ranking of HTTPS website faking your HTTP-only one), I cannot help you other than explaining and giving you external reference to read to understand.
-
Replying to [comment:11 naif]:
@JB You may re-read this tomorrow morning with a cup of coffee and discover that I never insulted you, but tried to help.
You've insulted us over and over. We're fed up with you.
Maybe your message has points, but maybe you'll try to be nice next time.
@JB you may look forward for any of my messages on the various post and highlight a single insult to you. You will not find it.
What's happening, that's creating a lot of worry, is the approach to denying what's technically correct from a security standpoint of view.
Obviously this drive anyone crazy, because denying the technically correctness of an analysis by posing out of topic arguments only spike a spike of discussion (me against you and so on).
I'm dedicating a certain amount of time doing technical analysis, suggestions and engaging in conversation not because I have a lot of time to waste, but because I sincerely think that there's a very important room for improvement that shall not be denied.
I'm professionally working in it security since 2005, I have nothing to earn from dedicating time in bringing suggestions there, other than trying to make the internet a safer place to stay (that's the reason I work on opensource security project since so much time).
Consider that when thinking that I am insulting and that I'm just trolling, I'm trying to bring topic that got just denied, rather than being acknowledged and then discussed to find out a step-by-step solutions.
Have a good night, and hope the conversation could goes on.
@JB Again, I'm not insulting you and you will not find a single insult from my against you.
Think about it, that maybe an excuse to avoid considering the security issues and the proposed improvement, but denying a scientifically correct statement is not the right way to go for the improvement of VLC project.
One approach is to find your most trustworthy security expert within your closed ties and have him independently read those tickets, then just listen carefully at his suggestions.
-
Replying to [comment:15 naif]:
@JB Again, I'm not insulting you and you will not find a single insult from my against you.
Yes, over comment 9 on this very ticket.
(And spamming our bugtrackers)
-
If anyone comes again on this old ticket, since then, all mirrors advertised from https://get.videolan.org/ should be now in HTTPS.
