Upstream PR's to build Asterisk w/o Openssl deprecated API

Philip Prindeville philipp_subx at
Tue May 17 09:30:50 PDT 2022

Hi all,

I've got a series of reviews upstream in Asterisk to build against Openssl 1.1.x and 3.x without OPENSSL_SUPPRESS_DEPRECATED being required, if anyone is curious or wants to track that:

The review process for non-core developers of Asterisk is a bit slow, so I can't say when they'll get around to merging this... and since it's slated for "master", it will likely only appear in 19.x.  A backport to 18.x and 16.x seems unlikely.

I did need to add test infrastructure to it to allow running external commands to generate reference test vectors to validate the changes I was making, since certain functionality like OAEP padding in RSA is non-deterministic (there's a random portion of the padding to make asymmetric key encryption be more resistant to pre-imaging attacks), which means that every time you encrypt text, the cipher text will be different (hopefully), and therefore you can't do a bitwise compare against canned strings.

This was necessary to ensure that the rewrite from the 1.0.x API (i.e. using SHA1(), RSA_encrypt(), AES_encrypt(), etc.) to instead using the EVP_PKEY and EVP_MD API didn't introduce any regressions.

As a result, if we generate RSA encrypted text internally, we validate it by calling "openssl pkeyutl -d ..." to decrypt it, etc.

The entire cryptographic suite of Asterisk is a train wreck, from a Best Practices point of view... The use 128-bit AES keys, and ECB, both of which are deprecated... The RSA keys are fixed at 1024 bit, which is also deprecated... and they use RSA for bulk-data encryption, which is never supposed to happen (it's meant for signing or key-exchange, not stream ciphers).

I have a proposal for deprecating the current res_crypto resource and replacing it with a redux:

I welcome any comments.  Highlights of the proposal are:

* supporting stronger AES and RSA key sizes;
* deprecating weak block ciphers (like ECB, CBC, etc.) in favor of GCM;
* deprecating stream operations with RSA;
* adding EC support with NIST curves;
* more explicit API's with better sanity checking (e.g. passing input and output buffer lengths);
* provider support for keystores like TPM and HSM's;
* more test coverage;

No idea when I'll get around to doing it... I don't want to sink a lot of time into the effort for naught, if the above relatively simply PR's are going to languish, since this will be a much larger effort and likely more work to get it across the finish line.

External enthusiasm for getting this in might speed things along... maybe.



More information about the openwrt-devel mailing list