17 Jun
2022
17 Jun
'22
11:53 a.m.
Hello Kamailio users,
I would like testers to try out a new module tls_wolfssl,
an alternate TLS transport based on wolfSSL.
Why another TLS transport implementation?
The travails of using OpenSSL >= 1.1.1 in Kamailio’s multi-process
paradigm has been documented by OpenSIPS (and that sister
project has implemented tls_wolfssl). Essentially, OpenSSL makes
no concessions to the multi-process use case and in fact has implementation
details that work against global shared memory structures.
As a result Kamailio contains some tricky code
* a pthread polyfill in core
* duplicated SSL_CTX per worker
* atexit workaround
How to test?
The code is currently in master and can be built in the usual way.
Debian has 5.2.0 libwolfssl-dev needed; for some RPM distros (el8, el9,
fc36) I have created a Copr repository
https://copr.fedorainfracloud.org/coprs/beaveryoga/wolfSSL/
Known limitations
The current state can be considered as identical to tls+OpenSSL 1.1.1/3.0.x.
Old TLS protocols < 1.2 and cipher list configuration don’t work, i.e., only
TLS 1.2 and 1.3 work with the default cipher list.
In your configuration just replace
loadmodule “tls.so”
with
loadmodule “tls_wolfssl.so”
The rest of the TLS configuration can remain unchanged unless
you are using a funky protocol version/cipher list combination.
Thanks!
S-P
17 Jun
17 Jun
1:52 p.m.
Hello,
thanks for contributing to the project!
On 17.06.22 10:53, Richard Chan wrote:
Hello Kamailio users,
[...]
As a result Kamailio contains some tricky code
* a pthread polyfill in core
* duplicated SSL_CTX per worker
* atexit workaround
Just some clarifications: the atexit is not libssl specific, it is from
the libc, just that libssl makes use of it. It can happen with other
libraries that do not need anything for multi-process.
Also, the duplicated context might be something that is needed because
of the multi-process design, not necessary the specific to libssl. We
have for example a connection to database per process as well.
The pthread locks init is indeed sort of workaround, although might
worth trying to push a patch to the libssl to make the flags optional
for setting them, it is just some initialization value (ie, to set
PTHREAD_PROCESS_SHARED attribute).
But those do not reduce in anyway the value of having an alternative
like tls_wolfssl.
How to test?
The code is currently in master and can be built in the usual way.
Debian has 5.2.0 libwolfssl-dev needed;
For the moment just adding that Ubuntu 20.04 has libwolfssl-dev 4.30, so
the module does not compile there.
Cheers,
Daniel
for some RPM distros (el8, el9,
fc36) I have created a Copr repository
https://copr.fedorainfracloud.org/coprs/beaveryoga/wolfSSL/
Known limitations
The current state can be considered as identical to tls+OpenSSL
1.1.1/3.0.x.
Old TLS protocols < 1.2 and cipher list configuration don’t work,
i.e., only
TLS 1.2 and 1.3 work with the default cipher list.
In your configuration just replace
loadmodule “tls.so”
with
loadmodule “tls_wolfssl.so”
The rest of the TLS configuration can remain unchanged unless
you are using a funky protocol version/cipher list combination.
Thanks!
S-P
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online: June 20-23, 2022
* https://www.asipto.com/sw/kamailio-advanced-training-online/
23 Jun
23 Jun
10:57 a.m.
On Fri, Jun 17, 2022 at 6:54 PM Daniel-Constantin Mierla
<miconda(a)gmail.com> wrote:
For the moment just adding that Ubuntu 20.04 has libwolfssl-dev 4.30, so
the module does not compile there.
Cheers,
Daniel
Hello Daniel and sr-users,
To facilitate testing of tls_wolfssl I have pushed a commit that
contains a submodule; at the early
stages of this module this will help avoid having to deal with
different versions of the library. You may
test as follows:
cd kamailio/;
git submodule init src/modules/tls_wolfssl/lib/wolfssl;
git submodule update src/modules/tls_wolfssl/lib/wolfssl;
make cfg; # other make commands
make -C src module_group_tls=tls_wolfssl group_include=tls every-module
Happy testing!
S-P
24 Jun
24 Jun
11:05 a.m.
Hello,
thanks for these details!
I am actually writing about the git submodule and I think we have decide
on a good/common practice should such need comes more often in the future.
I noticed that many project have a dedicated folder like vendor/ or
external/ where they place the 3rd party submodules. That makes it
easier to know the external dependencies and figure out also better the
impact on license, etc...
It is also better if another module needs the same submodule, for
example now we have crypto module that uses libssl. I do not know if
wolfssl has also those functions used by crypto module, if yes, maybe
someone wants to add a replace module for crypto with wolftls as well,
to not have to install libssl at all.
In my opinion, this approach would be better than have inside module
directory. I would propose to place them inside a folder like
misc/vendor or misc/external or another subfolder of misc/, given that
we do not want to add again (and grow) to the root folder like in the past.
I am going to open an issue on tracker about this and get the feedback
from other devs. But if any of community members can share best
practices out there, maybe from similar projects, then just reply to
mailing list.
Cheers,
Daniel
On 23.06.22 09:57, Anthony Alba wrote:
On Fri, Jun 17, 2022 at 6:54 PM Daniel-Constantin
Mierla
<miconda(a)gmail.com> wrote:
--
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - Online: June 20-23, 2022
* https://www.asipto.com/sw/kamailio-advanced-training-online/
For the moment just adding that Ubuntu 20.04 has
libwolfssl-dev 4.30, so
the module does not compile there.
Cheers,
Daniel
Hello Daniel and sr-users,
To facilitate testing of tls_wolfssl I have pushed a commit that
contains a submodule; at the early
stages of this module this will help avoid having to deal with
different versions of the library. You may
test as follows:
cd kamailio/;
git submodule init src/modules/tls_wolfssl/lib/wolfssl;
git submodule update src/modules/tls_wolfssl/lib/wolfssl;
make cfg; # other make commands
make -C src module_group_tls=tls_wolfssl group_include=tls every-module
Happy testing!
S-P
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions
* sr-users(a)lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the sender!
Edit mailing list options or unsubscribe:
* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
888
days inactive
895
days old
3 comments
3 participants
participants (3)
-
Anthony Alba -
Daniel-Constantin Mierla -
Richard Chan