Dont send emails with local version 14.0.0

Eduardo Carrasco

Sorry to be late here but I think I may have just spotted a potential issue that may cause your symptoms. Can you clarify your scenario for me here please?

Can you check in your instance's database to see if the SMTP password is being saved (it should save as an encrypted string) or if it is being set to NULL or blank? If it is set, can you try to change it to something else in the UI and then back to what it should be and make sure you can do this and check it saves in the database each time.

You say that "When you test sending outbound mail it's works" - does this mean when you are at the "System Email Settings" page, entering the password and clicking the "Send Test Email" button works fine? Or are you testing by sending an email from the in-built client e.g. from a Contact record?

Lastly, when you visit the "System Email Settings" page, do you see the "Change Password" link or are you seeing an empty text box for the password?

Thanks,

JH.

The password is saved correctly in the database.

Test Email button works fine in System Email Settings.

The problem is when send a Email from Emails Module or in a Process Definition or in logichook code.

Only I see an empty text box for the password in System Email Settings.

Eduardo,

As you are seeing the empty box for the password in System Email Settings then I believe the issue is as I suspect. I believe that if you try to update the password using that screen the save will wipe the value from the database.

I think that the issue is with the Blowfish encryption utility that Sugar uses. Or rather, with the cipher that the encryption uses to perform the encrypt / decrypt functions (actually done by the PHP function "openssl_decrypt") as this is using the 'bf-ecb' cipher in its call. That cipher is not supported by version 3 of OpenSSL which is what ships with PHP 8.2. To confirm, you can insert into your code somewhere a call to the PHP function: "openssl_get_cipher_methods" and see what ciphers are available to you. I am pretty sure that 'bf-ecb' will not be there. In fact this cipher is not only not supported by default, it is also marked as "to be avoided" by OpenSSL 3.0.

As this cipher is not supported, calls to the encrypt / decrypt functions return blank results. This means that Sugar is failing to decrypt all encrypted data. You are seeing this manifested as the password not working.

I guess that your platform stack is using a plain PHP 8.2 which uses the default OpenSSL settings? The fix for this is to modify your openssl.cnf file and add the items that pull in the legacy providers.

There are instructions for doing this here: https://www.practicalnetworking.net/practical-tls/openssl-3-and-legacy-providers/

Note that I had to slightly amend this as the section [provider_sect] did not action in my config file (I am using a Docker stack hardened up with SSL). I added the following to my openssl.cnf file:

[default_conf]
ssl_conf = ssl_sect
providers = provider_sect

# List of providers to load
[provider_sect]
default = default_sect
legacy = legacy_sect

[default_sect]
activate = 1

[legacy_sect]
activate = 1

Once I had added the directive to pull in legacy providers, the Blowfish encode / decode worked again.

Hopefully you can follow this. I only worked this out myself earlier this week having seen the issue come up when upgrading a system to use PHP 8.2 in preparation for an upgrade to Sugar v14.

Thanks,

JH.

I had already applied that configuration and it didn't work.

Eduardo,

Did you try to change the SMTP password and check what is saved in the database? If the database holds a blank entry after an attempt to save then it is the encryption functions that are at fault.

And also, did you run the "openssl_get_cipher_methods" PHP function to check the default Sugar Blowfish cipher is available to you? The easiest way is to (temporarily) add some $GLOBALS['log']->fatal statements to the code in the core Blowfish php file. Output something into the logs to show what each variable is holding at each stage before and after the calls and output that function above. The best way is to use var_export as it will properly format the results from the function call to allow logging out. Like this:

$GLOBALS['log']->fatal("Output from openssl_get_cipher_methods: ". var_export(openssl_get_cipher_methods(), true));

Then you can make sure the cipher being used is available.

If it is not, then the answer is probably that your openssl.cnf file is not being processed properly or at all. You may need to play with that to make sure the section that includes the legacy ciphers is actually being called - it did not get called in my file until I had adjusted the recommended setting to put it somewhere the default code was operating.

If the password is saving properly and the cipher is in the output list then I'm afraid I don't know what else the issue might be without a deep check into the instance.

Thanks,

JH.

The password is saved correctly but I think the problem is with openssl.cnf configuration.

How can I solve that?

Eduardo,

Apologies for the delay, I have been tied up with some work stuff and not had time to get back to you.

I think I agree that it is most likely that your OpenSSL configuration if at fault. I'm afraid it will be difficult to fix that remotely if it is the case. However, you can do some debugging if it is a local (On-Site) instance and you have access to the code files.

The best place to start is with the file:

./src/Security/Crypto/Blowfish.php

