Task #1987
openPlease use HTTPS for downloads to protect users
Added by Tom Delmas almost 8 years ago. Updated almost 5 years ago.
0%
Description
The link on the secure page
https://www.libreoffice.org/download/libreoffice-fresh/ for "Download Version 5.1.4"
launch download from the insecure HTTP link
http://ftp.free.fr/mirrors/documentfoundation.org/libreoffice/stable/5.1.4/win/x86/LibreOffice_5.1.4_Win_x86.msi
A Man in the Middle could replace the legitimate file by an infected one.
It's not realistic to except the user to check manually the checksum of the file.
I see at least two ways to correct that behavior:
Using only https mirrors is one solution. Another one could be a small downloader, downloaded from the https official website, that download from mirrors/torrent and check the checksum before install.
History of that problem: https://bugs.documentfoundation.org/show_bug.cgi?id=100824
Related issues
Updated by Samuel Mehrbrodt about 7 years ago
- Subject changed from Please use HTTPS for dowloads to protect users to Please use HTTPS for downloads to protect users
Updated by Guilhem Moulin over 6 years ago
- Related to Task #2312: Avoid serving web content over http:// when possible added
Updated by Guilhem Moulin over 6 years ago
- Category set to Mirrors
This was brought up at today's infra call: https://listarchives.libreoffice.org/global/website/msg14937.html
Adding a redirect http://download.documentfoundation.org to https://download.documentfoundation.org doesn't really help as long as we have http://-only mirrors, since users could be further redirected to an http:// mirror. Moreover it could be harmful if browsers decide to block such downgrade redirects.
Currently mirrorbrain can't redirect to https:// mirrors when it's accessible via https://, cf. https://github.com/poeml/mirrorbrain/issues/143 . However we can reach out to mirror operators and ask them to support https:// (need to patch `/usr/share/pyshared/mb/util.py` though, cf. https://github.com/poeml/mirrorbrain/issues/167), for instance by giving a link to the Let's Encrypt tutorials.
We currently have 113 enabled HTTP mirrors, of which 6 have an https:// baseURL. However the following scan shows that one third (34) of the http:// baseURLs can already be upgraded to https://.
echo "SELECT baseurl, admin_email FROM server WHERE enabled = 't' AND baseurl LIKE 'http://%'" \
| sudo -u postgres psql -tAF' ' mirrorbrain \
| while read baseurl email; do curl -m5 -fso/dev/null "https://${baseurl#http://}" && echo "$baseurl $email"; done(Interestingly, https://tdf.ip-connect.vn.ua works on v6 but not on v4…) I just reached out to these 34 operators (modulo two bounces) and asked them if we could upgrade their baseurl to https:// in our database. Once we have enough https://-capable mirrors, the plan is to disable the few remaining http://-only ones.
Updated by Guilhem Moulin over 6 years ago
- Status changed from New to In Progress
Updated by Florian Effenberger about 6 years ago
- Target version set to Q2/2018
Any updated numbers, what's the progress? ;-)
Updated by Tom Delmas about 6 years ago
- Priority changed from Normal to Urgent
- Tags Documentation added
Changed the priority from Normal to Urgent, because bad actors are actively using that security hole to infect peoples:
https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/
Updated by Guilhem Moulin about 6 years ago
Florian Effenberger wrote:
Any updated numbers, what's the progress? ;-)
36 mirrors with an https:// baseurl, 81 with an http:// one. Of these 81 http:// urls, 10 also support https:// with a X.509 cert issued by a “trusted” CA. Only one wasn't contacted already (will do); I did ask the other 9 if we could upgrade the baseurl to http://, but didn't get an answer yet.
Updated by Guilhem Moulin about 6 years ago
- Priority changed from Urgent to Normal
Tom Delmas wrote:
Changed the priority from Normal to Urgent, because bad actors are actively using that security hole to infect peoples:
https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlogic-devices-deploy-government-spyware-turkey-syria/
While I do agree using that using https:// between the user's browser and the mirror they are trying to download from is strictly better than using http://, I fail to see how that protects users from that type of attack. The default mirror is always chosen based on the client IP and the BGP routing agreements between their ISP and the mirrors'. We are regularly scanning each mirror but usually not from the IPs for which it's the default one, hence a compromised mirror, or one in bad hands, would likely be able to do a lot of harm before it's detected. Whether they serve content over HTTP or HTTPS, users need to rely on the the good faith of our (volunteer) network operators, unless they (or their system) verify integrity of what they are downloading.
It's (unfortunately) true that we can't expect users to check OpenPGP signatures or checksums (or X.509 chains). While I would welcome having only https:// mirrors, it doesn't seem to be doable at this point with only 30% of http://-capable mirrors: if we were to kick http:// mirrors from the network, people who would suffer the most are those located in places with poor connections to Europe and North America.
FWIW, https://libreoffice.org/download links to https://download.documentfoundation.org/….torrent files, which we're serving ourselves (ie not relying on the mirror network) and which contain a cryptographic digest (currently SHA-256) of the .msi/.tar/… file. As far as I can see that protects against the class of attack you mentioned; although our infrastructure, and the X.509 chain are still single point of failure in that model.
The better fix, as you hinted at in your report, would be to have LibreOffice upgrade itself on platform where user's don't rely on their distro (and the package maintainers) to verify cryptographic integrity of the software. The first download might be at risk (just like the initial install of a distro) but LO would then check signatures on the updates. That's being worked on, cf.
https://bugs.documentfoundation.org/show_bug.cgi?id=68274
https://mmohrhard.wordpress.com/2017/08/22/announcing-automatically-updating-daily-windows-libreoffice-builds/(and also moggi's talk at FOSDEM 2018) but that's not a project driven by the infra team. I'm lowering the priority of this issue back to normal because 1/ the .torrent links are already there and seem to solve your concern, and 2/ we can't force mirror operators to add HTTPS support, and 3/ the protection offered by HTTPS mirrors is marginal thus it's not worth spending all time and energy of the infra team on this. Would be nice to only have https:// mirrors, but getting there is not that urgent, IMHO.
Updated by Tom Delmas about 6 years ago
While I do agree using that using https:// between the user's browser and the mirror they are trying to download from is strictly better than using http://, I fail to see how that protects users from that type of attack. The default mirror is always chosen based on the client IP and the BGP routing agreements between their ISP and the mirrors'. We are regularly scanning each mirror but usually not from the IPs for which it's the default one, hence a compromised mirror, or one in bad hands, would likely be able to do a lot of harm before it's detected. Whether they serve content over HTTP or HTTPS, users need to rely on the the good faith of our (volunteer) network operators, unless they (or their system) verify integrity of what they are downloading.
That attack rely on a MitM, not on rogue mirror, so having https on
the download page and https for the mirror do fully protect against
that attack.
Having another way of downloading it doesn't protect users unless you
display a very explicit messages indicating that the standard download
button is not secure an may lead to a system compromised.
I know that you can't force mirrors to switch to https but you can
decide to only use https ones. As the thread is real, I strongly
suggest you do it quickly.
As for the threat of rogue (or infected) mirrors, there is no solution
today, but one is coming:
https://github.com/w3c/webappsec-subresource-integrity/issues/68
I'm lowering the priority of this issue back to normal because 1/ the .torrent links are already there and seem to solve your concern, and 2/ we can't force mirror operators to add HTTPS support, and 3/ the protection offered by HTTPS mirrors is marginal thus it's not worth spending all time and energy of the infra team on this. Would be nice to only have https:// mirrors, but getting there is not that urgent, IMHO.
The only reason that this attack was successful is because of projects
such as this one, who doesn't use https for downloads. So I strongly
disagree about the "it's not that urgent".
Please, protect your users.
On Thu, Mar 15, 2018 at 8:15 PM, The Document Foundation Redmine
<generic@redmine.documentfoundation.org> wrote:
Updated by Guilhem Moulin about 6 years ago
Tom Delmas wrote:
While I do agree using that using https:// between the user's browser and the mirror they are trying to download from is strictly better than using http://, I fail to see how that protects users from that type of attack. The default mirror is always chosen based on the client IP and the BGP routing agreements between their ISP and the mirrors'. We are regularly scanning each mirror but usually not from the IPs for which it's the default one, hence a compromised mirror, or one in bad hands, would likely be able to do a lot of harm before it's detected. Whether they serve content over HTTP or HTTPS, users need to rely on the the good faith of our (volunteer) network operators, unless they (or their system) verify integrity of what they are downloading.
That attack rely on a MitM, not on rogue mirror, so having https on
the download page and https for the mirror do fully protect against
that attack.
My point is that users are redirected to the mirror with the best connection, which is also often the closest geographically. If there is reason to worry about MiTM between the browser and the mirror, I don't see why one shouldn't worry about MiTM between the mirror and TDF, especially if the mirror and browser are in the same network and/or jurisdiction. And TDF ↔ mirrors links are cleartext rsync://. That's why I said https:// mirrors offer only “marginal protection”. Rebuilding the whole mirror network from scratch without the legacy stuff accumulated along the years is not an easy task, and at that point the auto-updater seems like the way to go. Plus it offers end-to-end cryptographic verification and drops two points of failure (TDF infra and the mirror incl. their X.509 chain), just like manually checking the .asc files.
I know that you can't force mirrors to switch to https but you can
decide to only use https ones. As the thread is real, I strongly
suggest you do it quickly.
Only 30% of our mirrors support https:// officially (+8% unofficially), the majority in western Europe. Kicking European http:// mirrors off the network might not hurt users much, but doing the same for say the Oceanian ones definitely would (there are no https:// mirrors is this area, and they have quite poor connection to other mirrors).
Updated by Tom Delmas about 6 years ago
Guilhem Moulin wrote:
My point is that users are redirected to the mirror with the best connection, which is also often the closest geographically. If there is reason to worry about MiTM between the browser and the mirror, I don't see why one shouldn't worry about MiTM between the mirror and TDF, especially if the mirror and browser are in the same network and/or jurisdiction. And TDF ↔ mirrors links are cleartext rsync://. That's why I said https:// mirrors offer only “marginal protection”.
Now I understand why you say “marginal protection”.
After TDF rsync the new version, it could check the download, so it could detect a MitM, no?
Rebuilding the whole mirror network from scratch without the legacy stuff accumulated along the years is not an easy task, and at that point the auto-updater seems like the way to go. Plus it offers end-to-end cryptographic verification and drops two points of failure (TDF infra and the mirror incl. their X.509 chain), just like manually checking the .asc files.
Auto-updater with cryptographic verification is a good direction. But it doesn't solve the first download.
Only 30% of our mirrors support https:// officially (+8% unofficially), the majority in western Europe. Kicking European http:// mirrors off the network might not hurt users much, but doing the same for say the Oceanian ones definitely would (there are no https:// mirrors is this area, and they have quite poor connection to other mirrors).
If there is no secure mirror available, as I said before, the minimum is to clearly warn the user that the connection is insecure and strongly advise to check the checksum and/or show an alternate link to a secure but slower mirror.
Updated by Florian Effenberger almost 5 years ago
- Assignee deleted (
Guilhem Moulin) - Target version deleted (
Q2/2018)
Seems the initial request has been dealt with or is obsolete, so putting the ticket to the general public - nothing immediate to be done by infra, I assume