[asterisk-bugs] [JIRA] (ASTERISK-30343) res_crypto: ast_sign_bin fails

[Michael Newton (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-30343?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=261610#comment-261610 ] 

Michael Newton commented on ASTERISK-30343:
-------------------------------------------

TLDR: {{update-crypto-policies --set LEGACY}}

Rather delayed, but I got a test install set up, using Asterisk 16.30.0. After stepping through the Asterisk code I got as far as {{res_crypto.c:360}} calling OpenSSL function {{EVP_PKEY_CTX_set_signature_md()}} which was failing.

{noformat}
Thread 27 "asterisk" hit Breakpoint 1, evp_pkey_sign (pkey=0x5555564fb100, in=0x7ffff60fdef0 "\r8\274AW\027,W\374I\a\246\232~\242F\343\274<\210\200", inlen=20, 
    sig=0x555555e4573c "", siglen=0x7ffff60fdedc, padding=1) at /usr/src/debug/asterisk-16.30.0-0.el9.x86_64/res/res_crypto.c:360
360	/usr/src/debug/asterisk-16.30.0-0.el9.x86_64/res/res_crypto.c: No such file or directory.
(gdb) stepi
0x00007ffff64cf650 in EVP_sha1 at plt () from /usr/lib64/asterisk/modules/res_crypto.so
(gdb) next
Single stepping until exit from function EVP_sha1 at plt,
which has no line number information.
EVP_sha1 () at crypto/evp/legacy_sha.c:98
98	{
{noformat}

Despite having all the debuginfo packages installed I couldn't get in there, but seeing {{legacy_sha.c}} reminded me of trouble we had with using older RSA keys with SHA1 signatures for SSH on one of our servers (and the temporary solution.) So in the end, I was able to resolve the issue by running {{update-crypto-policies --set LEGACY}}. The man pages have this to say about OpenSSL in particular:
{noformat}
* Applications using OpenSSL: If an application allows the configuration of
  ciphersuite string, the special cipher string "PROFILE=SYSTEM" should replace any other cipher string.
  Applications which use the default library settings automatically adhere to the policy.
  Applications following the policy inherit the settings for cipher suite preference.
  By default the OpenSSL library reads a configuration file when it is initialized. If
  the application does not override loading of the configuration file, the policy also
  sets the minimum TLS protocol version and default cipher suite preference via this
  file. If the application is long-running such as the httpd server it has to be restarted
  to reload the configuration file after policy is changed. Otherwise the changed policy
  cannot take effect.
{noformat}

Globally downgrading the system security is not an ideal solution; I guess the proper fix is to improve the security of Asterisk's keys, but in the short term I think this can be addressed with documentation updates.


> res_crypto: ast_sign_bin fails
> ------------------------------
>
>                 Key: ASTERISK-30343
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-30343
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_crypto
>    Affects Versions: 16.29.0, 18.15.1, 20.0.1
>         Environment: Alma Linux 9.1
>            Reporter: Michael Newton
>            Assignee: Unassigned
>            Severity: Major
>
> After upgrade from 16.28 to 16.29 our dundi queries stopped working with this error output:
> {noformat}
> WARNING[100840]: res_crypto.c:384 ast_sign_bin: RSA Signature (key gateway) failed -1
> NOTICE[100840]: pbx_dundi.c:1366 update_key: Failed to sign key (-1)!
> NOTICE[100840]: pbx_dundi.c:3376 dundi_send: Failed to send packet to '00:50:56:ae:13:23'
> {noformat}
> This appears to be a regression resulting from changes in ASTERISK-30046.



--
This message was sent by Atlassian JIRA
(v6.2#6252)