which handles the encoding and decoding of encrypted data, including the SMTP password. To do some debugging here, adjust the code so it lets you know exactly what it is managing to do. Look for the function: decode($key, $encoded) and change it to look like this:

    /**
     * Uses blowfish to decode data assumes data has been base64 encoded with the iv stored as part of the data
     *
     * @param string $key key to base decoding off of
     * @param string $encoded base64 encoded blowfish encrypted data
     *
     * @return string
     */
    public static function decode($key, $encoded)
    {
$GLOBALS['log']->fatal("In Blowfish::decode()...");
$GLOBALS['log']->fatal("key: ".var_export($key, true));
$GLOBALS['log']->fatal("encoded: ".var_export($encoded, true));
        // To be backwards compatible with how mcrypt/Pear_BlowFish works, remove zeropadding
        $returnVar = rtrim(openssl_decrypt($encoded, 'bf-ecb', self::padKey($key), OPENSSL_ZERO_PADDING), chr(0));
$GLOBALS['log']->fatal("returnVar: ".var_export($returnVar, true));
$GLOBALS['log']->fatal("openssl_get_cipher_methods: ".var_export(openssl_get_cipher_methods(), true));
        return $returnVar;

//        return rtrim(openssl_decrypt($encoded, 'bf-ecb', self::padKey($key), OPENSSL_ZERO_PADDING), chr(0));
    }

Then make sure the BPM process is working in the scheduler and you should get some output into sugarcrm.log (or wherever you have configured the logs to go). You do not need to kick off any emails, the BPM process will try to initialise an SMTP session whether there are emails or not I think.

As these are FATAL calls, it should be clean and easy to spot in the log. It should clearly show whether the decode function is able to decode the encrypted password. As OpenSSL is a key component here, any failure there will mean the password output is blank. The output line for openssl_get_cipher_mthods will also show you all ciphers available to openssl. It needs to include the legacy cipher "bf-ecb" in order for the Sugar decryption functions to work.

If the cipher is missing you need to investigate how to adjust your openssl.cnf file to make it load the legacy providers.

If the cipher is there but the password output is still blank then the issue is not likely to be with OpenSSL and I'm afraid you'll have to dig about a bit more.

Just as an aside, I found in one of our instances that, where the cron was run separately to the main Apache config, the OpenSSL config was different and it needed to be updated in both places in order to run properly (the platform was running on Docker containers with a separate container for each of Apache and Cron - similar to the SugarDockerized stack available). You may want to check the whatever is running your cron (or Windows batch scheduler) has permissions and proper access to OpenSSL as well.

Thanks,

JH.

Eduardo,

Apologies for the delay, I have been tied up with some work stuff and not had time to get back to you.

I think I agree that it is most likely that your OpenSSL configuration if at fault. I'm afraid it will be difficult to fix that remotely if it is the case. However, you can do some debugging if it is a local (On-Site) instance and you have access to the code files.

The best place to start is with the file:

./src/Security/Crypto/Blowfish.php

which handles the encoding and decoding of encrypted data, including the SMTP password. To do some debugging here, adjust the code so it lets you know exactly what it is managing to do. Look for the function: decode($key, $encoded) and change it to look like this:

    /**
     * Uses blowfish to decode data assumes data has been base64 encoded with the iv stored as part of the data
     *
     * @param string $key key to base decoding off of
     * @param string $encoded base64 encoded blowfish encrypted data
     *
     * @return string
     */
    public static function decode($key, $encoded)
    {
$GLOBALS['log']->fatal("In Blowfish::decode()...");
$GLOBALS['log']->fatal("key: ".var_export($key, true));
$GLOBALS['log']->fatal("encoded: ".var_export($encoded, true));
        // To be backwards compatible with how mcrypt/Pear_BlowFish works, remove zeropadding
        $returnVar = rtrim(openssl_decrypt($encoded, 'bf-ecb', self::padKey($key), OPENSSL_ZERO_PADDING), chr(0));
$GLOBALS['log']->fatal("returnVar: ".var_export($returnVar, true));
$GLOBALS['log']->fatal("openssl_get_cipher_methods: ".var_export(openssl_get_cipher_methods(), true));
        return $returnVar;

//        return rtrim(openssl_decrypt($encoded, 'bf-ecb', self::padKey($key), OPENSSL_ZERO_PADDING), chr(0));
    }

Then make sure the BPM process is working in the scheduler and you should get some output into sugarcrm.log (or wherever you have configured the logs to go). You do not need to kick off any emails, the BPM process will try to initialise an SMTP session whether there are emails or not I think.

As these are FATAL calls, it should be clean and easy to spot in the log. It should clearly show whether the decode function is able to decode the encrypted password. As OpenSSL is a key component here, any failure there will mean the password output is blank. The output line for openssl_get_cipher_mthods will also show you all ciphers available to openssl. It needs to include the legacy cipher "bf-ecb" in order for the Sugar decryption functions to work.

If the cipher is missing you need to investigate how to adjust your openssl.cnf file to make it load the legacy providers.

If the cipher is there but the password output is still blank then the issue is not likely to be with OpenSSL and I'm afraid you'll have to dig about a bit more.

Just as an aside, I found in one of our instances that, where the cron was run separately to the main Apache config, the OpenSSL config was different and it needed to be updated in both places in order to run properly (the platform was running on Docker containers with a separate container for each of Apache and Cron - similar to the SugarDockerized stack available). You may want to check the whatever is running your cron (or Windows batch scheduler) has permissions and proper access to OpenSSL as well.

Thanks,

JH.