LISTSERV mailing list manager LISTSERV 16.5

Help for CODE4LIB Archives


CODE4LIB Archives

CODE4LIB Archives


CODE4LIB@LISTS.CLIR.ORG


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

CODE4LIB Home

CODE4LIB Home

CODE4LIB  September 2017

CODE4LIB September 2017

Subject:

Re: HTTPS requirement in Chrome v.62

From:

Kyle Banerjee <[log in to unmask]>

Reply-To:

Code for Libraries <[log in to unmask]>

Date:

Mon, 4 Sep 2017 19:50:37 -0700

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (251 lines)

Currently, pages delivered over https are indicated to be secure, making
all others insecure by extension. The 'switch' simply makes the distinction
more explicit -- and probably won't be noticed by most people.

Most things that really need to be https already are so the biggest
practical effect will be to introduce an array of cert warnings resulting
from setup and maintenance errors which may desensitize people to real
security issues or scare them for no good reason.

As Deborah observes redirect over public wifi introduces issues at
connection time. But that issue has been around for years as most people
first go to social media, search, or email sites which use https. Even if
they need a library site, few people will open the initial window there.

kyle


On Sep 5, 2017 00:31, "Fitchett, Deborah" <[log in to unmask]>
wrote:

> 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/suggesti
> ons/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."
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
August 2011
July 2011
June 2011
May 2011
April 2011
March 2011
February 2011
January 2011
December 2010
November 2010
October 2010
September 2010
August 2010
July 2010
June 2010
May 2010
April 2010
March 2010
February 2010
January 2010
December 2009
November 2009
October 2009
September 2009
August 2009
July 2009
June 2009
May 2009
April 2009
March 2009
February 2009
January 2009
December 2008
November 2008
October 2008
September 2008
August 2008
July 2008
June 2008
May 2008
April 2008
March 2008
February 2008
January 2008
December 2007
November 2007
October 2007
September 2007
August 2007
July 2007
June 2007
May 2007
April 2007
March 2007
February 2007
January 2007
December 2006
November 2006
October 2006
September 2006
August 2006
July 2006
June 2006
May 2006
April 2006
March 2006
February 2006
January 2006
December 2005
November 2005
October 2005
September 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
May 2004
April 2004
March 2004
February 2004
January 2004
December 2003
November 2003

ATOM RSS1 RSS2



LISTS.CLIR.ORG

CataList Email List Search Powered by the LISTSERV Email List Manager