New module: add wolfSSL as alternate TLS stack.
<!-- Kamailio Pull Request Template -->
<!-- IMPORTANT: - for detailed contributing guidelines, read: https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md - pull requests must be done to master branch, unless they are backports of fixes from master branch to a stable branch - backports to stable branches must be done with 'git cherry-pick -x ...' - code is contributed under BSD for core and main components (tm, sl, auth, tls) - code is contributed GPLv2 or a compatible license for the other components - GPL code is contributed with OpenSSL licensing exception -->
#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [X] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [ ] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description This a new module: an alternate TLS implementation based on wolfSSL. The current tls module based on OpenSSL has many multi-process workarounds and can be quite fragile.
This is the initial code dump which is a copy of `tls/` and edited to compile with wolfSSL by using the OpenSSL compatibility layer. The `doc/` directory has not been changed.
The proposal is to get it into the code base as soon as possible so as to sync up with any ongoing changes in the `tls/` module. Any shared features can be extracted out into a common module: like certificate and configuration.
In the short-term the steps are: * testing * use native wolfSSL APIs (remove OpenSSL compatibility layer) * remove OpenSSL multi-process hacks in this module
This module is inspired by the `tls_wolfssl` module in the sister SIP project.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/3144
-- Commit Summary --
* tls_wolfssl: new module TLS stack based on wolfSSL
-- File Changes --
A src/modules/tls_wolfssl/Makefile (81) A src/modules/tls_wolfssl/README (1713) A src/modules/tls_wolfssl/TODO.md (7) A src/modules/tls_wolfssl/doc/Makefile (4) A src/modules/tls_wolfssl/doc/certs_howto.xml (154) A src/modules/tls_wolfssl/doc/functions.xml (63) A src/modules/tls_wolfssl/doc/history.xml (38) A src/modules/tls_wolfssl/doc/hsm_howto.xml (64) A src/modules/tls_wolfssl/doc/params.xml (1410) A src/modules/tls_wolfssl/doc/rpc.xml (69) A src/modules/tls_wolfssl/doc/tls.xml (367) A src/modules/tls_wolfssl/fixed_c_zlib.h (258) A src/modules/tls_wolfssl/sbufq.h (283) A src/modules/tls_wolfssl/tls.cfg (106) A src/modules/tls_wolfssl/tls_bio.c (314) A src/modules/tls_wolfssl/tls_bio.h (69) A src/modules/tls_wolfssl/tls_cert.sh (201) A src/modules/tls_wolfssl/tls_cfg.c (289) A src/modules/tls_wolfssl/tls_cfg.h (111) A src/modules/tls_wolfssl/tls_config.c (536) A src/modules/tls_wolfssl/tls_config.h (53) A src/modules/tls_wolfssl/tls_ct_q.h (133) A src/modules/tls_wolfssl/tls_ct_wrq.c (205) A src/modules/tls_wolfssl/tls_ct_wrq.h (98) A src/modules/tls_wolfssl/tls_domain.c (1585) A src/modules/tls_wolfssl/tls_domain.h (238) A src/modules/tls_wolfssl/tls_dump_vf.c (150) A src/modules/tls_wolfssl/tls_dump_vf.h (41) A src/modules/tls_wolfssl/tls_init.c (589) A src/modules/tls_wolfssl/tls_init.h (85) A src/modules/tls_wolfssl/tls_locking.c (59) A src/modules/tls_wolfssl/tls_locking.h (34) A src/modules/tls_wolfssl/tls_map.c (195) A src/modules/tls_wolfssl/tls_map.h (77) A src/modules/tls_wolfssl/tls_mod.c (733) A src/modules/tls_wolfssl/tls_mod.h (45) A src/modules/tls_wolfssl/tls_rand.c (375) A src/modules/tls_wolfssl/tls_rand.h (32) A src/modules/tls_wolfssl/tls_rpc.c (263) A src/modules/tls_wolfssl/tls_rpc.h (33) A src/modules/tls_wolfssl/tls_select.c (1707) A src/modules/tls_wolfssl/tls_select.h (52) A src/modules/tls_wolfssl/tls_server.c (1557) A src/modules/tls_wolfssl/tls_server.h (101) A src/modules/tls_wolfssl/tls_util.c (99) A src/modules/tls_wolfssl/tls_util.h (87) A src/modules/tls_wolfssl/tls_verify.c (135) A src/modules/tls_wolfssl/tls_verify.h (42) A src/modules/tls_wolfssl/todo.txt (4)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/3144.patch https://github.com/kamailio/kamailio/pull/3144.diff
Thanks for this contribution!
Is the module at the phase of "it compiles only" or was it also tested a bit with some tls connections and SIP traffic?
It is at "it compiles only" + server starts without segfault.
Is the module at the phase of "it compiles only" or was it also tested a bit with some tls connections and SIP traffic?
@space88man pushed 1 commit.
5d58fde8750cf684673f96edb401570178ad1c32 tls_wolfssl: new module TLS stack based on wolfSSL
@space88man pushed 1 commit.
b6490badbb6e6f6fcbfc94748d5f88fbf615d250 tls_wolfssl: new module TLS stack based on wolfSSL
@space88man pushed 1 commit.
a8cea2ea5a84b3f904be60b6a78a55ab4141651e tls_wolfssl: new module TLS stack based on wolfSSL
@space88man pushed 1 commit.
57464e8ee47f1af46a8abd9843421ce89b1589dd tls_wolfssl: new module TLS stack based on wolfSSL
Thanks for the details and further work on it! I can merge it all grant you access to the kamailio repo in order to continue the development directly on the main source tree. You can still do pull requests if you want other developers to comment on changes to this module. If you want to push commits to other modules or components, it is recommended to make pull requests, so the developers have a chance to review and avoid conflicts on working on same code part at that moment.
Merged #3144 into master.
Thanks for the details and further work on it! I can merge it all grant you access to the kamailio repo in order to continue the development directly on the main source tree. You can still do pull requests if you want other developers to comment on changes to this module. If you want to push commits to other modules or components, it is recommended to make pull requests, so the developers have a chance to review and avoid conflicts on working on same code part at that moment.
Yes - I would appreciate access for further development of this module. Thank you.
Hello, thanks for the pull request. It was merged really fast. I would appreciate some comments on how to address the code duplication from the existing tls module. Just checked briefly, but several header files are completely identical, in some cases just a few differences (tls_rpc.h, tls_ct_q.h etc..) . Also some implementation is idential (tls_verify.c) The approach from tlsa module to just include the headers if they are not modified seems better to me than to just copy them completely. This is one of the more complicated modules, and now we are having three tls modules.
@henningw - if you read the PR description: `Any shared features can be extracted out into a common module: like certificate and configuration.`
But first is to get the module working properly, if proved not feasible at the end, then it can be removed. If ok, then think about next steps.
Thanks @miconda for the clarification. If this is work in progress and will be then further improved in the git master, fine with me. I did not got from the description that this extraction or refactoring regarding code duplication was planned from the original author.
@henningw @miconda - a somewhat related question before a hypothetical `tls_common` (or `tls_mgm` in OpenSIPS) intermediate module: in master and 5.6 do we really want to continue to support older versions of OpenSSL (< 1.1.1)? This backward compatibility leads to a lot of special casing and gnarly code.
If the argument is for building newer kamailio on systems where the packaged or system version is OpenSSL ≤ 1.0.2 then the argument could also be made that such users could build OpenSSL ≥ 1.1.1 first.
OpenSSL 1.0.2/1.1.0 are EoL in 2019 and perhaps we should not facilitate such outdated libraries.
@space88man: there are many deployments on older systems, so I would not remove anything from tls module right now.
I think it is better to get first the tls_wolfssl working properly as an alternative to the tls (openssl) module. But, being a new module, it can be developed to only support the newer versions of libwolfssl and without being compatible with old versions of libssl (openssl). In other words, you can remove the parts that related to OpenSSL < 1.1.1 in the new module tls_wolfssl.
Once tested and results are satisfactory, then we can look what are the common parts still left between the two modules and decide what would be a best way to deal with. But I won't spend time now to think about nor even attempt to extract code from tls module to another one.
-
Daniel-Constantin Mierla -
Henning Westerholt
-
space88man