Check openssl 3.0 compatibility #1379
Comments
0xxon
changed the title
|
In absolute shocking news, Zeek compiles against the current alpha (alpha 12). We get a couple of deprecation warnings though that I will try to fix: There also are a few weird segfaults in tests that I will investigate. |
|
well, OpenSSL 3.0 is out now - so we should put this on as something to do for the next release. |
|
I tried this again - and there are good and bad news. The good news are - we get a couple of warnings, but we compile. Also - nearly all tests pass - and some of the failures are relatively trivial to catch baseline updates. On the negative side - two of the tests that do not pass have to do with the serialization of OpaqueVals. Currently, we can serialise Opaques of (md5/sha1) and send them over the network using broker. The way that that works is that we access the private data of OpenSSL - in the case of MD5 with For OpenSSL 3.0 the code that we have been using crashes. Also - while the function is still public, the data returned by it is marked as private - so I don't think we can really depend on it staying the same in the future. I will take a look to see if we can fix this - but I am kind of tempted to say that perhaps we should just not support sending Opaque of (hash) between nodes. On the plus side - I can also not really think of a usecase for this. |
|
This just got a whole bunch more urgent since, e.g., macports now uses OpenSSL 3 by default. I talked to @rsmmr a bit about this in the past. His feeling was that we should continue supporting sending opaques of (hash) between nodes. This likely will require us to switch implementations from OpenSSL to something that offers a stable internal representation. |
|
I just checked again if there is any way to reliably get access to the internal state of hash data structures in OpenSSL. The definitive answer is no - see openssl/openssl#14222 for details. It seems like support for this might be added in later versions of OpenSSL - but that does not help us. I am going to look up if we can just switch our hashing implementation to a different library (like crypto++), and if that would give us access to the internal state. |
|
Ok, after playing around with OpenSSL a bit more (wishful thinking...) - if we want to keep the functionality, we really have to switch crypto libraries. I took a look at crypto++ - which seems like it would work - but it will also be some work to interface with our build-system. Like a lot of crypto-libraries, it requires builds that are dependent on the system-architecture, contains assembly-files, etc. While I get that it is nice to have the ability to serialize the internal state of hash-operations, I am still a tad unconvinced that this really is worth it for functionality for which we don't have a well-defined use-case. |
|
Really not my area but will chime in.
Agree switching libraries for an undefined use case seems extreme.
I'm a little puzzled, md5/shave are strings no? Is this a blob that
converts to string? If so that would possibly be an escape for people
chasing a use case in this area. But may just be I don't understand.
If we assume all the recipients use the same zeek/openssl version is there
still a real risk? (Am sure there is no certainty given Private... But in
practice? Might let us keep options open)
S
…On Thu, Nov 11, 2021 at 6:28 AM Johanna ***@***.***> wrote:
Ok, after playing around with OpenSSL a bit more (wishful thinking...) -
if we want to keep the functionality, we really have to switch crypto
libraries.
I took a look at crypto++ - which seems like it would work - but it will
also be some work to interface with our build-system. Like a lot of
crypto-libraries, it requires builds that are dependent on the
system-architecture, contains assembly-files, etc.
While I get that it is nice to have the ability to serialize the internal
state of hash-operations, I am still a tad unconvinced that this really is
worth it for functionality for which we don't have a well-defined use-case.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1379 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADRHAWFOGGOYXHBUQHV2ZW3ULPHHXANCNFSM4WW3Y7RA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
|
This commit switches hashing from the more modern EVP message digest to the older direct function calls, that are deprecated as of OpenSSL 3.0. The reason is that we require the ability to store the internal state of hash operations to disk. This is no longer possible with the architecture that is used by the EVP digests; it is, however, possible when using the legacy methods. There might be a way to do this more cleanly in OpenSSL 3.1 - but for the moment this seems like the easiest solution - even though I am not really happy about it. For details see #1379 and openssl/openssl#14222
This commit fixes the compile-time warnings that OpenSSL 3.0 raises for our source-code. For the cases where this was necessary we now have two implementations - one for OpenSSL 1.1 and earlier, and one for OpenSSL 3.0. This also makes our testsuite pass with OpenSSL 3.0 Relates to GH-1379
This commit fixes the compile-time warnings that OpenSSL 3.0 raises for our source-code. For the cases where this was necessary we now have two implementations - one for OpenSSL 1.1 and earlier, and one for OpenSSL 3.0. This also makes our testsuite pass with OpenSSL 3.0 Relates to GH-1379
|
Currently we have one warning that is output when compiling CAF and using OpenSSL 3.0. That one should be fixed when actor-framework/actor-framework#1310 is merged. |
|
Sorry, I somehow missed that...
So - the final output of md5/sha-1 is a hash that is often represented as a hex-string. The part that we are interested in, of which support was removed, is to sync the internal state of the library inbetween operations. So - start hashing something, sync the state of the hash into a file/database/over the network, and then continue putting data in. For that you need to access the internal datastructures the library uses to track the current state. But - on the positive side - I found a workaround which is now part of master. |
We should start looking what we have to do to work with OpenSSL 3.
Alpha announcement: https://mta.openssl.org/pipermail/openssl-announce/2021-January/000189.html
The text was updated successfully, but these errors were encountered: