Loading ...
Sorry, an error occurred while loading the content.

Client side DANE - minimum openssl version

Expand Messages
  • Markus Petri
    Hi, I m trying to get client side TLSA/DANE working on a SLES11 SP3 system with openssl 0.9.8j and Postfix 2.11.1. When the smtp client tries to connect to the
    Message 1 of 14 , May 8, 2014
    • 0 Attachment
      Hi,

      I'm trying to get client side TLSA/DANE working on a SLES11 SP3 system
      with openssl 0.9.8j and Postfix 2.11.1.

      When the smtp client tries to connect to the destination system, the
      following is logged:

      May 8 22:23:11 mail postfix-rz-out/smtp[22203]: warning: cannot generate TA certificates, no trust-anchor or DANE support
      May 8 22:23:11 mail postfix-rz-out/smtp[22203]: warning: petri-markus.de: dane configured, but no requisite library support
      May 8 22:23:11 mail postfix-rz-out/smtp[22203]: Untrusted TLS connection established to marge.ceotex.de[2a01:4f8:140:6ffb::24]:25: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)

      I suspect, that the distributed openssl library is too old, but I may
      be wrong.

      Any clues?
    • Viktor Dukhovni
      ... You need at least OpenSSL 1.0.0. ... You re not wrong, it is too old. -- Viktor.
      Message 2 of 14 , May 8, 2014
      • 0 Attachment
        On Thu, May 08, 2014 at 10:45:28PM +0200, Markus Petri wrote:

        > I'm trying to get client side TLSA/DANE working on a SLES11 SP3 system
        > with openssl 0.9.8j and Postfix 2.11.1.

        You need at least OpenSSL 1.0.0.

        > When the smtp client tries to connect to the destination system, the
        > following is logged:
        >
        > May 8 22:23:11 mail postfix-rz-out/smtp[22203]: warning:
        > cannot generate TA certificates, no trust-anchor or DANE support
        > May 8 22:23:11 mail postfix-rz-out/smtp[22203]: warning:
        > petri-markus.de: dane configured, but no requisite library support
        > May 8 22:23:11 mail postfix-rz-out/smtp[22203]:
        > Untrusted TLS connection established to
        > marge.ceotex.de[2a01:4f8:140:6ffb::24]:25:
        > TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)
        >
        > I suspect, that the distributed openssl library is too old, but I may
        > be wrong.

        You're not wrong, it is too old.

        --
        Viktor.
      • Robert Schetterer
        ... maybe a suboptimal mixture Best Regards MfG Robert Schetterer -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München
        Message 3 of 14 , May 8, 2014
        • 0 Attachment
          Am 08.05.2014 22:45, schrieb Markus Petri:
          > openssl 0.9.8j and Postfix 2.11.1.

          maybe a suboptimal mixture


          Best Regards
          MfG Robert Schetterer

          --
          [*] sys4 AG

          http://sys4.de, +49 (89) 30 90 46 64
          Franziskanerstraße 15, 81669 München

          Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
          Vorstand: Patrick Ben Koetter, Marc Schiffbauer
          Aufsichtsratsvorsitzender: Florian Kirstein
        • Andreas Schulze
          ... any hint s to build postfix + openssl-1.x on a system based on openssl-0.9.x ??? I also avoided building openssl from source for good reasons over the last
          Message 4 of 14 , May 9, 2014
          • 0 Attachment
            Robert Schetterer:
            > > openssl 0.9.8j and Postfix 2.11.1.
            > maybe a suboptimal mixture

            any hint's to build postfix + openssl-1.x on a system based on openssl-0.9.x ???
            I also avoided building openssl from source for good reasons over the last years.

            But I'm open to try.

            Andreas
          • Wietse Venema
            ... I have some success with installing OpenSSL in a different location (/opt/openssl-1.x.y) and pointing the Postfix CCARGS/AUXLIBS there. However, this may
            Message 5 of 14 , May 9, 2014
            • 0 Attachment
              Andreas Schulze:
              > Robert Schetterer:
              > > > openssl 0.9.8j and Postfix 2.11.1.
              > > maybe a suboptimal mixture
              >
              > any hint's to build postfix + openssl-1.x on a system based on
              > openssl-0.9.x ??? I also avoided building openssl from source for
              > good reasons over the last years.
              >
              > But I'm open to try.

              I have some success with installing OpenSSL in a different location
              (/opt/openssl-1.x.y) and pointing the Postfix CCARGS/AUXLIBS there.

              However, this may cause conflicts if you link Postfix with any
              libraries that were compiled against a different OpenSSL version
              (in my case, libldap).

              Wietse
            • Viktor Dukhovni
              ... It is rather easy to build on Unix-like systems. Unpack the tarball, cd to the top-level source directory and run ./config -h . This will suggest default
              Message 6 of 14 , May 9, 2014
              • 0 Attachment
                On Fri, May 09, 2014 at 10:58:30AM -0400, Wietse Venema wrote:

                > > Any hint's to build postfix + openssl-1.x on a system based on
                > > openssl-0.9.x ??? I also avoided building openssl from source for
                > > good reasons over the last years.

                It is rather easy to build on Unix-like systems.

                Unpack the tarball, cd to the top-level source directory and run
                './config -h'. This will suggest default build options.

                For example, on a Macbook Pro:

                $ ./config -h
                Operating system: i686-apple-darwinDarwin Kernel Version 13.1.0: Wed Apr 2 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64
                WARNING! If you wish to build 64-bit library, then you have to
                invoke './Configure darwin64-x86_64-cc' *manually*.
                Configuring for darwin-i386-cc
                /opt/local/bin/perl5 ./Configure darwin-i386-cc

                > I have some success with installing OpenSSL in a different location
                > (/opt/openssl-1.x.y) and pointing the Postfix CCARGS/AUXLIBS there.

                Then I just run:

                $ ./Configure --prefix=/opt/openssl-1.x.y darwin64-x86_64-cc

                > However, this may cause conflicts if you link Postfix with any
                > libraries that were compiled against a different OpenSSL version
                > (in my case, libldap).

                Indeed DLL-hell is a potential problem. You may also need to build
                LDAP, MySQL, PgSQL, ... all linked with the custom version of
                OpenSSL.

                It may be simpler to upgrade your system.

                --
                Viktor.
              • Andreas Schulze
                ... yes, upgrade would be best but sometimes, older crypto is not as painfull as it should be Andreas
                Message 7 of 14 , May 9, 2014
                • 0 Attachment
                  Viktor Dukhovni:
                  > It may be simpler to upgrade your system.
                  yes, upgrade would be best but sometimes,
                  older crypto is not as painfull as it should be

                  Andreas
                • Larry Stone
                  This thread got my intrigued as I have my system (OS X ôClientö doing lots of server stuff) almost entirely independent of Apple provided stuff in favor of
                  Message 8 of 14 , May 11, 2014
                  • 0 Attachment
                    This thread got my intrigued as I have my system (OS X “Client” doing lots of server stuff) almost entirely independent of Apple provided stuff in favor of building from source. OpenSSL is one I have not done. So I decided to try it on my test system (which is really my laptop booted from an alternate disk).

                    On May 9, 2014, at 10:18 AM, Viktor Dukhovni <postfix-users@...> wrote:

                    > On Fri, May 09, 2014 at 10:58:30AM -0400, Wietse Venema wrote:
                    >
                    >>> Any hint's to build postfix + openssl-1.x on a system based on
                    >>> openssl-0.9.x ??? I also avoided building openssl from source for
                    >>> good reasons over the last years.
                    >
                    > It is rather easy to build on Unix-like systems.
                    >
                    > Unpack the tarball, cd to the top-level source directory and run
                    > './config -h'. This will suggest default build options.
                    >
                    > For example, on a Macbook Pro:
                    >
                    > $ ./config -h
                    > Operating system: i686-apple-darwinDarwin Kernel Version 13.1.0: Wed Apr 2 23:52:02 PDT 2014; root:xnu-2422.92.1~2/RELEASE_X86_64
                    > WARNING! If you wish to build 64-bit library, then you have to
                    > invoke './Configure darwin64-x86_64-cc' *manually*.
                    > Configuring for darwin-i386-cc
                    > /opt/local/bin/perl5 ./Configure darwin-i386-cc
                    >
                    >> I have some success with installing OpenSSL in a different location
                    >> (/opt/openssl-1.x.y) and pointing the Postfix CCARGS/AUXLIBS there.
                    >
                    > Then I just run:
                    >
                    > $ ./Configure --prefix=/opt/openssl-1.x.y darwin64-x86_64-cc
                    >

                    I went with './Configure darwin64-x86_64-cc -shared' which puts everything in /usr/local/ssl (the -shared adds the .dylib - maybe I shouldn’t go that route).

                    >> However, this may cause conflicts if you link Postfix with any
                    >> libraries that were compiled against a different OpenSSL version
                    >> (in my case, libldap).
                    >
                    > Indeed DLL-hell is a potential problem. You may also need to build
                    > LDAP, MySQL, PgSQL, ... all linked with the custom version of
                    > OpenSSL.

                    As far as I can tell, the only things I have dependent on OpenSSL are Postfix, Dovecot, and Apache. Apache built fine and mod_info reports OpenSSL 1.0.1g. Dovecot appears to be fine but I haven’t figure out how to tell.

                    But Postfix…

                    First off, I’m a neophyte at make and building C programs. So I don’t fully understand all the options but think I am getting the hang of it.
                    I’ve been building Postfix, adapted from instructions at diymacserver.com, with:
                    make -f Makefile.init makefiles CCARGS='-DUSE_TLS -DUSE_SASL_AUTH \
                    -DUSE_CYRUS_SASL -I/usr/include/sasl \
                    -DDEF_COMMAND_DIR=\"/usr/local/sbin\" \
                    -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" \
                    -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" \
                    -DHAS_PCRE -I/usr/local/include \
                    -DHAS_SSL -I/usr/include/openssl' \
                    AUXLIBS='-L/usr/local/lib -lpcre -lssl -L/usr/lib -llber -lresolv -lsasl2’

                    Today, after learning a few things and realizing I need neither the LDAP nor Cyrus SASL stuff, I reduced that to:
                    make -f Makefile.init makefiles CCARGS='-DUSE_TLS -I/usr/include/openssl \
                    -DUSE_SASL_AUTH \
                    -DDEF_COMMAND_DIR=\"/usr/local/sbin\" \
                    -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" \
                    -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" \
                    -DHAS_PCRE -I/usr/local/include' \
                    AUXLIBS='-L/usr/local/lib -lpcre -lssl -L/usr/lib -lresolv’
                    which as of earlier today was used to rebuild my production build of 2.11.1.

                    On the test system, trying to force the new version of OpenSSL (1.0.1g), I used:
                    make -f Makefile.init makefiles \
                    CCARGS='-DUSE_TLS /usr/local/ssl/include/openssl \
                    -DUSE_SASL_AUTH \
                    -DDEF_COMMAND_DIR=\"/usr/local/sbin\" \
                    -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" \
                    -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" \
                    -DHAS_PCRE -I/usr/local/include' \
                    AUXLIBS='L/usr/local/ssl/lib –lssl –lcrypto \
                    -L/usr/local/lib -lpcre -L/usr/lib -lresolv’

                    It builds fine but when I run it, I get OpenSSL mismatch warnings from both smtp and smtpd:
                    May 11 17:38:14 mbpls.stonejongleux.com postfix/p10028/smtpd[10806]: warning: run-time library vs. compile-time header version mismatch: OpenSSL 1.0.1 may not be compatible with OpenSSL 0.9.8
                    and
                    May 11 17:38:14 mbpls.stonejongleux.com postfix/smtp[10807]: warning: run-time library vs. compile-time header version mismatch: OpenSSL 1.0.1 may not be compatible with OpenSSL 0.9.8

                    It all seems to work but obviously pieces of both are getting into the build and as I said, understanding all the nuances of makefiles is beyond me. Also, this is just for curiosity for now so more interested in learning at this point than actually getting it running. But pointing me in the right direction will be appreciated.

                    >
                    > It may be simpler to upgrade your system.

                    AFAIK, Apple does not have a later version of OpenSSL available.

                    --
                    Larry Stone
                    lstone19@...
                    http://www.stonejongleux.com/
                  • Viktor Dukhovni
                    ... The above syntax is incorrect. Try ... CCARGS= -DUSE_TLS -I/usr/local/ssl/include -DUSE_SASL_AUTH -DDEF_COMMAND_DIR= /usr/local/sbin
                    Message 9 of 14 , May 11, 2014
                    • 0 Attachment
                      On Sun, May 11, 2014 at 06:00:38PM -0500, Larry Stone wrote:

                      > On the test system, trying to force the new version of OpenSSL (1.0.1g), I used:
                      > make -f Makefile.init makefiles \
                      > CCARGS='-DUSE_TLS /usr/local/ssl/include/openssl \
                      > -DUSE_SASL_AUTH \
                      > -DDEF_COMMAND_DIR=\"/usr/local/sbin\" \
                      > -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" \
                      > -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" \
                      > -DHAS_PCRE -I/usr/local/include' \
                      > AUXLIBS='L/usr/local/ssl/lib ?lssl ?lcrypto \
                      > -L/usr/local/lib -lpcre -L/usr/lib -lresolv?

                      The above syntax is incorrect. Try

                      ... CCARGS='
                      -DUSE_TLS -I/usr/local/ssl/include
                      -DUSE_SASL_AUTH
                      -DDEF_COMMAND_DIR=\"/usr/local/sbin\"
                      -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\"
                      -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\"
                      -DHAS_PCRE -I/usr/local/include
                      ' \
                      AUXLIBS='
                      -L /usr/local/ssl/lib -lssl -lcrypto
                      -L/usr/local/lib -lpcre
                      '

                      --
                      Viktor.
                    • Larry Stone
                      ... That worked. Thanks. But I donÆt understand why. IÆm assuming the key difference was on the -DUSE_TLS directive. With the new OpenSSL version,
                      Message 10 of 14 , May 11, 2014
                      • 0 Attachment
                        On May 11, 2014, at 6:34 PM, Viktor Dukhovni <postfix-users@...> wrote:

                        > On Sun, May 11, 2014 at 06:00:38PM -0500, Larry Stone wrote:
                        >
                        >> On the test system, trying to force the new version of OpenSSL (1.0.1g), I used:
                        >> make -f Makefile.init makefiles \
                        >> CCARGS='-DUSE_TLS /usr/local/ssl/include/openssl \
                        >> -DUSE_SASL_AUTH \
                        >> -DDEF_COMMAND_DIR=\"/usr/local/sbin\" \
                        >> -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\" \
                        >> -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\" \
                        >> -DHAS_PCRE -I/usr/local/include' \
                        >> AUXLIBS='L/usr/local/ssl/lib ?lssl ?lcrypto \
                        >> -L/usr/local/lib -lpcre -L/usr/lib -lresolv?
                        >
                        > The above syntax is incorrect. Try
                        >
                        > ... CCARGS='
                        > -DUSE_TLS -I/usr/local/ssl/include
                        > -DUSE_SASL_AUTH
                        > -DDEF_COMMAND_DIR=\"/usr/local/sbin\"
                        > -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\"
                        > -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\"
                        > -DHAS_PCRE -I/usr/local/include
                        > ' \
                        > AUXLIBS='
                        > -L /usr/local/ssl/lib -lssl -lcrypto
                        > -L/usr/local/lib -lpcre
                        > '

                        That worked. Thanks.

                        But I don’t understand why. I’m assuming the key difference was on the -DUSE_TLS directive. With the new OpenSSL version, /usr/local/ssl/include contains only the openssl directory which in turn contains all the openssl header files. So how does the path specified behind -DUSE_TLS work?

                        --
                        Larry Stone
                        lstone19@...
                        http://www.stonejongleux.com/
                      • Viktor Dukhovni
                        ... Wrong mental model of the C-compiler -D option syntax. ... This is a boolean option, -DFOO is equivalent to -DFOO=1 . The option just activates the
                        Message 11 of 14 , May 11, 2014
                        • 0 Attachment
                          On Sun, May 11, 2014 at 08:57:29PM -0500, Larry Stone wrote:

                          > > The above syntax is incorrect. Try
                          > >
                          > > ... CCARGS='
                          > > -DUSE_TLS -I/usr/local/ssl/include
                          > > -DUSE_SASL_AUTH
                          > > -DDEF_COMMAND_DIR=\"/usr/local/sbin\"
                          > > -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\"
                          > > -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\"
                          > > -DHAS_PCRE -I/usr/local/include
                          > > ' \
                          > > AUXLIBS='
                          > > -L /usr/local/ssl/lib -lssl -lcrypto
                          > > -L/usr/local/lib -lpcre
                          > > '
                          >
                          > That worked. Thanks.
                          >
                          > But I don't understand why.

                          Wrong mental model of the C-compiler '-D' option syntax.

                          > I'm assuming the key difference was on the -DUSE_TLS directive.

                          This is a boolean option, "-DFOO" is equivalent to "-DFOO=1". The
                          option just activates the '#ifdef USE_TLS <tls-specific code> #endif'
                          blocks in the Postfix source code. It DOES NOT take any parameters.

                          To include additional directories in the header search path you
                          need a "-I /some/path" option.

                          > With the new OpenSSL version, /usr/local/ssl/include contains
                          > only the openssl directory which in turn contains all the openssl
                          > header files. So how does the path specified behind -DUSE_TLS work?

                          It is a separate option and need be after or even adjacent to -DUSE_TLS.
                          Because OpenSSL header files are included as:

                          #include <openssl/ssl.h>
                          #include <openssl/evp.h>
                          ...

                          The right path to add the search path is the directory containing
                          the "openssl" directory with all the headers. In particular this
                          works when the header paths are of the form:

                          /usr/include/openssl/some_openssl_header.h

                          and the default compiler search path contains /usr/include.

                          --
                          Viktor.
                        • Larry Stone
                          ... Viktor, thanks, that greatly improves my understanding of how those options works. And also serves as a reminder not to put to much trust in other
                          Message 12 of 14 , May 11, 2014
                          • 0 Attachment
                            On May 11, 2014, at 9:04 PM, Viktor Dukhovni <postfix-users@...> wrote:

                            > On Sun, May 11, 2014 at 08:57:29PM -0500, Larry Stone wrote:
                            >
                            >>> The above syntax is incorrect. Try
                            >>>
                            >>> ... CCARGS='
                            >>> -DUSE_TLS -I/usr/local/ssl/include
                            >>> -DUSE_SASL_AUTH
                            >>> -DDEF_COMMAND_DIR=\"/usr/local/sbin\"
                            >>> -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\"
                            >>> -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\"
                            >>> -DHAS_PCRE -I/usr/local/include
                            >>> ' \
                            >>> AUXLIBS='
                            >>> -L /usr/local/ssl/lib -lssl -lcrypto
                            >>> -L/usr/local/lib -lpcre
                            >>> '
                            >>
                            >> That worked. Thanks.
                            >>
                            >> But I don't understand why.
                            >
                            > Wrong mental model of the C-compiler '-D' option syntax.
                            >
                            >> I'm assuming the key difference was on the -DUSE_TLS directive.
                            >
                            > This is a boolean option, "-DFOO" is equivalent to "-DFOO=1". The
                            > option just activates the '#ifdef USE_TLS <tls-specific code> #endif'
                            > blocks in the Postfix source code. It DOES NOT take any parameters.
                            >
                            > To include additional directories in the header search path you
                            > need a "-I /some/path" option.
                            >
                            >> With the new OpenSSL version, /usr/local/ssl/include contains
                            >> only the openssl directory which in turn contains all the openssl
                            >> header files. So how does the path specified behind -DUSE_TLS work?
                            >
                            > It is a separate option and need be after or even adjacent to -DUSE_TLS.
                            > Because OpenSSL header files are included as:
                            >
                            > #include <openssl/ssl.h>
                            > #include <openssl/evp.h>
                            > ...
                            >
                            > The right path to add the search path is the directory containing
                            > the "openssl" directory with all the headers. In particular this
                            > works when the header paths are of the form:
                            >
                            > /usr/include/openssl/some_openssl_header.h
                            >
                            > and the default compiler search path contains /usr/include.

                            Viktor, thanks, that greatly improves my understanding of how those options works. And also serves as a reminder not to put to much trust in other people’s “how to” documents since if I now understand it correctly, the '-I/usr/include/openssl’ in the original document I followed at diymacserver.com was meaningless and instead, the headers were found from the default /usr/include.

                            --
                            Larry Stone
                            lstone19@...
                            http://www.stonejongleux.com/
                          • Viktor Dukhovni
                            ... Correct. If you re referring to: http://diymacserver.com/mail/snow-leopard/compiling-postfix-in-64-bits/ drop the author a note. The instructions should
                            Message 13 of 14 , May 11, 2014
                            • 0 Attachment
                              On Sun, May 11, 2014 at 10:53:05PM -0500, Larry Stone wrote:

                              > Viktor, thanks, that greatly improves my understanding of how
                              > those options work. And also serves as a reminder not to put to
                              > much trust in other people's "how to" documents since if I now
                              > understand it correctly, the '-I/usr/include/openssl' in the original
                              > document I followed at diymacserver.com was meaningless and instead,
                              > the headers were found from the default /usr/include.

                              Correct. If you're referring to:

                              http://diymacserver.com/mail/snow-leopard/compiling-postfix-in-64-bits/

                              drop the author a note. The instructions should be changed to:

                              make -f Makefile.init makefiles \
                              CCARGS='-arch x86_64
                              -DUSE_TLS
                              -DUSE_SASL_AUTH
                              -DDEF_SERVER_SASL_TYPE=\"dovecot\"
                              -DDEF_COMMAND_DIR=\"/usr/local/sbin\"
                              -DDEF_CONFIG_DIR=\"/usr/local/etc/postfix\"
                              -DDEF_DAEMON_DIR=\"/usr/local/libexec/postfix\"
                              -DHAS_MYSQL -I/usr/local/mysql/include
                              -DHAS_PCRE -I/usr/local/include
                              ' \
                              AUXLIBS='-L/usr/local/lib \
                              -lpcre -lssl -lcrypto \
                              -L/usr/local/mysql/lib -lmysqlclient -lz -lm'

                              On a Mac you should strongly consider a package manager, such as
                              either "MacPorts" or "Homebrew". These will also build dependencies,
                              make it easy to refresh packages that are out of date, ...

                              https://www.macports.org/

                              or if you're not put-off by Ruby:

                              http://brew.sh/

                              --
                              Viktor.
                            • Jonas Wielicki
                              ... Although older crypto saves you from heartbleeds. I think there are some good reasons (not that I’d do that myself) to run old versions of crypto
                              Message 14 of 14 , May 12, 2014
                              • 0 Attachment
                                On 09.05.2014 18:44, Andreas Schulze wrote:
                                > Viktor Dukhovni:
                                >> It may be simpler to upgrade your system.
                                > yes, upgrade would be best but sometimes,
                                > older crypto is not as painfull as it should be

                                Although older crypto saves you from heartbleeds. I think there are some
                                good reasons (not that I’d do that myself) to run old versions of crypto
                                libraries with backported security patches, as provided by Debian for
                                example.

                                >
                                > Andreas
                                >
                              Your message has been successfully submitted and would be delivered to recipients shortly.