Forcing HTTPS breaks some functionality in staff client

Bug #1507013 reported by Jeff Davis on 2015-10-16
262
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned

Bug Description

Evergreen 2.8.1
OpenSRF 2.4

During our last upgrade, we tried forcing HTTPS on all connections, OPAC and XUL client alike. We implemented this with a 307 redirect at the load balancer level. For the most part it worked. However, we had to add exceptions in two cases:

1. path /cgi-bin/offline/offline.pl - if you force HTTPS, uploading offline circ transactions will fail
2. paths beginning /opac/extras/sru - YAZ simple2zoom apparently cannot handle HTTPS, and also can't handle 307 redirects

We want HTTPS to work in these places, and anywhere else where it currently breaks things (a list of other issues like this would be useful). I'm creating this ticket primarily to share our experiences; I don't have a fix in mind.

Galen Charlton (gmc) on 2015-10-16
information type: Private Security → Public Security
Mike Rylander (mrylander) wrote :

These both look to fail because a 307 won't pass POST parameters (or, more accurately, will only pass GET parameters, if parameters there be).

IMO, the SRU part is pretty easily solved. All practical use of that URL is over localhost, so with a localhost non-SSL exception MITM is mitigated at the http level. Z39.50 itself does not have TLS support, so not much we can do there but suggest folks use stunnel if they want encrypted Z...

For offline.pl, things are more tricky. We may not be able to force SSL there until the web client (or at least a major version release).

Galen Charlton (gmc) wrote :

> For offline.pl, things are more tricky. We may not be able to force SSL
> there until the web client (or at least a major version release).

A major version release (or even a minor one with a new XUL client) should suffice here, since all that's needed in this case is having the staff client request HTTPS in the first place.

Galen Charlton (gmc) wrote :

> IMO, the SRU part is pretty easily solved. All practical use of that URL
> is over localhost, so with a localhost non-SSL exception MITM is mitigated
> at the http level.

Agreed, although it looks like it wouldn't be hard to get simple2zoom to use HTTPS, and that would be worth contributing back to IndexData.

> Z39.50 itself does not have TLS support, so not much we can do
> there but suggest folks use stunnel if they want encrypted Z...

Interestingly, ZOOM supports this!

Mike Rylander (mrylander) wrote :

Re offline.pl, you're correct. However, we should allow offline.pl to be accessed without SSL until a major release, and then add the apache config changes to the upgrade instructions. Individual sites that choose to upgrade their staff client at minor release boundaries can, of course, gain the benefit and choose to apply the apache config changes.

The reason for the delay in forcing SSL until the next major release is long-standing position that any X.Y staff client should be able to use any X.Y server. We could force the issue, but I (personally) don't see MITM against offline transaction upload as an attack surface worth breaking that rule for.

Thoughts?

As for ZOOM, that's great news! Are there clients other than yaz-client that support TLS or SSL? If essentially all do, we could certainly document how to set that up so sites can give out secure URLs. I've no actual opinion on whether it's worth the effort to secure localhost connections weighed against the (however slight) increased CPU time and latency that would bring, so I'll leave it to those with tuits to judge. ;)

Thanks for the info, Galen!

A man in the middle attack against offline transactions seems pretty
unlikely to me as well

On Tue, Oct 20, 2015 at 1:01 PM, Mike Rylander <email address hidden> wrote:

> Re offline.pl, you're correct. However, we should allow offline.pl to
> be accessed without SSL until a major release, and then add the apache
> config changes to the upgrade instructions. Individual sites that
> choose to upgrade their staff client at minor release boundaries can, of
> course, gain the benefit and choose to apply the apache config changes.
>
> The reason for the delay in forcing SSL until the next major release is
> long-standing position that any X.Y staff client should be able to use
> any X.Y server. We could force the issue, but I (personally) don't see
> MITM against offline transaction upload as an attack surface worth
> breaking that rule for.
>
> Thoughts?
>
> As for ZOOM, that's great news! Are there clients other than yaz-client
> that support TLS or SSL? If essentially all do, we could certainly
> document how to set that up so sites can give out secure URLs. I've no
> actual opinion on whether it's worth the effort to secure localhost
> connections weighed against the (however slight) increased CPU time and
> latency that would bring, so I'll leave it to those with tuits to judge.
> ;)
>
> Thanks for the info, Galen!
>
> --
> You received this bug notification because you are subscribed to
> Evergreen.
> Matching subscriptions: evergreenbugs
> https://bugs.launchpad.net/bugs/1507013
>
> Title:
> Forcing HTTPS breaks some functionality in staff client
>
> Status in Evergreen:
> New
>
> Bug description:
> Evergreen 2.8.1
> OpenSRF 2.4
>
> During our last upgrade, we tried forcing HTTPS on all connections,
> OPAC and XUL client alike. We implemented this with a 307 redirect at
> the load balancer level. For the most part it worked. However, we had
> to add exceptions in two cases:
>
> 1. path /cgi-bin/offline/offline.pl - if you force HTTPS, uploading
> offline circ transactions will fail
> 2. paths beginning /opac/extras/sru - YAZ simple2zoom apparently cannot
> handle HTTPS, and also can't handle 307 redirects
>
> We want HTTPS to work in these places, and anywhere else where it
> currently breaks things (a list of other issues like this would be
> useful). I'm creating this ticket primarily to share our experiences;
> I don't have a fix in mind.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1507013/+subscriptions
>

Galen Charlton (gmc) wrote :

> Re offline.pl, you're correct. However, we should allow offline.pl to
> be accessed without SSL until a major release, and then add the apache
> config changes to the upgrade instructions. Individual sites that
> choose to upgrade their staff client at minor release boundaries can, of
> course, gain the benefit and choose to apply the apache config changes.
>
> The reason for the delay in forcing SSL until the next major release is
> long-standing position that any X.Y staff client should be able to use
> any X.Y server. We could force the issue, but I (personally) don't see
> MITM against offline transaction upload as an attack surface worth
> breaking that rule for.

But note that offline transaction management also includes patron
registration, so using that part of it means uploading directly
personally identifying information in the clear (unlike offline
checkouts and checkins, where only opaque (or so one would hope)
patron barcodes are transmitted).

Galen Charlton (gmc) wrote :

Re TLS and Z39.50: https://galencharlton.com/blog/2015/10/securing-z39-50-traffic-from-koha-and-evergreen-z39-50-servers-using-yaz-and-tls/

Of course, not every client will support this, but it will be easy to update the example config to show this as an option.

Dan Scott (denials) wrote :

Anecdata: just noting that our install of EG 2.12.5 on Ubuntu 16.04 seems to be working fine for us when relying on the indexdata yaz pacakges with our oils_z3950.xml stanzas connecting to HTTPS for SRU; it contains (for example):

   <database name="LUSYS">
     <zurl>https://www.concat.ca/opac/extras/sru/LUSYS/holdings</zurl>
     <option name="sru">get</option>
     <charset>UTF-8</charset>
     <search>
       <querytype>cql</querytype>
       <map use="4"><index>eg.title</index></map>
       <map use="7"><index>eg.isbn</index></map>
       <map use="8"><index>eg.issn</index></map>
       <map use="12"><index>eg.id</index></map>
       <map use="21"><index>eg.subject</index></map>
       <map use="1003"><index>eg.creator</index></map>
       <map use="1018"><index>eg.publisher</index></map>
       <map use="1035"><index>eg.keyword</index></map>
       <map use="1016"><index>eg.keyword</index></map>
     </search>
   </database>

# dpkg -s yaz
Package: yaz
Architecture: amd64
Version: 5.23.0-1.indexdata

Bill Erickson (berick) wrote :

Here's a branch to force HTTPS in XUL url_prefix(), which allows offline transactions to complete when the server only supports HTTPS. Not entirely sure this is the best solution, but appears to work.

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/lp1507013-xul-offline-https

Jason Stephenson (jstephenson) wrote :

I'm setting status to Won't Fix because AFAICT this bug only affects the XUL client.

Changed in evergreen:
status: New → Won't Fix
To post a comment you must log in.
This report contains Public Security information  Edit
Everyone can see this security related information.

Other bug subscribers