Task #2312
closedAvoid serving web content over http:// when possible
0%
Description
Ideally all http:// requests would be permanently redirected to their https:// counterpart. It's mostly the case already (using X.509 certs from Let's Encrypt), but the TDF and LO websites are still serving pages over http://. (There is an HTTPS Everywhere rule for both, but we still want 301 redirects on our HTTPd.)
Moreover we should track down pages that are still referencing http:// URIs (for instance the imprint or the logo, respectively with an <a> and <img> tag) and upgrade them to https://.
- hub.libreoffice.org, tdf.io, etc.: avoid the double redirect http://tdf.io/infra → https://tdf.io/infra → …
- dev-www and other dev tools: scripts don't always follow redirects (eg,
curlwithout-Lflag) so we need to be careful not to break things. - mirrorbrain: currently clients might be sent to http:// mirrors when visiting https://download.libreoffice.org (and vice versa); until all mirrors are HTTPS-cabable we probably want to keep serving http:// pages, but ideally https:// should be sent to https:// mirrors (assuming we have enough of them).
Related issues
Updated by Guilhem Moulin over 6 years ago
- Related to Task #2340: LibreOffice download page - please change torrent file to be downloaded using https instead of current http link added
Updated by Olivier Hallot over 6 years ago
Hi
I grep'ed the source code sfx2 module and FWIW, here is the result WRT to hub.libreoffice.org. I think nothing is to change
tdf@olivier-ntbk:~/git/core/sfx2/source$ git grep hub
appl/appserv.cxx: OUString sURL("https://hub.libreoffice.org/send-feedback/?LOversion=" + utl::ConfigManager::getAboutBoxProductVersion() +
appl/appserv.cxx: OUString sURL("https://hub.libreoffice.org/forum/?LOlang=" + aLang);
appl/appserv.cxx: OUString sURL("https://hub.libreoffice.org/documentation/?LOlocale=" + utl::ConfigManager::getLocale());
appl/appserv.cxx: OUString sURL("https://hub.libreoffice.org/donation/?BCP47=" + aBcp47 + "&LOlang=" + aLang );
Updated by Krasnaya Ploshchad’ over 6 years ago
To avoid this, I have installed Smart HTTPS add-on in my browser, then I enabled “Add Upgrade-Insecure-Requests header to ALL websites with HTTPS protocol” option. All requests would be forced using HTTPS firstly.
https://mybrowseraddon.com/smart-https.html
Updated by Florian Effenberger over 6 years ago
- Target version changed from Q3/2017 to Q4/2017
Given the other pending tasks for Q3 (e.g. further SSO deployments), and that this is a longer tasks, shifting to Q4
Olivier, if there are pages that are important for you specifically wrt. SEO, please let us know, and Guilhem can look if those can be prioritized
Updated by Krasnaya Ploshchad’ over 6 years ago
Maybe we can also making certain links hardcoded in this way:
<a href="//example.com#contents">see contents</a>
Updated by Guilhem Moulin over 6 years ago
- Related to Task #1987: Please use HTTPS for downloads to protect users added
Updated by Guilhem Moulin about 6 years ago
All URLs on the main sites (LO's and TDF's), as well as on the NL template, should have been upgraded to https://, with the exception of those to http://download.documentfoundation.org. The NL sites weren't touched yet.
As for download.documentfoundation.org, we want to leave the mirrors alone for now but upgrade URLs to small files (.mirrorlist/.info/.torrent, which we serve ourselves). The SS3 template is using a single variable with the URI path, but in principle we could use "//download.documentfoundation.org" and prepend "http:" to the "normal" download URL (so all other URLs will preserve the scheme, namely https://). Not sure what the side-effects of doing that could, so I need to sync with cloph first.
Updated by Florian Effenberger about 6 years ago
- Target version changed from Q4/2017 to Q2/2018
All URLs on the main sites (LO's and TDF's), as well as on the NL template, should have been upgraded to https://, with the exception of those to http://download.documentfoundation.org. The NL sites weren't touched yet.
How much work would the NL sites entail?
Can we send out a notice we will do this via a script in xyz days, and people should check the pages afterwards?
HTTPS also helps our SEO efforts...
As for download.documentfoundation.org, we want to leave the mirrors alone for now but upgrade URLs to small files (.mirrorlist/.info/.torrent, which we serve ourselves). The SS3 template is using a single variable with the URI path, but in principle we could use "//download.documentfoundation.org" and prepend "http:" to the "normal" download URL (so all other URLs will preserve the scheme, namely https://). Not sure what the side-effects of doing that could, so I need to sync with cloph first.
Any outcome of this already?
Updated by Guilhem Moulin about 6 years ago
Florian Effenberger wrote:
All URLs on the main sites (LO's and TDF's), as well as on the NL template, should have been upgraded to https://, with the exception of those to http://download.documentfoundation.org. The NL sites weren't touched yet.
How much work would the NL sites entail?
Can we send out a notice we will do this via a script in xyz days, and people should check the pages afterwards?
HTTPS also helps our SEO efforts...
Would certainly be easier if we had a robot do the mass edit. No idea how to do that though, and I didn't find hints online at the time, so I wrote a small webcrawler to detect upgradable http:// links, and edited by hand… took a full night, so I stopped after the non-localized sites and the NL template. Not trilled to do that again on the localized sites I must say, and I fully understand if translators feel the same way. I'd gladly learn how to perform mass edition if that's possible.
As for download.documentfoundation.org, we want to leave the mirrors alone for now but upgrade URLs to small files (.mirrorlist/.info/.torrent, which we serve ourselves). The SS3 template is using a single variable with the URI path, but in principle we could use "//download.documentfoundation.org" and prepend "http:" to the "normal" download URL (so all other URLs will preserve the scheme, namely https://). Not sure what the side-effects of doing that could, so I need to sync with cloph first.
Any outcome of this already?
It was #2312, which is now closed.
Updated by Florian Effenberger about 6 years ago
Would certainly be easier if we had a robot do the mass edit. No idea
Would that be possible via SQL statements? I think Cloph mentioned
something like that.
It was #2312 <https://redmine.documentfoundation.org/issues/2312>, which
is now closed.
This ticket is 2312? ;-)
Updated by Guilhem Moulin about 6 years ago
Florian Effenberger wrote:
Would certainly be easier if we had a robot do the mass edit. No idea
Would that be possible via SQL statements? I think Cloph mentioned
something like that.
Possibly, I need to check if the table has rows with the full pages, or if it's just the diff. In the latter case the risk of database surgery causing corruption is much higher…
It was #2312 <https://redmine.documentfoundation.org/issues/2312>, which
is now closed.This ticket is 2312? ;-)
Meant https://redmine.documentfoundation.org/issues/2340, sorry :-P
Updated by Florian Effenberger almost 6 years ago
Was there any progress recently, can you give a quick status update? ;-)
Updated by Guilhem Moulin almost 6 years ago
We have 301 redirections to https:// everywhere except for the hub and the URL shortener (pointless to have double redirects) and the mirrorbrain instances. So technically this ticket can be closed.
On the other hand we still have hard-coded http:// links in various places, for instance on Silverstripe (NL sites) and on the wiki. Perhaps we should file other tickets for that.
Updated by Florian Effenberger almost 6 years ago
On the other hand we still have hard-coded http:// links
<http://%20links> in various places, for instance on Silverstripe (NL
sites) and on the wiki. Perhaps we should file other tickets for that.
Can you send a list where we still have those links, so we can
distribute the task amongst the team to fix these?
Updated by Florian Effenberger over 5 years ago
Can you send a list where we still have those links, so we can
distribute the task amongst the team to fix these?
Any updates?
Updated by Florian Effenberger almost 5 years ago
- Target version changed from Q2/2018 to Q2/2019
Any updates on this topic?
Updated by Florian Effenberger over 4 years ago
- Target version changed from Q2/2019 to Q3/2019
Florian Effenberger wrote:
Any updates on this topic?
Any updates? Can this be closed, is this still pending? I don't think we have that many HTTP-only links?
Updated by Guilhem Moulin over 4 years ago
- Status changed from New to Closed
Closing. We've chased http:// links out there and upgraded them by the ton. I guess there are still a handful of HTTP links left out there, and we'll keep upgrading them should anyone report them. Having HSTS deployed on the target vhost (#1086) also reduces a lot chances of cleartext/MiTM'able redirects.