 |
 |
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] >