Hi Gagandeep et al,

I am working on setting this up as part of my integration right now. We are
moving from Sierra, which uses a non-encrypted SIP connection, to Alma,
which is encrypted using Stunnel. The SIP protocol is not secure at all.
It's a known shortcoming. The options, as far as I can tell, are to just
live with unencrypted data, to use a VPN between your self-check station
and the ILS/LSP, or to use something like Stunnel to encrypt your message
on the self-check machine and then decrypt it on the ILS/LSP server. The
choice is based entirely on how your ILS/LSP vendor handles it. If they
don't have a method for handling Stunnel-encrypted SIP messages, there's
nothing you can do about it (except complain I guess).

In Alma, the LSP assigns us a random SSL certificate that contains a public
key for encrypting the data. On the backend somewhere, they have a matching
private key that knows how to decrypt that data into a plain SIP message.
Stunnel intercepts the data before it leaves your self-check station and
encrypts it into a meaningless blob of text. The vendor has set up a
process on their server to decrypt the data before trying to process it as
a SIP message.

Joshua Welker
Library Systems and Discovery Coordinator
James C. Kirkpatrick Library
University of Central Missouri
Warrensburg, MO 64093
JCKL 2260
660.543.8022



On Mon, Apr 29, 2019 at 3:30 PM Gagandeep Dhillon, Mr. <
[log in to unmask]> wrote:

> Hi folks,
>
>
>
> We are stepping through configuring secure transmission between our
> Bibliotheca self-check machines and our new LSP, OCLC's WorldShare, using
> stunnel. We are in the process of migrating from Aleph (an Ex Libris
> product) to WorldShare and, in the past, have set up our Bibliotheca
> self-checks with Aleph using stunnel and an SSL certificate provided by Ex
> Libris. This is not something that OCLC does, or has apparently needed to
> do with other libraries. On their end they authenticate whether our machine
> is our machine based on its IP address but beyond that data transmission is
> insecure.
>
>
>
> Most of us working on this are new to SSL certificates, stunnel, and
> securing transmission between our self-checks and a vendor system hosted on
> a server that we don't have control over. Has anyone had experience doing
> something similar to this? If so, could we pick your brain?
>
>
>
> On a related, but broader, note: what is the origin of SSL certificates?
> Where did this come from and why wouldn't it be a standard thing a vendor
> supports?
>
> Please feel free to contact any of us.
>
> Thanks,
>
> Clara Turp
> Eka Grguric
> Awais Mehmood Khalid
> Mutugi Gathuri
>
> ---
> Gagandeep Dhillon
> Team Leader, Application Development | Digital Initiatives | McGill
> University Library
> P:514-398-1846 |E:[log in to unmask]
>