Hello

I remember that when sendmail 8.18.1 was released in January 2024,
"officially" it supported only OpenSSL 3.0.x (from 3 series).

And there was some issue with OpenSSL 3.1.x and a bug reported was also
filed with OpenSSL. I can not recall what the issue was. I just faintly
remember it.

So just wanted to know, if this is still the case? Is the OpenSSL bug
resolved?

Or can sendmail be used with OpenSSL 3.4.x series safely now?

Please inform.

Thank you

AMM.

AMM wrote:

> And there was some issue with OpenSSL 3.1.x and a bug reported was also
> filed with OpenSSL. I can not recall what the issue was. I just faintly

Do you mean
"there is a double-free bug in 3.2.0 related to DANE"
See the openssl-users mailing list or
https://github.com/openssl/openssl/pull/22821

> So just wanted to know, if this is still the case? Is the OpenSSL bug
> resolved?

The bug was resolved.

> Or can sendmail be used with OpenSSL 3.4.x series safely now?

No idea - why don't you give it a try and report back?

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

Works like a champ with 3.4. I was just too lazy to recompile it after
OpenSSL 3.3.

# sendmail-version
Version 8.18.1
Compiled with: ALLOW_255 DANE HAVE_SSL_CTX_dane_enable MAX_TLSA_RR=64
DNSMAP IPV6_FULL LOG MAP_REGEX MATCHGECOS MILTER
MIME7TO8
MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB=4.8
NIS
PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS TCPWRAPPERS
TLS_EC
TLS_VRFY_PER_CTX USERDB USE_EAI XDEBUG
OS Defines: ADDRCONFIG_IS_BROKEN DNSSEC_TEST HASFCHOWN HASFCHMOD
HASGETDTABLESIZE HAS_GETHOSTBYNAME2 HASINITGROUPS
HASLSTAT
HASNICE HASRANDOM HASRRESVPORT HASSETREGID HASSETREUID
HASSETRLIMIT HASSETSID HASSETVBUF HASURANDOMDEV
HASSTRERROR
HASUNAME HASUNSETENV HASWAITPID IDENTPROTO
NEEDSGETIPNODE
REQUIRES_DIR_FSYNC SFS_VFS USE_DOUBLE_FORK
USE_SIGLONGJMP
Kernel symbols: /boot/vmlinux
Conf file: /etc/mail/submit.cf (default for MSP)
Conf file: /etc/mail/sendmail.cf (default for MTA)
Pid file: /var/run/sendmail.pid (default)
libsm Defines: SM_CONF_LONGLONG SM_CONF_MEMCHR SM_CONF_MSG SM_CONF_SEM
SM_CONF_SIGSETJMP SM_CONF_SHM SM_CONF_SSIZE_T
SM_CONF_STDBOOL_H
SM_CONF_STDDEF_H SM_CONF_SYS_CDEFS_H SM_CONF_UID_GID
DO_NOT_USE_STRCPY SM_HEAP_CHECK SM_OS=sm_os_linux
SM_VA_STD
FFR Defines: _FFR_MTA_STS _FFR_TLS_ALTNAMES _FFR_LOGASIS=1
_FFR_M_ONLY_IPV4
OpenSSL: compiled 0x30300000
OpenSSL: linked 0x30400000

On 28/12/24 11:05 am, Claus Aßmann wrote:
> AMM wrote:
>
>> And there was some issue with OpenSSL 3.1.x and a bug reported was also
>> filed with OpenSSL. I can not recall what the issue was. I just faintly
>
> Do you mean
> "there is a double-free bug in 3.2.0 related to DANE"
> See the openssl-users mailing list or
> https://github.com/openssl/openssl/pull/22821
>
> The bug was resolved.

Yes that's the one.

>
>> Or can sendmail be used with OpenSSL 3.4.x series safely now?
>
> No idea - why don't you give it a try and report back?

I took the risk and put it (8.18.1) on production server.

All seems to work fine from 2 days. (touchwood)

However I am concerned about this new line in sendmail.cf file.

EOPENSSL_CONF=/etc/mail/sendmail.ossl

In my case this file does not exist.

From 8.18.1 RELEASE NOTES:

Note: OpenSSL 3 loads by default an openssl.cnf file from a location
specified in the library which may cause unwanted behaviour in sendmail.
Hence sendmail sets the environment variable OPENSSL_CONF to
/etc/mail/sendmail.ossl to override the default.

It is not clear what unwanted behaviour can occur if OpenSSL defaults
are used? Didn't sendmail use OpenSSL defaults, earlier too?

Ideally, what setting should be mentioned in /etc/mail/sendmail.ossl?

Thank you

AMM.

AMM wrote:

> EOPENSSL_CONF=/etc/mail/sendmail.ossl

> In my case this file does not exist.

That's the entire idea - as the release notes entry explains:

> Note: OpenSSL 3 loads by default an openssl.cnf file from a location
> specified in the library which may cause unwanted behaviour in sendmail.

> It is not clear what unwanted behaviour can occur if OpenSSL defaults
> are used?

Check the OpenSSL config file / documentation, e.g., wrt
"security level".

> Didn't sendmail use OpenSSL defaults, earlier too?

sendmail never explicitly use{s,d} OpenSSL config files.

> Ideally, what setting should be mentioned in /etc/mail/sendmail.ossl?

None.

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

