New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for other TLS/SSL libraries than OpenSSL #6509
Comments
Small devices should be running without the dbengine. The netdata instances on those devices should be streaming metrics to other netdata for long-term storage. @paulkatsoulakis on that sheet we have in #6300 we should also mention how one could remove a particular dependency, when they don't want the installation to include it. We already have several such flags, we may need to add more. The other TLS libraries do make sense for the SSL support though, so we should do the work anyway. |
Unless I'm mistaken, the dbengine is completely independent of OpenSSL. If it isn't, it should be, as it isn't doing any encryption. As far as alternate TLS implementations, mbed should indeed be on the list, and I'd argue that verifying against LibreSSL should be there too (I'm 99% certain from a quick look at what we're using that LibreSSL will work (provided of course that the headers match up properly), but having some level of official support would be good). GnuTLS and NSS would be nice to have in terms of flexibility, but not critical. Also, if we're looking at Windows support, we should probably eventually support SChannel (the TLS implementation provided as part of Windows). |
It's just using the cryptographic SHA functions. |
@mfundul OK, potentially stupid question: Why are we using a crypto hash for a non-cryptographic purpose? I mean, I would assume we're using it as part of some sort of hash table structure, or for integrity checking the files on disk when we load them, both of which don't need crypto-grade hashes. |
For the same reason it's used in deduplication solutions, to guarantee practically no collisions for deterministic UUID generation. edit: we use CRC32 for integrity checking |
Ah, OK, I didn't realize we were using UUID's internally in the dbengine backend. Might be worth considering the option of just using libuuid on Linux systems for that, as that would allow people to build Netdata on Linux without it depending on any SSL/TLS library. |
That is the plan for the current design, but until we put some data structures in place (e.g. metrics map) to handle random UUIDs we are stuck with uniquely mapping netdata chart/dimension identifiers to UUIDs. |
In any case, dbengine is not a hard requirement to compile the actual code itself. It can even be explicitly ran like this Moreover, dbengine is kind of useless in small devices without storage. |
I think there was no change since I reported this issue, right? OpenWrt is now using WolfSSL by default instead of MbedTLS and would be good if there is support for it as well instead of relying only on OpenSSL. |
There was some work for LibreSSL done by @Ferroin but unsure about others. |
Actually it was @thiagoftsm who did the LibreSSL stuff. I absolutely agree though that we need better support for a wider variety of TLS implementations. At minimum WolfSSL, but ideally probably also GNUTLS and MbedTLS as well. |
@thiagoftsm please do so |
Hello everybody, I made the PR that will bring support for I will take a look later to verify if a patch to Best regards! |
@thiagoftsm we are planning the ACLK-NG that will not need libwebsockets. |
Thanks for the update @underhood ! I won't expend time trying to fix the wolfssl compilation against |
With PR #15113 we re-wrote and abstracted the entire SSL support in netdata. Using the new code, it is much easier to have different ssl implementations in Netdata. |
Feature idea summary
OpenWrt aims for minimalistic devices even for their upcoming release (OpenWrt 19.07) they still count with support for routers with 4 MB / 32 MB. They are using mbedTLS which is designed to fit on small embedded devices. For these small devices, I can not provide a new version as since netdata version 1.15, there is a new database engine, which requires OpenSSL. I don't own any such of those small devices, but some people might do like @diizzyy, who helps me with keeping netdata up-to-date in OpenWrt. Current idea is to have two packages of Netdata in OpenWrt. (netdata-legacy = 1.14 for those small devices, which will be supported approx for a year and then netdata, the latest one)
Expected behavior
What is a disadvantage of mbed TLS that there is not support for TLS 1.3, yet. While wolfSSL supports it.
The text was updated successfully, but these errors were encountered: