Upstream PR's to build Asterisk w/o Openssl deprecated API
philipp_subx at redfish-solutions.com
Tue May 17 09:30:50 PDT 2022
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