[Koha-bugs] [Bug 25965] Create SIP2 client daemon with HTTPS API endpoint

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25965

--- Comment #36 from David Cook <dcook at prosentient.com.au> ---
(In reply to Lari Strand from comment #33)
> I haven't worked with the stunnels myself on our systems or even asked one
> to be set up, but as far as I understand it needs work from both our
> server's host/provider's support personnel (which is not us) + the
> municipalities' IT personnel for each library and they have to work together
> to set up a tunnel. We can only ask them to enable an stunnel to be set up
> between a self check machine's network and out server host. So it's out of
> our hands how they manage to set them up and in what time (+upkeep). So
> naturally we wanted to get rid of all that hassle.

If you don't have server access, then you will need a sysadmin with server
access to setup the stunnel on the server, yes.

However, it's very easy. It's a few lines of configuration that you do 1 time.
You only need to update the SSL certificate like you'd need to do with any
SSL-based service (like a HTTPS listener on a web server).

As for the client side, yes that would be up to whoever is setting up the
devices. It depends on their infrastructure. They could have 1 stunnel proxy on
their local network which every self-check device connects to, which then
proxies the connection (over SSL) to your server's stunnel. 

The client and server ends can be set up independently of each other, and then
at the end an integration test can be done to make sure the client can talk to
the server. It's pretty easy.

> I haven't looked at SIP over TLS so I have no experience of that. Does
> Koha's SIP server support it natively?

No, that's what I was saying before. Koha's SIP server does *not* support
SSL/TLS natively, which is why stunnel is needed.

However, Koha's SIP server could be updated fairly easily to support it
natively I think. 

(In reply to Lari Strand from comment #34)
> I googled a bit and seems This TLS thing is something our server service
> provider support personnel would have to set up with the self check
> machines' support people? Maybe too many extra steps for us compared to just
> pointing the self check machines etc. to a Koha SIPoHTTPS endpoint. Not sure
> though...

As I noted above, the client and server are separate. Your server service
provider would set up the stunnel service on the server. This is like any
server software. You can test it independently on your own. 

After the server is setup, the self check machines' support people would need
to test to make sure they can connect, but that's a fairly normal procedure.

SIPoHTTPS is using TLS too, but you're managing the TLS in the Apache web
server instead of the Stunnel proxy server.

(In reply to Lari Strand from comment #35)
> Seems like a valid alternative approach if the self check machines could
> support/could add support to their software.

So some self check machines have built-in SSL/TLS support. But many don't and
that's why they use a stunnel client to proxy traffic over SSL/TLS. 

But if the self check machines you're talking about are adding SIPoHTTPS
support, then they are adding SSL/TLS support... just via a HTTP client rather
than a SIP client. So they're already doing the work...

But HTTP is a lot more well understood of an application layer protocol than
SIP.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are watching all bug changes.