Re: Crash in OpenSSL v1.0.1 from dtls1_do_write OPENSSL_assert(len == (unsigned int)ret);
For anyone running across this, we also were affected by this issue and worked with the Asterisk community to produce the patch referenced here: https://issues.asterisk.org/jira/browse/ASTERISK-28576 This will return nonzero values to prevent the hard assert, for anyone that is using packaged versions of OpenSSL that may be difficult to change. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html
Re: Static linking libssl.a and libcrypto.a on Linux x64 fails
> Actually, that is also the format and mechanism with Microsoft Win32 tools, > they just use the DOS-like file name "foo.lib" instead of "libfoo.a" to > maintain makefile compatibility with their older Intel OMF-based toolchains. > The object files inside > the archive are in COFF format, as they seem to > have used Unix tools to bring up the initial "NT" operating system internally > back before the initial 1993 release. On some platforms, where objects can be > relinked, the constituent object files > produced by compiling source files are sometimes combined into a single large > object. This is most often seen on AIX, which uses IBM's XCOFF object format > (an enhanced COFF); XCOFF supports relinking objects, so you can bundle > objects up this way and save some time in symbol resolution when you link > against the library later. But even on AIX this is commonly seen with dynamic > libraries and relatively rare for static ones. As I mentioned earlier in my reply to Micheal, I would want to create a single archive that is a self contained 'package' (if you will) that alone would suffice for any application that requires openssl functionality. I've created certain wrappers over the original SSL APIs and the object files that contain this functionality (let's call this collectively as libapp.a) would be 'bundled' along with libssl.a and libcrypto.a. So as mike suggested, I'll combine the whole into a new shiny 'libappssl.a' and all that the application has to be is to pass this to the platform linker (which BTW is posix compliant) and that's all he requires. > Normally the linker isn't even involved in creating a static library. You > compile sources to objects, and then use ar(1) to create the static library. > The makefile you posted to StackOverflow doesn't include this step, so it's > hard to tell what exactly you're doing. That StackOverflow question contains yet another link that points to another question (which I had asked about creating the library). The Makefile for that library contains this at the final linking (or archiving) stage: libAPP.a: $(obj) @ar rcs $@ $^ #$(LINK.c) -shared $^ -o $@ I was creating a shared library earlier but now I am creating a static archive from the object files. > Note: I seem to recall from a long time ago that GNU ar can combine static > libraries directly (without all those temporary file names). > In BinUtils 2.25 this was apparently done by invoking ar in "MRI > compatibility mode" and using the script command "ADDLIB" inside the provided > MRI-style linker script. > For more details see the "ar scripts" part of the full GNU BinUtils TexInfo > manual. > Enjoy > Jakob Well, I'll take a look however Mike's method is pretty easy enough to follow. However, what I am concerned with is, which other libraries do I need to archive (except libc which seems to be obvious I assume) to allow libssl and libcrypto to run on a stripped down system that resembles Linux (aka is POSIX compliant)? Regards, Aijaz On Thu, Nov 14, 2019 at 6:28 AM Aijaz Baig wrote: > > Thank you for the suggestion. Will try that. > > Regarding the static library, the term 'linking' I used was more tongue in > cheek but nonetheless. However my current concern here is meeting libSSL and > libCrypto's dependencies on host libraries on Linux platform. For instance, > when I talked about 'linking' errors with respect to symbols like 'dlopen', > so as I mentioned, I had to specify '-ldl' and '-lz' to the gcc linker that > suggests a dynamic dependency on these platform libraries. > > I was trying to understand the components that would be needed to package the > whole shebang into an archive which I can later 'just run' on a similar Linux > system that has been completely stripped down for purposes of size and speed > > Is there a way to do that? > > On Wed, Nov 13, 2019 at 8:04 PM Michael Wojcik > wrote: >> >> > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf >> > Of Aijaz Baig >> > Sent: Wednesday, November 13, 2019 01:45 >> >> > I am trying to statically link libssl.a and libcrypto.a into a static >> > library of my own >> > which I will be using in an application (Linux). >> >> You can't link anything into a Linux static library, technically. >> >> ELF static libraries, like the older UNIX static libraries they're descended >> from, are just collections of object files, possibly with some additional >> metadata. (In BSD 4.x, for example, libraries often had an index member >> added using the ranlib utility, so that the linker didn't have to search the >> entire library for each symbol.) >> >> On some platforms, where objects can be relinked, the constituent object >> files produced by compiling source files are sometimes combined into a >> single large object. This is most often seen on AIX, which uses IBM's XCOFF >> object format (an enhanced COFF); XCOFF supports relinking objects, so you >> can bundle objects up this
Re: Static linking libssl.a and libcrypto.a on Linux x64 fails
Thank you for the suggestion. Will try that. Regarding the static library, the term 'linking' I used was more tongue in cheek but nonetheless. However my current concern here is meeting libSSL and libCrypto's dependencies on host libraries on Linux platform. For instance, when I talked about 'linking' errors with respect to symbols like 'dlopen', so as I mentioned, I had to specify '-ldl' and '-lz' to the gcc linker that suggests a dynamic dependency on these platform libraries. I was trying to understand the components that would be needed to package the whole shebang into an archive which I can later 'just run' on a similar Linux system that has been completely stripped down for purposes of size and speed Is there a way to do that? On Wed, Nov 13, 2019 at 8:04 PM Michael Wojcik < michael.woj...@microfocus.com> wrote: > > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On > Behalf Of Aijaz Baig > > Sent: Wednesday, November 13, 2019 01:45 > > > I am trying to statically link libssl.a and libcrypto.a into a static > library of my own > > which I will be using in an application (Linux). > > You can't link anything into a Linux static library, technically. > > ELF static libraries, like the older UNIX static libraries they're > descended from, are just collections of object files, possibly with some > additional metadata. (In BSD 4.x, for example, libraries often had an index > member added using the ranlib utility, so that the linker didn't have to > search the entire library for each symbol.) > > On some platforms, where objects can be relinked, the constituent object > files produced by compiling source files are sometimes combined into a > single large object. This is most often seen on AIX, which uses IBM's XCOFF > object format (an enhanced COFF); XCOFF supports relinking objects, so you > can bundle objects up this way and save some time in symbol resolution when > you link against the library later. But even on AIX this is commonly seen > with dynamic libraries and relatively rare for static ones. > > Normally the linker isn't even involved in creating a static library. You > compile sources to objects, and then use ar(1) to create the static > library. The makefile you posted to StackOverflow doesn't include this > step, so it's hard to tell what exactly you're doing. > > But in any case, linking a static library against another static library > is essentially a no-op. > > What you *can* do, if you don't want to have to list your library and the > OpenSSL libraries when linking your application, is combine multiple static > libraries into a single one - provided the object names don't conflict. > This is straightforward: > > $ mkdir tmp; cd tmp > $ ar x /path/to/libssl.a > $ ar x /path/to/libcrypto.a > $ cp /path/to/your/objects/*.o . > $ ar c ../your-library.a *.o > $ cd .. > $ rm -rf tmp > > (Untested, but see the ar manpage if you run into issues.) > > That should create a single archive library containing all the objects > from the three input libraries. Again, it relies on there being no filename > clashes among the objects; if there are, you'll have to rename some of them. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > > -- Best Regards, Aijaz Baig
Re: sshd fails to start - undefined symbol: EVP_KDF_ctrl
On Wed, Nov 13, 2019 at 01:47:31PM -0500, SP wrote: > Following an OS upgrade of the server I have been unable to start sshd > service. On this server some software is upgraded from the OS packages > whereas others are manually built. Openssl is manually built from source. > After the upgrade of the OS the error message I get when starting sshd is > sshd: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b The version I > was running was openssl.1.1.1a I then replaced it with openssl.1.1.1d hoping > it would resolve the problem. It did not. I would be grateful for any > pointers as to how I can resolve this. OpenSSL from openssl.org (upstream) has never had EVP_KDF_ctrl in the OpenSSL 1.1.1 release branch. That function briefly appeared in the 3.0.0 development (master) branch, but has since been replaced. Whoever built your SSH packages used a custom verson of OpenSSL. You really SHOULD NOT replace system packages (like OpenSSL) with your own builds, unless you're willing and able to ensure ABI compatibility with the vendor build. It is safer to install any custom copy of OpenSSL in a non-default location (I use /opt/openssl/1.1), and give the shared libraries in such copies non-default SONAMEs so as to avoid conflict. -- Viktor.
sshd fails to start - undefined symbol: EVP_KDF_ctrl
Following an OS upgrade of the server I have been unable to start sshd service. On this server some software is upgraded from the OS packages whereas others are manually built. Openssl is manually built from source. After the upgrade of the OS the error message I get when starting sshd is sshd: undefined symbol: EVP_KDF_ctrl, version OPENSSL_1_1_1b The version I was running was openssl.1.1.1a I then replaced it with openssl.1.1.1d hoping it would resolve the problem. It did not. I would be grateful for any pointers as to how I can resolve this.
Re: Help on Diffie Hellman key exchange
Thanks Rich, On Wed, Nov 13, 2019 at 12:34 PM Salz, Rich wrote: > *>*For using 1.1.0, we only need to call RAND_bytes() ? > > > > Yes. But do check the return value of RAND_bytes. >
Re: sk_X509_OBJECT_num()
Hi, They're macros, defined in SKM_DEFINE_STACK_OF() in safestack.h. If you DEFINE_STACK_OF(Foo), you'll automatically end up with a sk_Foo_num() macro. Cheers, -Dave > On Nov 13, 2019, at 12:20, Jason Schultz wrote: > > Hello- > > I am updating my Linux application from using OpenSSL 1.0.2 to 1.1.1 in > preparation for OpenSSL 3.0 (and of course the EOL of 1.0.2). I'm confused > about the function in the subject line as well as other, related sk_X509_* > functions. > > My code has always used these functions, and currently my code compiles and > runs successfully against 1.1.1. I was sort of doing an audit of my code, > evaluating the API calls that have changed vs not changed when I noticed > these functions. I searched for them in the 1.1.1 source. They don't exist, > except where called in x509_lu.c. In the 1.0.2 code base, they are called in > the same file, as well as are defined in a header, > /include/openssl/safestack.h. > > My question is, how are those symbols in my application being resolved since > they are no longer found in the safestack.h header file? > > My system previously had OpenSSL 1.0.2 installed when I installed 1.1.1, but > I don't think I have any old headers around that are being found when I > compile and link. But for some reason this works. They obviously work within > the OpenSSL 1.1.1 code also. > > I'm thinking I could be missing something basic about the compile/link > process that explains this. Any ideas? > > Thanks in advance. smime.p7s Description: S/MIME cryptographic signature
Re: Help on Diffie Hellman key exchange
On Wed, Nov 13, 2019 at 12:23:37PM -0500, Jason Qian via openssl-users wrote:
> Here is the code for creating the key (openssl-0.9.8h)
Is this is a new question? It seems to no longer be related to DH
key agreement.
> int AESCipher::createKey(unsigned char *buf, int keySize) {
> char seed[256];
> ::sprintf(seed, "%ldXXX_XXX_H__x__xxx_x_xxx__INCLUDED_",
> MiscUtils::generateId());
> RAND_seed(seed, ::strlen(seed));
>
> RAND_bytes(buf, keySize / 8);
> return keySize / 8;
> }
>
> For using 1.1.0, we only need to call RAND_bytes() ?
If the application running this code has no other sources of entropy,
and the above is the only "random" data stirred into the PRNG, then
you may be generating predictable AES keys in your 0.9.8h code.
It is likely that MiscUtils::generateId() does not generate
cryptographically secure random numbers, and even if it did, the
output is at most 64 bits (%ld), which is not long enough for an
AES key.
--
Viktor.
Re: Help on Diffie Hellman key exchange
>For using 1.1.0, we only need to call RAND_bytes() ? Yes. But do check the return value of RAND_bytes.
Re: sk_X509_OBJECT_num()
On 13/11/2019 17:20, Jason Schultz wrote: > Hello- > > I am updating my Linux application from using OpenSSL 1.0.2 to 1.1.1 in > preparation for OpenSSL 3.0 (and of course the EOL of 1.0.2). I'm > confused about the function in the subject line as well as other, > related sk_X509_* functions. > > My code has always used these functions, and currently my code compiles > and runs successfully against 1.1.1. I was sort of doing an audit of my > code, evaluating the API calls that have changed vs not changed when I > noticed these functions. I searched for them in the 1.1.1 source. They > don't exist, except where called in x509_lu.c. In the 1.0.2 code base, > they are called in the same file, as well as are defined in a header, > /include/openssl/safestack.h. > > My question is, how are those symbols in my application being resolved > since they are no longer found in the safestack.h header file? > > My system previously had OpenSSL 1.0.2 installed when I installed 1.1.1, > but I don't think I have any old headers around that are being found > when I compile and link. But for some reason this works. They obviously > work within the OpenSSL 1.1.1 code also. > > I'm thinking I could be missing something basic about the compile/link > process that explains this. Any ideas? > In the header file openssl/x509_vfy.h you will see this line: DEFINE_STACK_OF(X509_OBJECT) That macro is defined inside safestack.h and generates all the sk_*_*() functions (as inline functions). Matt > Thanks in advance.
Re: Help on Diffie Hellman key exchange
Thanks Rich and Tomas,
Here is the code for creating the key (openssl-0.9.8h)
int AESCipher::createKey(unsigned char *buf, int keySize) {
char seed[256];
::sprintf(seed, "%ldXXX_XXX_H__x__xxx_x_xxx__INCLUDED_",
MiscUtils::generateId());
RAND_seed(seed, ::strlen(seed));
RAND_bytes(buf, keySize / 8);
return keySize / 8;
}
For using 1.1.0, we only need to call RAND_bytes() ?
Jason
On Wed, Nov 13, 2019 at 12:11 PM Salz, Rich wrote:
> *>*RAND_seed(seed, ::strlen(seed));
> >RAND_bytes(buf, keySize / 8);
>
>
>
> I don’t know where you are getting the seed, but it is typically binary
> data, not a C string.
>
>
>
> If you are using 1.1.0 or later, you do not need to seed things.
>
Re: Help on Diffie Hellman key exchange
> On Nov 12, 2019, at 3:14 AM, Tomas Mraz wrote: > > Could it be a padding issue? I.E. use DH_compute_key_padded() instead. Do we have an open issue to document DH_compute_key_padded(3)? It should be documented right next to DH_compute_key(3), with some words to suggest that the caller needs to know whether the peer expects a key octet string that is fixed width (same as "p") or stripped of inessential leading zero octets. -- Viktor.
sk_X509_OBJECT_num()
Hello- I am updating my Linux application from using OpenSSL 1.0.2 to 1.1.1 in preparation for OpenSSL 3.0 (and of course the EOL of 1.0.2). I'm confused about the function in the subject line as well as other, related sk_X509_* functions. My code has always used these functions, and currently my code compiles and runs successfully against 1.1.1. I was sort of doing an audit of my code, evaluating the API calls that have changed vs not changed when I noticed these functions. I searched for them in the 1.1.1 source. They don't exist, except where called in x509_lu.c. In the 1.0.2 code base, they are called in the same file, as well as are defined in a header, /include/openssl/safestack.h. My question is, how are those symbols in my application being resolved since they are no longer found in the safestack.h header file? My system previously had OpenSSL 1.0.2 installed when I installed 1.1.1, but I don't think I have any old headers around that are being found when I compile and link. But for some reason this works. They obviously work within the OpenSSL 1.1.1 code also. I'm thinking I could be missing something basic about the compile/link process that explains this. Any ideas? Thanks in advance.
Re: Help on Diffie Hellman key exchange
>RAND_seed(seed, ::strlen(seed)); >RAND_bytes(buf, keySize / 8); I don’t know where you are getting the seed, but it is typically binary data, not a C string. If you are using 1.1.0 or later, you do not need to seed things.
Re: Help on Diffie Hellman key exchange
On Wed, 2019-11-13 at 11:11 -0500, Jason Qian wrote: > Hi Tomas, > >Using DH_compute_key_padded() seems fixed the problem. > > I have one more question regarding a similar issue but this time is > about AES key generation. > > I think the problem is related to RAND_seed or RAND_bytes (someone > also mentioned on another thread). > > RAND_seed(seed, ::strlen(seed)); > RAND_bytes(buf, keySize / 8); > I do not understand what is the problem you have. But nevertheless - you should not need to call RAND_seed() unless you are running the code on some very special platform where no method of automatical seeding of the OpenSSL RNG is available. Your RAND_bytes() call should be fine to produce an AES key of bit length keySize. > > > > > > On Tue, Nov 12, 2019 at 10:50 AM Jason Qian wrote: > > Thanks Tomas, > > > > I will try that. > > > > On Tue, Nov 12, 2019 at 3:14 AM Tomas Mraz > > wrote: > > > On Mon, 2019-11-04 at 17:34 -0500, Jason Qian via openssl-users > > > wrote: > > > > Hi > > > > > > > >We have an application that does the Diffie Hellman key > > > exchange > > > > (OpenSSL/1.1.0f). > > > >It works fine, but under heavy loaded conditions, sometimes > > > an > > > > invalide secret been generated and other side couldn't decrypt > > > the > > > > data (the secret seems offset by one). > > > > > > > >The client side is c++ and the server side is java. > > > > > > > > DH_compute_key(secretKey, bnY, m_DH); > > > > > > > >Someone in the openssl group also talks about a similar > > > issue, but > > > > not sure if have a solution. > > > > > > Could it be a padding issue? I.E. use DH_compute_key_padded() > > > instead. > > > -- Tomáš Mráz No matter how far down the wrong road you've gone, turn back. Turkish proverb [You'll know whether the road is wrong if you carefully listen to your conscience.]
Re: Static linking libssl.a and libcrypto.a on Linux x64 fails
On 13/11/2019 15:23, Michael Wojcik wrote: From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of Aijaz Baig Sent: Wednesday, November 13, 2019 01:45 I am trying to statically link libssl.a and libcrypto.a into a static library of my own which I will be using in an application (Linux). You can't link anything into a Linux static library, technically. ELF static libraries, like the older UNIX static libraries they're descended from, are just collections of object files, possibly with some additional metadata. (In BSD 4.x, for example, libraries often had an index member added using the ranlib utility, so that the linker didn't have to search the entire library for each symbol.) Actually, that is also the format and mechanism with Microsoft Win32 tools, they just use the DOS-like file name "foo.lib" instead of "libfoo.a" to maintain makefile compatibility with their older Intel OMF-based toolchains. The object files inside the archive are in COFF format, as they seem to have used Unix tools to bring up the initial "NT" operating system internally back before the initial 1993 release. On some platforms, where objects can be relinked, the constituent object files produced by compiling source files are sometimes combined into a single large object. This is most often seen on AIX, which uses IBM's XCOFF object format (an enhanced COFF); XCOFF supports relinking objects, so you can bundle objects up this way and save some time in symbol resolution when you link against the library later. But even on AIX this is commonly seen with dynamic libraries and relatively rare for static ones. Normally the linker isn't even involved in creating a static library. You compile sources to objects, and then use ar(1) to create the static library. The makefile you posted to StackOverflow doesn't include this step, so it's hard to tell what exactly you're doing. But in any case, linking a static library against another static library is essentially a no-op. What you *can* do, if you don't want to have to list your library and the OpenSSL libraries when linking your application, is combine multiple static libraries into a single one - provided the object names don't conflict. This is straightforward: $ mkdir tmp; cd tmp $ ar x /path/to/libssl.a $ ar x /path/to/libcrypto.a $ cp /path/to/your/objects/*.o . $ ar c ../your-library.a *.o $ cd .. $ rm -rf tmp (Untested, but see the ar manpage if you run into issues.) That should create a single archive library containing all the objects from the three input libraries. Again, it relies on there being no filename clashes among the objects; if there are, you'll have to rename some of them. Note: I seem to recall from a long time ago that GNU ar can combine static libraries directly (without all those temporary file names). In BinUtils 2.25 this was apparently done by invoking ar in "MRI compatibility mode" and using the script command "ADDLIB" inside the provided MRI-style linker script. For more details see the "ar scripts" part of the full GNU BinUtils TexInfo manual. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded
Re: Help on Diffie Hellman key exchange
Hi Tomas, Using DH_compute_key_padded() seems fixed the problem. I have one more question regarding a similar issue but this time is about AES key generation. I think the problem is related to RAND_seed or RAND_bytes (someone also mentioned on another thread). RAND_seed(seed, ::strlen(seed)); RAND_bytes(buf, keySize / 8); What other method do you suggest to use ? Thanks Jason On Tue, Nov 12, 2019 at 10:50 AM Jason Qian wrote: > Thanks Tomas, > > I will try that. > > On Tue, Nov 12, 2019 at 3:14 AM Tomas Mraz wrote: > >> On Mon, 2019-11-04 at 17:34 -0500, Jason Qian via openssl-users wrote: >> > Hi >> > >> >We have an application that does the Diffie Hellman key exchange >> > (OpenSSL/1.1.0f). >> >It works fine, but under heavy loaded conditions, sometimes an >> > invalide secret been generated and other side couldn't decrypt the >> > data (the secret seems offset by one). >> > >> >The client side is c++ and the server side is java. >> > >> > DH_compute_key(secretKey, bnY, m_DH); >> > >> >Someone in the openssl group also talks about a similar issue, but >> > not sure if have a solution. >> >> Could it be a padding issue? I.E. use DH_compute_key_padded() instead. >> >> -- >> Tomáš Mráz >> No matter how far down the wrong road you've gone, turn back. >> Turkish proverb >> [You'll know whether the road is wrong if you carefully listen to your >> conscience.] >> >> >>
Re: Removing Extensions from Client Hello Header
On Tuesday, 12 November 2019 21:22:51 CET, Benjamin Kaduk via openssl-users wrote: On Tue, Nov 12, 2019 at 01:13:49PM -0700, Phil Neumiller wrote: Thanks for all the useful device. I was able to get the server to accept this client hello message. If you're willing/able to share, it can be useful for us to know what products are buggy in that they don't implement extensions in a proper, extensible, manner and need to have the ClientHello extensions adjusted like this. If we have a list of "likely suspects" it can make diagnosing future connection issues easier. contributing a fingerprint to https://github.com/WestpointLtd/tls_prober would also be really welcome, for the same reasons -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
RE: Static linking libssl.a and libcrypto.a on Linux x64 fails
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Aijaz Baig > Sent: Wednesday, November 13, 2019 01:45 > I am trying to statically link libssl.a and libcrypto.a into a static library > of my own > which I will be using in an application (Linux). You can't link anything into a Linux static library, technically. ELF static libraries, like the older UNIX static libraries they're descended from, are just collections of object files, possibly with some additional metadata. (In BSD 4.x, for example, libraries often had an index member added using the ranlib utility, so that the linker didn't have to search the entire library for each symbol.) On some platforms, where objects can be relinked, the constituent object files produced by compiling source files are sometimes combined into a single large object. This is most often seen on AIX, which uses IBM's XCOFF object format (an enhanced COFF); XCOFF supports relinking objects, so you can bundle objects up this way and save some time in symbol resolution when you link against the library later. But even on AIX this is commonly seen with dynamic libraries and relatively rare for static ones. Normally the linker isn't even involved in creating a static library. You compile sources to objects, and then use ar(1) to create the static library. The makefile you posted to StackOverflow doesn't include this step, so it's hard to tell what exactly you're doing. But in any case, linking a static library against another static library is essentially a no-op. What you *can* do, if you don't want to have to list your library and the OpenSSL libraries when linking your application, is combine multiple static libraries into a single one - provided the object names don't conflict. This is straightforward: $ mkdir tmp; cd tmp $ ar x /path/to/libssl.a $ ar x /path/to/libcrypto.a $ cp /path/to/your/objects/*.o . $ ar c ../your-library.a *.o $ cd .. $ rm -rf tmp (Untested, but see the ar manpage if you run into issues.) That should create a single archive library containing all the objects from the three input libraries. Again, it relies on there being no filename clashes among the objects; if there are, you'll have to rename some of them. -- Michael Wojcik Distinguished Engineer, Micro Focus
Re: upgrading the openSSL version from 1.0.2j to 1.1.1c - api changes
On 13/11/2019 09:22, Umamaheswari Nagarajan wrote: > The following apis seems to be unavailable or modified in 1.1.1c, > > ENGINE_cleanup This still exists, but was converted from a function to a macro that does nothing. You no longer need to call it. OpenSSL 1.1.0+ cleans itself up automatically. > RAND_cleanup As above. > CRYPTO_lock This function was used to lock an internal OpenSSL lock. These locks are not exposed any more. You will need to rewrite your code to not need this function. There are some new lock related functions that exist that are essentially thin wrappers around the platform threading library that is in use. Depending on what you need it for they might suffice: CRYPTO_RWLOCK *CRYPTO_THREAD_lock_new(void); int CRYPTO_THREAD_read_lock(CRYPTO_RWLOCK *lock); int CRYPTO_THREAD_write_lock(CRYPTO_RWLOCK *lock); int CRYPTO_THREAD_unlock(CRYPTO_RWLOCK *lock); void CRYPTO_THREAD_lock_free(CRYPTO_RWLOCK *lock); https://www.openssl.org/docs/man1.1.1/man3/CRYPTO_THREAD_lock_new.html > > RSA_PKCS1_SSLeay Now called RSA_PKCS1_OpenSSL(). > DH_get_ex_new_index> DSA_get_ex_new_index > RSA_get_ex_new_index All of these still exist but were just converted from functions to macros. Matt
upgrading the openSSL version from 1.0.2j to 1.1.1c - api changes
Hi, We are upgrading the openSSL version from 1.0.2j to 1.1.1c in our product. The following apis seems to be unavailable or modified in 1.1.1c, ENGINE_cleanup RAND_cleanup CRYPTO_lock RSA_PKCS1_SSLeay DH_get_ex_new_index DSA_get_ex_new_index RSA_get_ex_new_index Please advise on the replacement api's that can to be used. Thanks Uma N
Re: Resetting DTLS server
On 2019-11-12 10:30 p.m., Patrick Herbst wrote: > > I'm not creating a new socket because it is UDP, and i'm assuming only > one client. If you use a BIO_new_dgram, then you dont need to You assumed one client, and you got one client. What's the problem :-) > Even if i were the "connect" the socket to the clients addr, the > client comes up with the same addr/port combination, so the server's > "connected" UDP socket will continue reading mesgs from the client. I think that it won't work with OpenSSL for more than one DTLS session to occur on the same 5-tuple pair. Whether or not that is correct behaviour according to a specification, I suspect is open to debate. signature.asc Description: OpenPGP digital signature
