1. Forum
  2. Usenet
  3. COMP.MAIL.SENDMAIL

  • Re: OpenSSL 3.4.x supported?

    From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to AMM on Sat Dec 28 00:35:39 2024
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to AMM on Mon Jan 6 11:18:17 2025
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Mon Jan 6 18:31:40 2025
    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. . . .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to Grant Taylor on Tue Jan 7 01:28:38 2025
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Grant Taylor@21:1/5 to All on Tue Jan 7 16:50:25 2025
    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. . . .

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?utf-8?Q?Bj=C3=B8rn_Mork?=@21:1/5 to AMM on Wed Jan 8 13:52:04 2025
    AMM <[email protected]> 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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Claus =?iso-8859-1?Q?A=DFmann?= @21:1/5 to AMM on Wed Jan 8 12:00:16 2025
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)