Re: RedHat 8.6 libk5crypto.so.3 misses symbol EVP_KDF with openssl 1.1.1l
Red Hat backports security fixes to older versions so if you keep your RHEL installation up-to-date with 'yum update' you should not need to install newer upstream releases on the system. Regards, Tomas Mraz On Tue, 2022-11-08 at 08:51 +0100, Matthias Apitz wrote: > El día martes, noviembre 08, 2022 a las 08:26:54a. m. +0100, Tomas > Mraz escribió: > > > Hi, > > > > Red Hat patches its OpenSSL implementation with some additional API > > calls. That means you cannot use builds from an unpatched upstream > > OpenSSL tarball in place of the system libcrypto and libssl > > libraries. > > > > The proper way is to always obtain updated system packages from > > your > > vendor, i.e., Red Hat. Otherwise you would have to try to update > > the > > source rpm package from RHEL with new openssl version keeping the > > patches that Red Hat adds to it. That is definitely not a trivial > > endeavour. > > > > If, for some reason, you need newer OpenSSL package for some > > particular > > application that you install to the system, it should be possible > > to > > keep the system openssl package untouched, install the upstream > > OpenSSL > > package somewhere into /opt or /usr/local, and link that > > application > > against this installation of OpenSSL. > > > > The primary question to ask is - why do you need to install > > openssl 1.1.1l on RHEL-8.6? > > > > Tomas Mraz, OpenSSL > > Thanks for your answer and explanation. We updated all our server on > SuSE > Linux SLES and RedHat to openssl 1.1.1l due to an announced security > problem (do > not remember the CVE, perhaps you will know better). The RH 8.6 > server > has: > > # /usr/bin/openssl version > OpenSSL 1.1.1k FIPS 25 Mar 2021 > > we use: > > # /usr/local/sisis-pap/bin/openssl version > OpenSSL 1.1.1l 24 Aug 2021 > > and have linked all our application servers agains this version. > > matthias > > -- Tomáš Mráz, OpenSSL
Not able to retreive session ticket both at server and client level
Dear Team,
Problem Statement : The session is resumable, but still the session does not
have any tickets after calling SL_CTX_sess_set_new_cb() and
SSL_new_session_ticket()
This is the method TLS_server_method and TLS_client_method we are using at
server and client level respectively.
Please guide me in getting the session ticket at server and client level.
Code snippet and the output at server side
printf("\n The session resumable is : [%d]",
SSL_SESSION_is_resumable(SSL_get_session(ssl)));
Output : The session resumable is : [1]
// set an call back function at session to be triggered during sending ticket
to client
SL_CTX_sess_set_new_cb(ctx, new_session_cb);
printf("\nThe new session ticket : [%d]",SSL_new_session_ticket(ssl));
Output : The new session ticket : [1]
printf("\nThe session has ticket
[%d]",SSL_SESSION_has_ticket(SSL_get0_session(ssl)));
Output : The session has ticket [0]
// Able to set the ticket appdata at server and able to retrevie the value at
server level but not at client level
SSL_SESSION_set1_ticket_appdata(SSL_get_session(ssl), m_ServerChallenge, 32);
unsigned char m_ServerChallenge1[32];
unsigned int sid_ctx_len1 = 0;
SSL_SESSION_get0_ticket_appdata(SSL_get_session(ssl),m_ServerChallenge1,
_ctx_len1);
// Able to print the above value at server side,but not able to get the same at
client side.
Regards,
Sethu V
RedHat 8.6 libk5crypto.so.3 misses symbol EVP_KDF with openssl 1.1.1l
Hello, We compile openssl 1.1.1l from the sources and run on RedHat 8.6 into the problem that the system shared lib /usr/lib64/libk5crypto.so.3 misses a symbol from openssl: # objdump -TC /usr/lib64/libk5crypto.so.3 | grep EVP_KDF DF *UND* OPENSSL_1_1_1b EVP_KDF_ctrl DF *UND* OPENSSL_1_1_1b EVP_KDF_CTX_new_id DF *UND* OPENSSL_1_1_1b EVP_KDF_CTX_free DF *UND* OPENSSL_1_1_1b EVP_KDF_derive # objdump -TC libssl.so.1.1 | grep EVP_KDF (nix) I checked also the sources 1.1.1l and 1.1.1s, there are a lot of 'EVP_*' symbols, but not EVP_KDF_ctrl. What is the correct way to fix this. Thanks in advance. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
Re: RedHat 8.6 libk5crypto.so.3 misses symbol EVP_KDF with openssl 1.1.1l
Hi, Red Hat patches its OpenSSL implementation with some additional API calls. That means you cannot use builds from an unpatched upstream OpenSSL tarball in place of the system libcrypto and libssl libraries. The proper way is to always obtain updated system packages from your vendor, i.e., Red Hat. Otherwise you would have to try to update the source rpm package from RHEL with new openssl version keeping the patches that Red Hat adds to it. That is definitely not a trivial endeavour. If, for some reason, you need newer OpenSSL package for some particular application that you install to the system, it should be possible to keep the system openssl package untouched, install the upstream OpenSSL package somewhere into /opt or /usr/local, and link that application against this installation of OpenSSL. The primary question to ask is - why do you need to install openssl 1.1.1l on RHEL-8.6? Tomas Mraz, OpenSSL On Tue, 2022-11-08 at 07:17 +0100, Matthias Apitz wrote: > > Hello, > > We compile openssl 1.1.1l from the sources and run on RedHat 8.6 into > the > problem that the system shared lib /usr/lib64/libk5crypto.so.3 misses > a > symbol from openssl: > > # objdump -TC /usr/lib64/libk5crypto.so.3 | grep EVP_KDF > DF *UND* OPENSSL_1_1_1b > EVP_KDF_ctrl > DF *UND* OPENSSL_1_1_1b > EVP_KDF_CTX_new_id > DF *UND* OPENSSL_1_1_1b > EVP_KDF_CTX_free > DF *UND* OPENSSL_1_1_1b > EVP_KDF_derive > > # objdump -TC libssl.so.1.1 | grep EVP_KDF > (nix) > > I checked also the sources 1.1.1l and 1.1.1s, there are a lot of > 'EVP_*' > symbols, but not EVP_KDF_ctrl. > > What is the correct way to fix this. Thanks in advance. > > matthias > -- Tomáš Mráz, OpenSSL
Re: RedHat 8.6 libk5crypto.so.3 misses symbol EVP_KDF with openssl 1.1.1l
El día martes, noviembre 08, 2022 a las 08:26:54a. m. +0100, Tomas Mraz escribió: > Hi, > > Red Hat patches its OpenSSL implementation with some additional API > calls. That means you cannot use builds from an unpatched upstream > OpenSSL tarball in place of the system libcrypto and libssl libraries. > > The proper way is to always obtain updated system packages from your > vendor, i.e., Red Hat. Otherwise you would have to try to update the > source rpm package from RHEL with new openssl version keeping the > patches that Red Hat adds to it. That is definitely not a trivial > endeavour. > > If, for some reason, you need newer OpenSSL package for some particular > application that you install to the system, it should be possible to > keep the system openssl package untouched, install the upstream OpenSSL > package somewhere into /opt or /usr/local, and link that application > against this installation of OpenSSL. > > The primary question to ask is - why do you need to install > openssl 1.1.1l on RHEL-8.6? > > Tomas Mraz, OpenSSL Thanks for your answer and explanation. We updated all our server on SuSE Linux SLES and RedHat to openssl 1.1.1l due to an announced security problem (do not remember the CVE, perhaps you will know better). The RH 8.6 server has: # /usr/bin/openssl version OpenSSL 1.1.1k FIPS 25 Mar 2021 we use: # /usr/local/sisis-pap/bin/openssl version OpenSSL 1.1.1l 24 Aug 2021 and have linked all our application servers agains this version. matthias -- Matthias Apitz, ✉ g...@unixarea.de, http://www.unixarea.de/ +49-176-38902045 Public GnuPG key: http://www.unixarea.de/key.pub signature.asc Description: PGP signature
