GNOME Bugzilla – Bug 749481
Security of redirect to mirrors
Last modified: 2018-09-21 15:24:51 UTC
Hi, if the file accessed on "download.gnome.org" is accessed through HTTPS (in case it's not enforced by HSTS), redirect should be chosen so, it's HTTPS mirror as well. We're experiencing state of security confusion in current state. For reference I'm adding related discussion on Homebrew package manager, where the idea for me started [1],[2] Also, this fix should be applied so the resulting {.mirrorlist} meta file serves only mirrors with same or higher level of security (upgrading to HTTPS is OK, other way around obviously not) [3] I've also noticed that you're using MirrorBrain to resolve the mirroring service, it could probably be something to resolve on their side. [4] Thank you [1] https://github.com/Homebrew/homebrew/issues/39822 [2] https://github.com/Homebrew/homebrew/pull/38835 [3] https://download.gnome.org/WELCOME.msg.mirrorlist [4] https://www.mirrorbrain.org/
Hey Marek, as you correctly pointed out download.gnome.org is not a mirror on its own but a Mirrorbrain instance that redirects the user to the best mirror in terms of proximity through the mod_geoip module. I'm not sure whether all of our mirrors will ever decide to switch to HTTPS by default or even make it available together with HTTP but what I would suggest right now is: 1. On the GNOME Infrastructure side: double check all the mirrors again and see whether any of them now supports HTTPS, if yes, update the reference at download.gnome.org. Probably giving mirrors that support HTTPS some more priority than others might also help short term. 2. On the homebrew side: for the case a HTTP mirror is selected make sure homebrew notifies the user that a downgrade from HTTPS has happened behind the scenes. You can use the 'Location' header for checking what the effective download URL will actually be. Then prompt the user to continue or abort the connection and if possible include a list of the enabled HTTPS mirrors the user can select from.
Hello Andrea, thank you for your response. 1. That would be great for opt-in HTTPS only mirrors usage, in my opinion, it's not necessary to switch to HTTPS ultimately (although it would be great), especially for long-term support products with possible hard-coded HTTP usage or for clients unable to verify the CA chain. However important is to keep the security chain, which means, not redirect to HTTP from HTTPS, which should be possible, as I don't see HSTS enabled on download.gnome.org subdomain 2. Yes, that is actually already being implemented in a way you suggested, along with option to disable redirect to non-ssl mirror (which could be easily checked if there is appropriately updated .mirrorlist file, in other cases, that would require hard-coding or brute-force checking whether given mirror is HTTPS enabled. Given your response, do you think the information in .mirrorlist files will be updated any soon, so we could base the decision logic on it? I.E. the referenced WELCOME.msg.mirrorlist should contain HTTPS URLs if the mirror is HTTPS enabled. Possible would be also to update your mirror rating algorithm (which is now strictly location-based I guess) to give higher priority to HTTPS enabled mirrors, which would naturally push other mirrors to adopt the HTTP security measures.
I verified what mirrors provided HTTPS, they are: https://mirrorservice.org https://mirror.umd.edu https://ftp-stud.hs-esslingen.de I've updated their reference at download.gnome.org and bumped their priority by 20 points, that should help as a first step.
An update on this: fr2.rpmfind.net ftp.acc.umu.se ftp.heanet.ie mirrors.ustc.edu.cn are now SSL aware. URLs at download.gnome.org have been updated.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/9.