tcpdump
tcpdump copied to clipboard
the-tcpdump-group
Add support for wolfSSL as an alternative to OpenSSL.
wolfSSL support leverages wolfSSL's OpenSSL compatibility layer, which maps OpenSSL's API onto native wolfSSL functions. To use wolfSSL, clone the wolfSSL repo from GitHub, configure with --enable-tcpdump, make, and make install. Then, when configuring tcpdump, point it to the wolfSSL installation with --with-wolfssl=<path to installation>.
I am quite happy to have wolfSSL support, but if it's gonna remain functional, then it needs to be in the CI system. Can you add some lines to .circle.yml/build-matrix.sh? Thank you for doing cmake as well.
I am quite happy to have wolfSSL support, but if it's gonna remain functional, then it needs to be in the CI system. Can you add some lines to .circle.yml/build-matrix.sh? Thank you for doing cmake as well.
Sure, I can look into that.
close #931
Just FYI, this is magic github stuff, such that, when this PR is merged, it would close that issue. You didn't need to close it yourself.
Just FYI, this is magic github stuff, such that, when this PR is merged, it would close that issue. You didn't need to close it yourself.
Good to know!
@mcr I've added logic to build_matrix.sh and build.sh to run builds with wolfSSL as the crypto provider. Since the --enable-tcpdump option for wolfSSL is quite new, it's not in an official release yet. As such, build_matrix.sh uses wolfSSL's master branch.
Will look into the build failures. At first glance, it looks like some are failing due to not having libtool installed.
Thank you for preparing these changes. Regarding the build failures, it might be easier to identify the additional dependencies on Linux first by taking a minimal Ubuntu 20.04 VM and installing only the packages listed in .cirrus.yml. Then you could take note of any additional packages required to get to a passing build. I can look into translating that list for the other involved OSes where possible.
Regarding the new code, after a brief look it seems that the base of your work is not well layered for alternative crypto libraries. It does not look right that protocol dissectors should know which specific library is in use. Maybe that would be better to address in the same go, for example, with one or more preparatory/cleanup commits before the commit that actually adds a new library.
To explain that, with all changes in place instead of #if defined(HAVE_LIBCRYPTO) || defined(HAVE_LIBWOLFSSL) in a protocol dissector it would be #ifdef CRYPTO_PROVIDER and calls to wrapper functions like nd_crypto_hash() and nd_crypto_decode(), which would then test for different values of CRYPTO_PROVIDER to compile the right thing. In which case you might find it simpler to call native wolfSSL functions from the wrapper functions instead of using the OpenSSL compatibility layer. Likewise, in future this layering could allow for crypto libraries that don't mimic OpenSSL, such as Libgcrypt.
However, if you find it better to use the compatibility layer in the first working implementation, it might be acceptable as well. Other reviewers should be able to make plenty of useful input too.
Hi @infrastation. Thanks for the feedback.
Regarding the build failures, it might be easier to identify the additional dependencies on Linux first by taking a minimal Ubuntu 20.04 VM and installing only the packages listed in .cirrus.yml. Then you could take note of any additional packages required to get to a passing build.
Excellent idea. I'll do just that.
I can look into translating that list for the other involved OSes where possible.
That would be great.
To explain that, with all changes in place instead of #if defined(HAVE_LIBCRYPTO) || defined(HAVE_LIBWOLFSSL) in a protocol dissector it would be #ifdef CRYPTO_PROVIDER and calls to wrapper functions like nd_crypto_hash() and nd_crypto_decode(), which would then test for different values of CRYPTO_PROVIDER to compile the right thing. In which case you might find it simpler to call native wolfSSL functions from the wrapper functions instead of using the OpenSSL compatibility layer. Likewise, in future this layering could allow for crypto libraries that don't mimic OpenSSL, such as Libgcrypt.
I think what you propose makes a lot of sense. If I understand you correctly, this is more-or-less the same approach I've seen in many other open source projects (e.g. OpenLDAP, libssh2). They abstract the crypto such that the code using it doesn't need to actually be aware of what the underlying crypto library is. I do think this is overall a better design than what I've done here. My work is the result of a customer request for us (wolfSSL) to port tcpdump to wolfSSL so that they could use tcpdump with a FIPS-validated cryptography library, which wolfSSL provides. Using the compatibility layer was the preferred route in order to get them up and running as quickly as possible. I think a better long term approach would be to create the abstraction layer and drop the usage of the compatibility layer, as you suggest.
However, if you find it better to use the compatibility layer in the first working implementation, it might be acceptable as well. Other reviewers should be able to make plenty of useful input too.
I'm not in any particular rush to have wolfSSL support upstreamed, so I would be fine with revising my approach here to create a crypto abstraction layer for tcpdump. Of course, this would be a slightly larger effort that I would probably find the time to work on here and there outside of my paid work duties, so it'll take a little while.