This is a really good report of a generally poor situation.
I'm worried that when Chrome 62 gets out, all the companies that have dragged their heels will suddenly switch into crisis mode when their executives start seeing the "insecure" labels popping up on their browser. Then hurried teams will start breaking things, as you saw with Sierra/WebPAC.
One extra tool to suggest in your enhancement requests is HSTS. providers that implement this save you the trouble of updating all the links in your systems (though you want to do that too, sooner or later).
On the bright side, many of the the folks who have been working on the switch - that's most of the big guys- have been working slowly and will soon have a strong incentive to focus on finishing their work. I expect we'll see a lot of movement in the next two months.
Would it be useful to organize some of the information that Matthew has presented here into a wiki, perhaps on code4lib.org so we can keep track of changes over the next few months?
Google's Emiliy Schechter gives an excellent presentation on the transition to HTTPS, and how the Chrome UI is gradually changing to more accurately communicate to users that non-HTTPS sites may present risks: https://www.youtube.com/watch?v=GoXgl9r0Kjk&feature=youtu.be <https://www.youtube.com/watch?v=GoXgl9r0Kjk&feature=youtu.be>
(discussion of Chrome 62 changes starts around 32:00)
President, Free Ebook Foundation
Founder, Unglue.it https://unglue.it/
> On Aug 30, 2017, at 11:21 AM, Matthew Reidsma <[log in to unmask]> wrote:
> At Grand Valley, we’ve been focusing on the non-database/journal systems, since it’s easier to control those than anything else. (You can read about my initial foray into getting just a small section of our subscription databases to wotj with HTTPS here: https://matthew.reidsrow.com/worknotes/177 ) Our own servers have been forcing HTTPS for over a year, so that helped us a little bit. But most of our tools are hosted by vendors, so we did an audit this month to determine what was working and what we needed help with. The good news was that pretty much all of our systems already support HTTPS, but some do not *force* HTTPS connections. We’ve already worked to address this by making sure all our links to systems on our website, LibGuides, forms, etc. go to HTTPS, and changing settings in our discovery systems and other places to send folks via HTTPS to our link resolver and catalog.
> Here is the list of patron-facing systems I compiled and the current status of HTTPS support, and where we’re at. I hope it’s helpful to anyone else trying to come to terms with this change:
> • bepress Digital Commons: they announced vague support for HTTPS connections earlier this year, but have offered no details and told us last week that no progress has been made. (No doubt they have been busy rolling around in the pile of dirty money from Elsevier.) The big question we have is that we have a CNAME for our instance, which would require a root-level wildcard or a specific certificate for the subdomain. Our institution won’t let us use the root-level wildcard (*.gvsu.edu) on a hosted server, so we’ll have to buy a certificate for this. I asked for details on a CSR and they were like, “What? We’re not there yet.”
> • Our campus CMS already forces HTTPS.
> • LibGuides: now supports custom domains and certificates through a slick GUI admin console in LibApps. We’re purchasing a certificate for this, since it has a URL structure that doesn’t match our current wildcard certificate.
> • LibChat, LibCal, LibAnswers: GUI certificate support is coming in a few weeks. We’ll add our wildcard (*.library.gvsu.edu) to these once we can.
> • Ares (Course Reserves) and Illiad (ILL): both hosted instances already force HTTPS on all connections.
> • ArchivesSpace – hosted now supports HTTPS (it uses the *.lyrasistechnology.org URL, so we don’t need a certificate.) I don’t think it forces HTTPS, though, so we currently direct folks there over HTTPS and will be looking at how the new OAI-PMH feed emphasizes HTTPS and checking our MARC records for support. In addition, we’ll ask for an option to force HTTPS connections on all visits.
> • Omeka – This is hosted on our servers, so it already supports HTTPS and forces HTTPS connections.
> • 360 Link link resolver: supports HTTPS, and we direct *a lot* of our traffic there, but not everything. For instance, today I realized that GOBI links were still using http. I’ve put in a feature request on the Ex Libris idea exchange to give an option to force HTTPS connections if you want to vote it up. (It already has almost 50 votes and I added it late last week.) http://ideas.exlibrisgroup.com/forums/564566-summon/suggestions/31025644-add-option-to-force-360-link-to-load-over-https (I got the impression that this feature is already scheduled for a December release, since they are adding it to EJP 2.0, but don’t quote me on that.)
> • EJP 2.0 (eJournal Portal from ProQuest/Ex Libris): Was told an option to force HTTPS is coming in the December release. There are still a few issues even if you route folks there over HTTPS, which I have tickets in on:
> o Syndetics book covers still use HTTP, even when the rest of the site loads with HTTPS. This is on the same ticket above. They’re waiting to hear from the Development team about fixing this. I recommended always using HTTPS, but at least making the images load relative to the selected protocol.
> • Summon: We currently direct all our forms, links, etc. that we can control over HTTPS. I submitted a feature request to add an option to force HTTPS connections. It’s here: http://ideas.exlibrisgroup.com/forums/564566-summon/suggestions/31025608-add-the-option-to-force-summon-to-load-over-https
> o At 6:00am on SATURDAY, they put in a temporary HTTPS redirect on the apache server (it lives on campus, but they manage it.) They didn’t ask us if we wanted to try this, they just did it ON A SATURDAY MORNING 2 days before classes started.
> o All our clients went down
> o We lost connection to our INNREACH consortial catalogs
> o Still only about half the pages were getting redirected to HTTPS
> o They reversed the change, and then bizarrely closed the ticket. I’m still so mad about this weekend I haven’t written them back to reopen it because I’m afraid of what they will do!!
> There are still no doubt tons of places where we’re missing updating URLs for tools with https, like all the databases where we have our link resolver information stored (we have 300 databases, so it will take a while to update those.) But by hitting the main preferences in our most popular tools to link to HTTPS versions of other tools, updating our HTML forms to direct to HTTPS versions, and doing a find/replace in LibGuides to make sure all the URLs to the catalog and Summon were going to https, we do get most of the traffic. Hopefully with enough pressure from all of us, the vendors will get this sorted out on their end (although I don’t have much hope for III).
> So far the only vendor to address this openly has been Springshare: http://blog.springshare.com/2017/08/24/https-a-palooza-and-what-are-we-doing-about-it/
> I’d love to hear what others are doing, too.
> Matthew Reidsma
> Web Services Librarian, GVSU.edu/library
> Editor-in-Chief, WeaveUX.org
> Report a problem with a GVSU Library system at https://prod.library.gvsu.edu/status/?problem
> PGP: 25AA 0DE3 B9E9 658F 04A2 EEF0 0DEF 555D F8BD 785B
> On 8/30/17, 10:44 AM, "Code for Libraries on behalf of Benjamin Florin" <[log in to unmask] on behalf of [log in to unmask]> wrote:
> How is everyone handling the switch to HTTPS-everywhere-all-the-time next
> In October Chrome v62 will start marking all pages served over HTTP with
> text input elements as insecure (
> Almost every page we serve or link to has a search box on it, so most
> libraries will effectively have to go HTTPS-only.
> Switching sites on our own domain to HTTPS-only will be easy, but requiring
> HTTPS from the databases, journals, repositories, etc that we link to is
> How is everyone else dealing with this? Do you have a sense of the scope of
> the problem? Are you already HTTPS-only?