check for libcrypto using EVP_CIPHER_CTX_new #1174
Conversation
|
This is exactly where #1111 started. |
ryancdotorg
force-pushed
the
no-more-des
branch
from
ee4114b
to
34c7a28
Compare
|
From having a quick look at #1111 I have changed this to use Could the maintainers please let me know if they're willing to accept a patch to bundle an MD5 implementation to fall back to if libcrypto isn't available to address concerns raised in #1111? I would be happy to provide HMAC-MD5 that can reuse key material across multiple calls (somewhat faster) as well. |
ryancdotorg
changed the title
|
Actually, there's a public domain implementation of MD5 that's compatible with the OpenSSL function prototypes here https://openwall.info/wiki/people/solar/software/public-domain-source-code/md5 which could be used. |
|
This needs more changes, please do not merge. |
|
With long-term maintenance in mind, a useful way to reason about it seems to be "if a user wants to use a particular old/new cipher/mode, it is their responsibility to provide a library version that supports it, and it is tcpdump code responsibility to detect and to use the required library functions, but not to reimplement any functionality that the library does not have". |
|
That seems sensible. Separate checks for MD5 and disabling that code when not available is straightforward. So, then:
In order to future-proof, in anticipation of not being able to rely on the long term availability if
|
Grab the stuff from libpcap's configure script that looks for libssl (and libcrypto) and adapt it to look for libcrypto. his includes some macros to check using pkg-config (and other macros, such as macros to save and restore CFLAGS, LIBS, and LDFLAGS; any resemblance between their names and the cmake_push_check_state() and cmake_pop_check_state() commands is *entirely* coincidental :-)). Instead of checking for DES_cbc_encrypt(), which we don't use, to determine whether the libcrypto we found is usable, check for EVP_CIPHER_CTX_block_size(), which we *do* use. (We also check whether the openssl/evp.h header exists; if it doesn't, we might have found the libcrypto that Apple bundles with macOS, for which they do *NOT* provide the header in newer versions of Xcode.) See also the-tcpdump-group#1174. This means that we don't need to check wehether we have openssl/evp.h at compile time - now, if we don't, we don't even set HAVE_LIBCRYPTO, so there's no need to check HAVE_OPENSSL_EVP_H.
|
Given that we use neither We currently use We do use |
Grab the stuff from libpcap's configure script that looks for libssl (and libcrypto) and adapt it to look for libcrypto. his includes some macros to check using pkg-config (and other macros, such as macros to save and restore CFLAGS, LIBS, and LDFLAGS; any resemblance between their names and the cmake_push_check_state() and cmake_pop_check_state() commands is *entirely* coincidental :-)). Instead of checking for DES_cbc_encrypt(), which we don't use, to determine whether the libcrypto we found is usable, check for EVP_CIPHER_CTX_block_size(), which we *do* use. (We also check whether the openssl/evp.h header exists; if it doesn't, we might have found the libcrypto that Apple bundles with macOS, for which they do *NOT* provide the header in newer versions of Xcode.) See also the-tcpdump-group#1174. This means that we don't need to check whether we have openssl/evp.h at compile time - now, if we don't, we don't even set HAVE_LIBCRYPTO, so there's no need to check HAVE_OPENSSL_EVP_H.
Grab the stuff from libpcap's configure script that looks for libssl (and libcrypto) and adapt it to look for libcrypto. his includes some macros to check using pkg-config (and other macros, such as macros to save and restore CFLAGS, LIBS, and LDFLAGS; any resemblance between their names and the cmake_push_check_state() and cmake_pop_check_state() commands is *entirely* coincidental :-)). Instead of checking for DES_cbc_encrypt(), which we don't use, to determine whether the libcrypto we found is usable, check for EVP_CIPHER_CTX_block_size(), which we *do* use. (We also check whether the openssl/evp.h header exists; if it doesn't, we might have found the libcrypto that Apple bundles with macOS, for which they do *NOT* provide the header in newer versions of Xcode.) See also #1174. This means that we don't need to check whether we have openssl/evp.h at compile time - now, if we don't, we don't even set HAVE_LIBCRYPTO, so there's no need to check HAVE_OPENSSL_EVP_H.
Grab the stuff from libpcap's configure script that looks for libssl (and libcrypto) and adapt it to look for libcrypto. his includes some macros to check using pkg-config (and other macros, such as macros to save and restore CFLAGS, LIBS, and LDFLAGS; any resemblance between their names and the cmake_push_check_state() and cmake_pop_check_state() commands is *entirely* coincidental :-)). Instead of checking for DES_cbc_encrypt(), which we don't use, to determine whether the libcrypto we found is usable, check for EVP_CIPHER_CTX_block_size(), which we *do* use. (We also check whether the openssl/evp.h header exists; if it doesn't, we might have found the libcrypto that Apple bundles with macOS, for which they do *NOT* provide the header in newer versions of Xcode.) See also #1174. This means that we don't need to check whether we have openssl/evp.h at compile time - now, if we don't, we don't even set HAVE_LIBCRYPTO, so there's no need to check HAVE_OPENSSL_EVP_H. (cherry picked from commit 749988b)
I build static versions of tcpdump for my own convenience, and I disable DES in OpenSSL when doing so. This causes tcpdump to fail to detect libcrypto.
Currently, I have a script that applies this patch - looking for
AES_cbc_encryptrather thanDES_cbc_encrypt- before building.Given that AES is now over a quarter of a century old, and is a required algorithm in TLS, I think we can assume that if libcrypto exsists, it will support AES.
DES, on the other hand, seems very reasonable to disable when building OpenSSL, and I expect that some Linux distributions will begin doing this by default in the next few years.