Bug 25972 - SIP2 server doesn't have a TLS/SSL-enabled listener
Summary: SIP2 server doesn't have a TLS/SSL-enabled listener
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: SIP2 (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-07-10 06:21 UTC by David Cook
Modified: 2023-12-28 20:43 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Cook 2020-07-10 06:21:41 UTC
I'm not super familiar with SIP2, but I don't see why we couldn't have a TLS/SSL-enabled listener for the SIP2 server.

Most people use stunnel to secure their SIP2 server, but why not build in TLS/SSL support directly?
Comment 1 Colin Campbell 2020-07-10 13:51:52 UTC
SIP2 predates SSL - In the log in process there is a field to indicate what encryption is used but no specified values. To my knowledge no supplier of SIP devices is currently offering SSL at the client end. 
The Net::Server module used to handle the comms end does have SSL support so it  should be possible to do this without too much effort.
Comment 2 David Cook 2020-07-16 03:39:39 UTC
(In reply to Colin Campbell from comment #1)
> SIP2 predates SSL - In the log in process there is a field to indicate what
> encryption is used but no specified values. To my knowledge no supplier of
> SIP devices is currently offering SSL at the client end. 

I was wondering about that. Something on the client end must be negotiating the SSL connection to stunnel though. Or are SIP devices connecting to a proxy server on the LAN and then that proxy server securely connects to the Koha server running stunnel?

> The Net::Server module used to handle the comms end does have SSL support so
> it  should be possible to do this without too much effort.

That was my observation as well.

The main reason I thought about this was because the amount of work that Bug 25965 would take and how surely having a built-in SSL listener would be better...
Comment 3 Magnus Enger 2022-10-05 13:24:57 UTC
> it  should be possible to do this without too much effort.

That sounds promising ;-) 

Having a little look at this, but it feels like it is a little bit above me... 

I found this code, where we pass params from $config->{'server-params'} to ->run:

if (defined($config->{'server-params'})) {
    while (my ($key, $val) = each %{$config->{'server-params'}}) {
        push @parms, $key . '=' . $val;
    }
}
__PACKAGE__ ->run(@parms);
https://git.koha-community.org/Koha-community/Koha/src/branch/master/C4/SIP/SIPServer.pm#L80

From https://metacpan.org/pod/Net::Server::Proto::SSL#SYNOPSIS it looks like SSL is just a question of doing this: 

main->run(
    proto => 'ssl',
    SSL_key_file  => "/path/to/my/file.key",
    SSL_cert_file => "/path/to/my/file.crt",
);

Could this mean that enabling SSL is as simple as adding proto, SSL_key_file and SSL_cert_file to the <server-params> in the SIPconfig.xml? Or are there more adjustments that are needed somewhere?
Comment 4 David Cook 2022-10-10 01:06:14 UTC
(In reply to Magnus Enger from comment #3)
> Could this mean that enabling SSL is as simple as adding proto, SSL_key_file
> and SSL_cert_file to the <server-params> in the SIPconfig.xml? Or are there
> more adjustments that are needed somewhere?

I'd have to look into it more.

But I don't think that this is something I'm likely to work on. stunnel works well especially in a more centralized reverse proxy setup, so it's a good tool to use.

After talking with more hardware vendors, it seems like stunnel is often used on the client side as well.
Comment 5 Martin Renvoize (ashimema) 2022-10-10 09:47:35 UTC
In our experience, SIP2 clients still don't support this in the vast majority of cases.. we encourage all our customers to use stunnel and that's working well.
Comment 6 Katrin Fischer 2022-10-14 18:58:04 UTC
(In reply to Martin Renvoize from comment #5)
> In our experience, SIP2 clients still don't support this in the vast
> majority of cases.. we encourage all our customers to use stunnel and that's
> working well

Similar/same for us afaikt.
Comment 7 David Cook 2023-03-28 12:09:25 UTC
Closing this one as stunnel works well enough on both server and client side.