On 1/6/25 10:18, Claus Aßmann wrote:
> sendmail never explicitly use{s,d} OpenSSL config files.

Doesn't that mean that Sendmail would be using the defaults in the
OpenSSL on the system?

Which would mean that if the defaults compiled into OpenSSL change, then
Sendmail's behavior might also unexpectedly change.

The thing that comes to mind is the OpenSSL team changing what ciphers /
algorithms / key lengths / etc. are set as the default in the compiled
library.

> None.

If you ever run into a situation where the default changes in a way that
you don't like, you could add / change an entry in the OpenSSL config
file that Sendmail uses thus overriding the then changed default
compiled into the new OpenSSL library.

Networkers call this "nailing the thing a specific way" so that they
aren't surprised if -> when the default changes.

Both OpenSSL and OpenSSH are notorious for chasing security and dropping
legacy things much faster than other things. - I recently had an
OpenSSH update break support for ciphers / algorithms used on old
systems I manage. I had to change how OpenSSH behaved to get back into
the old systems.

--
Grant. . . .

Grant Taylor wrote:

> Which would mean that if the defaults compiled into OpenSSL change, then
> Sendmail's behavior might also unexpectedly change.

If you use different code, then you get different behaviour.
Hence it might be a good idea to read the "change log"
(and hope that all relevant changes are properly documented).

> The thing that comes to mind is the OpenSSL team changing what ciphers /
> algorithms / key lengths / etc. are set as the default in the compiled
> library.

Let's hope the RFCs are followed - after all, this is about
interoperability.

On 1/7/25 00:28, Claus Aßmann wrote:
> Let's hope the RFCs are followed - after all, this is about
> interoperability.

Sadly, I suspect that the OpenSSL and OpenSSH developers are some of the
first to violate /old/ RFCs by not including what they deem to be
deprecated. Thus new won't interoperate with old equipment.

Take a look at the following:

Link - OpenSSH: Legacy Options
- https://www.openssh.com/legacy.html

There are ciphers that used to be enabled that have been disabled in the
default / complied in configuration (as in /etc/ssh/sshd.conf) that can
be re-enabled with a config file.

I've seen similar with OpenSSL.

So old RFCs are willfully and wantonly violated in the name of security
progress.

I don't blame the OpenSSL / OpenSSH developers for what they are doing.
I do dislike what they are doing when it comes to still supporting retro
things.

I just experienced a problem where I had to alter a compile time option
for OpenSSH (client) to be able to log into an old Fibre Channel switch
and ancient Unix server. It changed in a point minor point release.

Things are constantly moving forward. So sometimes it's best to
*EXPLICITLY* specify what you want a given program to do. E.g. the
value in the EOPENSSL_CONF file. ;-)

--
Grant. . . .

On 06/01/25 9:48 pm, Claus Aßmann wrote:
> AMM wrote:
>
>> EOPENSSL_CONF=/etc/mail/sendmail.ossl
>
>> In my case this file does not exist.
>
> That's the entire idea - as the release notes entry explains:
>
>> Note: OpenSSL 3 loads by default an openssl.cnf file from a location
>> specified in the library which may cause unwanted behaviour in sendmail.
>
>> It is not clear what unwanted behaviour can occur if OpenSSL defaults
>> are used?
>
> Check the OpenSSL config file / documentation, e.g., wrt
> "security level".

Thank you for your response. However, it is still not clear what
unwanted behaviour can occur? If you can explain, then please do.

>
>> Didn't sendmail use OpenSSL defaults, earlier too?
>
> sendmail never explicitly use{s,d} OpenSSL config files.
>
>> Ideally, what setting should be mentioned in /etc/mail/sendmail.ossl?

Currently I have this in sendmail.mc file: (using from few years)

dnl # recommended from https://weakdh.org/sysadmin.html
LOCAL_CONFIG
O
CipherList=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
O DHParameters=/etc/ssl/dhparams.pem
O ServerSSLOptions=+SSL_OP_CIPHER_SERVER_PREFERENCE

Hopefully this is what is sufficient.

Regards

AMM.

AMM <anon.amish@gmail.com> writes:

> LOCAL_CONFIG
> O
> CipherList=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
> O DHParameters=/etc/ssl/dhparams.pem
> O ServerSSLOptions=+SSL_OP_CIPHER_SERVER_PREFERENCE

Doesn't matter, I guess. But you can also set those options by defining
confCIPHER_LIST, confDH_PARAMETERS and confSERVER_SSL_OPTIONS

Bjørn

AMM wrote:

> > Check the OpenSSL config file / documentation, e.g., wrt
> > "security level".

> Thank you for your response. However, it is still not clear what
> unwanted behaviour can occur? If you can explain, then please do.

Quoting the release notes:
* The default SSL/TLS security level has been changed from 1 to 2. RSA,
DSA and DH keys of 1024 bits and above and less than 2048 bits and ECC keys
of 160 bits and above and less than 224 bits were previously accepted by
default but are now no longer allowed. By default TLS compression was
already disabled in previous OpenSSL versions. At security level 2 it cannot
be enabled.

This might be useful for other applications, but not for SMTP
- it may break using STARTTLS with other MTAs.

> Currently I have this in sendmail.mc file: (using from few years)

> CipherList= ...

Why do you have that list?
"What's the problem you are trying to solve?"

BTW: Setting CipherList has NO effect when using TLSv1.3
(OpenSSL).

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.