The one thing that worries me about https-everywhere-all-the-time is that if you're trying to use public wifi in an airport, or hotel, or similar, the process is generally: try to go to a webpage -> get redirected to wifi login website -> login -> access web to your heart's content. But if the webpage you try to go to in the first step is https then the initial redirect doesn't work and you get thoroughly stuck; instead you have to rack your brain to think of a website still using http. Now I imagine the companies that sell this public wifi set up could actually re-program their system so that it did work with https, I just don't imagine they're going to notice soon, being so removed from the people actually using it.

Anyway, though, our https notes include:

* WordPress has a "Really Simple SSL" plugin that works well for internal links, though I still have to search every now and then in case someone's hot-linked to an image on an external site that's http. (There are other systems I can think of that let users hot-link to external images, and it generally makes things trickier.)

* We've configured EZproxy, OJS, DSpace, and Symplectic Elements to be https-only.

* LibraryH3lp, CareerHub and Alma are https-only

* Primo can be configured to be https-only though we haven't done this yet because last I checked some thumbnails were still being served through http.

* SuperSaaS is http-only, similarly Recollect, so I need to chase the vendor on both of these

Deborah

-----Original Message-----
From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Eric Hellman
Sent: Friday, 1 September 2017 3:10 a.m.
To: [log in to unmask]
Subject: Re: [CODE4LIB] HTTPS requirement in Chrome v.62

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)

Eric Hellman
President, Free Ebook Foundation
Founder, Unglue.it https://unglue.it/
https://go-to-hellman.blogspot.com/
twitter: @gluejar

> 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 If you use the 1.0 form syntax and route to an https connection, you will be redirected to http. You can get around this by using the 2.0 syntax, although that requires JavaScript. They will fix this in the December release. My ticket number is 00462308 if you want to follow up.
> 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/310256
> 08-add-the-option-to-force-summon-to-load-over-https
> • Sierra/WebPAC Pro from III: The OPAC for Sierra currently switches to HTTPS when you log in, but otherwise connections are http. We have our links and forms set to send users over HTTPS, but sometimes they find ways to get there over HTTP so we asked for an option to force HTTPS. Last year I submitted this same feature request, and they told me, no joke, to “do it with JavaScript.” 0_o I submitted another ticket (Case #576013) which had the following effect:
> 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
>    month?
>
>    In October Chrome v62 will start marking all pages served over HTTP with
>    text input elements as insecure (
>    https://blog.chromium.org/2017/04/next-steps-toward-more-connection.html).
>    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
>    tougher.
>
>    How is everyone else dealing with this? Do you have a sense of the scope of
>    the problem? Are you already HTTPS-only?
>
>    Thanks,
>    Ben
>
>


________________________________
P Please consider the environment before you print this email.
"The contents of this e-mail (including any attachments) may be confidential and/or subject to copyright. Any unauthorised use, distribution, or copying of the contents is expressly prohibited. If you have received this e-mail in error, please advise the sender by return e-mail or telephone and then delete this e-mail together with all attachments from your system."