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

Certificate Error (android client)

Expand Messages
  • nanotek
    I am receiving a Certificate Error when sending mail from K-9 on my android. I do not receive any error on my PC client (Thunderbird). I only have a
    Message 1 of 29 , Dec 23, 2013
    • 0 Attachment
      I am receiving a "Certificate Error" when sending mail from K-9 on my
      android. I do not receive any error on my PC client (Thunderbird).

      I only have a self-signed public certificate and private key configured
      for use by Postfix. Should I create my own Certificate Authority and cat
      its certificate into a .chn file with the Postfix server certificate and
      use this instead of the standalone Postfix cert?

      Or should I create my own CA and just make use of the:

      $smtpd_tls_CAfile
      $smtpd_tls_CApath

      options in main.cf? Same result, I gather, via different means. But will
      it resolve this K-9 error? Thanks.

      --
      syn.bsdbox.co
    • nanotek
      ... Wow. I feel foolish. Yes: I did just upgrade. After having re-accepted my certificate, I can now send mail sans said error. Thanks, Richard. Still, might
      Message 2 of 29 , Dec 23, 2013
      • 0 Attachment
        > ------------ Original Message ------------
        >> Date: Tuesday, December 24, 2013 12:57:53 AM +1100
        >> From: nanotek <nanotek@...>
        >> To: postfix-users@...
        >> Subject: Certificate Error (android client)
        >>
        >> I am receiving a "Certificate Error" when sending mail from K-9 on
        >> my android. I do not receive any error on my PC client
        >> (Thunderbird).
        >>
        >> I only have a self-signed public certificate and private key
        >> configured for use by Postfix. Should I create my own Certificate
        >> Authority and cat its certificate into a .chn file with the
        >> Postfix server certificate and use this instead of the standalone
        >> Postfix cert?
        >>
        >> Or should I create my own CA and just make use of the:
        >>
        >> $smtpd_tls_CAfile
        >> $smtpd_tls_CApath
        >>
        >> options in main.cf? Same result, I gather, via different means.
        >> But will it resolve this K-9 error? Thanks.
        >
        >
        > Did you just upgrade to k9-4.802? They made some changes to the
        > their certificate code and the change log notes indicate that you'll
        > need to manually re-accept certificates that you manually accepted
        > previously (e.g., self-signed certs) ... and I can confirm this.
        >
        > Once accepted I don't think you'll get prompted again -- I haven't.
        >
        >
        > - Richard
        >
        >
        >

        Wow. I feel foolish.

        Yes: I did just upgrade. After having re-accepted my certificate, I can
        now send mail sans said error. Thanks, Richard.

        Still, might be a good time to create my own CA and upgrade to 4096 bit
        keys/certificates using SHA512 algorithms and make use of some
        Diffie-Hellman ephemeral elliptic curve parameters for perfect forward
        secrecy. I've read http://www.postfix.org/TLS_README.html -- Postfix
        documentation is exceptional by the way -- are there any guides for DHE?


        --
        syn.bsdbox.co
      • Wietse Venema
        ... There is a work-in-progress document on forward secrecy that covers both EDH and EECDH. It shows how to configure things (the defaults should be sufficient
        Message 3 of 29 , Dec 23, 2013
        • 0 Attachment
          nanotek:
          > Still, might be a good time to create my own CA and upgrade to 4096 bit
          > keys/certificates using SHA512 algorithms and make use of some
          > Diffie-Hellman ephemeral elliptic curve parameters for perfect forward
          > secrecy. I've read http://www.postfix.org/TLS_README.html -- Postfix
          > documentation is exceptional by the way -- are there any guides for DHE?

          There is a work-in-progress document on forward secrecy that covers
          both EDH and EECDH. It shows how to configure things (the defaults
          should be sufficient for many applications) and what you can expect
          to see in logging and message headers.

          http://www.postfix.org/FORWARD_SECRECY_README.html

          I am still fixing it for clarity, but it should be accurate. Feedback
          is welcome.

          Wietse
        • nanotek
          ... Thanks, Wietse. Much appreciated. I ll put it to use and let you know if I encounter any problems. -- syn.bsdbox.co
          Message 4 of 29 , Dec 23, 2013
          • 0 Attachment
            On 24/12/2013 1:40 AM, Wietse Venema wrote:
            > nanotek:
            >> Still, might be a good time to create my own CA and upgrade to 4096 bit
            >> keys/certificates using SHA512 algorithms and make use of some
            >> Diffie-Hellman ephemeral elliptic curve parameters for perfect forward
            >> secrecy. I've read http://www.postfix.org/TLS_README.html -- Postfix
            >> documentation is exceptional by the way -- are there any guides for DHE?
            >
            > There is a work-in-progress document on forward secrecy that covers
            > both EDH and EECDH. It shows how to configure things (the defaults
            > should be sufficient for many applications) and what you can expect
            > to see in logging and message headers.
            >
            > http://www.postfix.org/FORWARD_SECRECY_README.html
            >
            > I am still fixing it for clarity, but it should be accurate. Feedback
            > is welcome.
            >
            > Wietse
            >

            Thanks, Wietse. Much appreciated. I'll put it to use and let you know if
            I encounter any problems.

            --
            syn.bsdbox.co
          • Viktor Dukhovni
            ... You can deploy 4096-bit RSA key if it makes you feel more cool, but there is little point in going beyond 2048-bit RSA at this time. The further you stray
            Message 5 of 29 , Dec 23, 2013
            • 0 Attachment
              On Tue, Dec 24, 2013 at 01:29:38AM +1100, nanotek wrote:

              > Still, might be a good time to create my own CA and upgrade to 4096 bit
              > keys/certificates

              You can deploy 4096-bit RSA key if it makes you feel more cool,
              but there is little point in going beyond 2048-bit RSA at this
              time. The further you stray away from current practice into the
              land of "extreme" cryptography, the more likely you are to run into
              interoperability problems, without any real security gains.

              > using SHA512 algorithms

              TLSv1 and TLSv1.2 does not support negotiation of digest algorithms.
              Deploying digests beyond SHA1 will cause interoperability problems
              with systems that don't yet support the SHA2 family.

              > and make use of some
              > Diffie-Hellman ephemeral elliptic curve parameters for perfect forward
              > secrecy.

              This is enabled in Postfix >= 2.8 by default. If you stuck with
              2.6 or 2.7, see the new forward secrecy document.

              We obviously don't know which is stronger against hypothetical
              unpublished attacks, EDH at 2048-bits or the P-256 curve. Feel
              free to roll the dice. Against publically known attacks P-256 is
              both more secure and more computationally efficient than 2048-bit
              EDH.

              > I've read http://www.postfix.org/TLS_README.html -- Postfix
              > documentation is exceptional by the way

              Thanks for the praise.

              --
              Viktor.
            • Viktor Dukhovni
              ... I meant TLSv1 and TLSv1.1 , but typed TLSv1.2. Speaking of TLSv1.2, does anyone have more information about:
              Message 6 of 29 , Dec 23, 2013
              • 0 Attachment
                On Mon, Dec 23, 2013 at 03:09:09PM +0000, Viktor Dukhovni wrote:

                > > using SHA512 algorithms
                >
                > TLSv1 and TLSv1.2 does not support negotiation of digest algorithms.

                I meant "TLSv1 and TLSv1.1", but typed TLSv1.2.

                Speaking of TLSv1.2, does anyone have more information about:

                https://rt.openssl.org/Ticket/Display.html?id=3128&user=guest&pass=guest

                and the related OpenSSL post-1.0.1e fix:

                commit ca989269a2876bae79393bd54c3e72d49975fc75
                Author: Dr. Stephen Henson <steve@...>
                Date: Thu Dec 19 14:37:39 2013 +0000

                Use version in SSL_METHOD not SSL structure.

                When deciding whether to use TLS 1.2 PRF and record hash algorithms
                use the version number in the corresponding SSL_METHOD structure
                instead of the SSL structure. The SSL structure version is sometimes
                inaccurate. Note: OpenSSL 1.0.2 and later effectively do this already.
                (CVE-2013-6449)

                The issue seems to be triggered by Squid trying to use SSL_read()
                to flush socket input after an SSL error. If that's the only way
                to run into this problem, it should not be an issue for Postfix.
                Postfix does not perform any further I/O on SSL connections after
                an SSL or I/O error.

                --
                Viktor.
              • nanotek
                ... You re right; I ll keep 4096 bit for private data-, and key-encipherment and restrict service keys to 2048. ... I was just reading into this as I just
                Message 7 of 29 , Dec 23, 2013
                • 0 Attachment
                  On 24/12/2013 2:09 AM, Viktor Dukhovni wrote:
                  > On Tue, Dec 24, 2013 at 01:29:38AM +1100, nanotek wrote:
                  >
                  >> Still, might be a good time to create my own CA and upgrade to 4096 bit
                  >> keys/certificates
                  >
                  > You can deploy 4096-bit RSA key if it makes you feel more cool,
                  > but there is little point in going beyond 2048-bit RSA at this
                  > time. The further you stray away from current practice into the
                  > land of "extreme" cryptography, the more likely you are to run into
                  > interoperability problems, without any real security gains.

                  You're right; I'll keep 4096 bit for private data-, and key-encipherment
                  and restrict service keys to 2048.

                  >
                  >> using SHA512 algorithms
                  >
                  > TLSv1 and TLSv1.2 does not support negotiation of digest algorithms.
                  > Deploying digests beyond SHA1 will cause interoperability problems
                  > with systems that don't yet support the SHA2 family.

                  I was just reading into this as I just upgraded to OpenSSL 1.0.1e
                  (FreeBSD base system still installs 0.9.8y). I thought v1.x supported
                  SHA256 cipher suites. Thanks for making me aware, Viktor.

                  >
                  >> and make use of some
                  >> Diffie-Hellman ephemeral elliptic curve parameters for perfect forward
                  >> secrecy.
                  >
                  > This is enabled in Postfix >= 2.8 by default. If you stuck with
                  > 2.6 or 2.7, see the new forward secrecy document.

                  I'm running 2.11. Wietse provided the link, which I've read. It appears
                  to contain all necessary intel.

                  >
                  > We obviously don't know which is stronger against hypothetical
                  > unpublished attacks, EDH at 2048-bits or the P-256 curve. Feel
                  > free to roll the dice. Against publically known attacks P-256 is
                  > both more secure and more computationally efficient than 2048-bit
                  > EDH.

                  I think 384-bit ECDSA keys might be my choice then?

                  >
                  >> I've read http://www.postfix.org/TLS_README.html -- Postfix
                  >> documentation is exceptional by the way
                  >
                  > Thanks for the praise.
                  >

                  It's deserved; thank you all for your great work!

                  --
                  syn.bsdbox.co
                • Viktor Dukhovni
                  ... I don t have any interoperability information for NIST P-384 (i.e. secp384r1). Like its P-256 cousin it is part of Suite B, and thus generally also
                  Message 8 of 29 , Dec 23, 2013
                  • 0 Attachment
                    On Tue, Dec 24, 2013 at 03:00:37AM +1100, nanotek wrote:

                    > >We obviously don't know which is stronger against hypothetical
                    > >unpublished attacks, EDH at 2048-bits or the P-256 curve. Feel
                    > >free to roll the dice. Against publically known attacks P-256 is
                    > >both more secure and more computationally efficient than 2048-bit
                    > >EDH.
                    >
                    > I think 384-bit ECDSA keys might be my choice then?

                    I don't have any interoperability information for NIST P-384 (i.e.
                    secp384r1). Like its P-256 cousin it is part of Suite B, and thus
                    generally also supported by software that supports P-256, but it
                    likely not as widely used as P-256. If there are any practical
                    unpublished attacks on P-256, one might guess they would be due to
                    the curve being "cooked" to be vulnerable. In that case, it would
                    seem prudent to assume that P-384 is also suspect. If you're
                    sufficiently paranoid, there is nothing you can trust.

                    I don't see any compelling reason to prefer P-384 over P-256, but
                    also know of no reasons to avoid it. P-384 has higher CPU cost,
                    but this is generally tolerable in MTAs, since unlike web servers
                    the SMTP connection rate is generally well below CPU performance
                    limits.

                    --
                    Viktor.
                  • nanotek
                    ... Thanks, Viktor. I will conduct some research and weigh my options. Whatever choice, a significant improvement on my current cryptographic protocol will be
                    Message 9 of 29 , Dec 23, 2013
                    • 0 Attachment
                      On 24/12/2013 3:19 AM, Viktor Dukhovni wrote:
                      > On Tue, Dec 24, 2013 at 03:00:37AM +1100, nanotek wrote:
                      >
                      >>> We obviously don't know which is stronger against hypothetical
                      >>> unpublished attacks, EDH at 2048-bits or the P-256 curve. Feel
                      >>> free to roll the dice. Against publically known attacks P-256 is
                      >>> both more secure and more computationally efficient than 2048-bit
                      >>> EDH.
                      >>
                      >> I think 384-bit ECDSA keys might be my choice then?
                      >
                      > I don't have any interoperability information for NIST P-384 (i.e.
                      > secp384r1). Like its P-256 cousin it is part of Suite B, and thus
                      > generally also supported by software that supports P-256, but it
                      > likely not as widely used as P-256. If there are any practical
                      > unpublished attacks on P-256, one might guess they would be due to
                      > the curve being "cooked" to be vulnerable. In that case, it would
                      > seem prudent to assume that P-384 is also suspect. If you're
                      > sufficiently paranoid, there is nothing you can trust.
                      >
                      > I don't see any compelling reason to prefer P-384 over P-256, but
                      > also know of no reasons to avoid it. P-384 has higher CPU cost,
                      > but this is generally tolerable in MTAs, since unlike web servers
                      > the SMTP connection rate is generally well below CPU performance
                      > limits.
                      >

                      Thanks, Viktor. I will conduct some research and weigh my options.
                      Whatever choice, a significant improvement on my current cryptographic
                      protocol will be made.

                      --
                      syn.bsdbox.co
                    • Tom Hendrikx
                      ... Hash: SHA256 ... After reading, I m having some questions. The document states that forward secrecy is supported by default on recent postfix installs.
                      Message 10 of 29 , Dec 23, 2013
                      • 0 Attachment
                        -----BEGIN PGP SIGNED MESSAGE-----
                        Hash: SHA256

                        On 23-12-13 15:40, Wietse Venema wrote:
                        > nanotek:
                        >> Still, might be a good time to create my own CA and upgrade to
                        >> 4096 bit keys/certificates using SHA512 algorithms and make use
                        >> of some Diffie-Hellman ephemeral elliptic curve parameters for
                        >> perfect forward secrecy. I've read
                        >> http://www.postfix.org/TLS_README.html -- Postfix documentation
                        >> is exceptional by the way -- are there any guides for DHE?
                        >
                        > There is a work-in-progress document on forward secrecy that
                        > covers both EDH and EECDH. It shows how to configure things (the
                        > defaults should be sufficient for many applications) and what you
                        > can expect to see in logging and message headers.
                        >
                        > http://www.postfix.org/FORWARD_SECRECY_README.html
                        >
                        > I am still fixing it for clarity, but it should be accurate.
                        > Feedback is welcome.
                        >

                        After reading, I'm having some questions.

                        The document states that forward secrecy is supported by default on
                        recent postfix installs. However, the quick-start still has some
                        settings that apparently need tweaking.

                        Setting 'smtpd_tls_eecdh_grade = strong' is already available as
                        default (tested with postfix 2.10), so no actual work here.

                        Setting the files (and refreshing them using a cronjob) specified by
                        'smtpd_tls_mumble_param_file' is a bit unclear though. The default for
                        these params is empty, and setting them does not really show a
                        different behavior in postfix (i.e. using different ciphers and keys)
                        as far as visible from the logged information.

                        But since forward secrecy is supported by default, what does it help
                        to specify these params, and re-generate them once in a while? I've no
                        deep ssl knowledge, but the smtpd_tls_dh1024_param_file postconf
                        documentation seems to indicate that openssl distributes some kind of
                        defaults for these contents? Maybe it's a nice idea to make the
                        forward secrecy and/or postconf documentation a bit verbose on how
                        this works, and what benefits manual generation of these params has?


                        Tom
                        -----BEGIN PGP SIGNATURE-----
                        Version: GnuPG v1.4.14 (GNU/Linux)
                        Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

                        iQIcBAEBCAAGBQJSuGmkAAoJEJPfMZ19VO/1FbIP/jKzjUXPTGQLigTS5gZZzJA+
                        cEOuokXnYsUxcsce/kLfYvY0nPMI+YsByAPtcde8aNQ0efGJGI/sol4cfeJ2aXj0
                        ZGp3yUVN0RY+vcAdCvfL5Exa5nVM4UxMHfYuwJElZcid0ZpS/46D32EBZStq39n7
                        WbdPOqM2L3ey1PtsJZ4U9V0LSSz0uDfLTQRxtpK2nQJloPZHHShlWRZLsW3Sny4H
                        UdUdMijR8tpItOeLedaxmCeoBRyNEYxO++J+PRVp4feeeUVUicyU4CwUkx/wbS13
                        mE5EUttUmOU5GYF34B+9z+HdpyecnZjlr1s51Sfb5pKwSid6PxIeuNS6IvsgvSDQ
                        N0fP0wMNcTpgyDM196TctZc9OMtjhsUntXk90EnS34fOfEomjduXBHVGabZ+FARw
                        /pmJWeGNPdi7WtZJ/Ptr8ZgzdiIfZhqEkJWL5nhdCPzZGBX/2aI1ZRk236guhRkv
                        HOi6sRzrWw/iDdbfjbb31XqV4fsXCBUQ07SnVorCGcckt8PA5+KG6o/LRynhVK6r
                        RdlDs7iKGjQtHN2/SgKvgrenSxUYXyuHaN6hH+yihKZJ4JwHVTcDOarfUBTTJpi1
                        lr/AWQcKDHau5QtVr6s/YlzcRyv50ejgecViIfNcuwYjZoVgAVrGCfT7NJhcRA5H
                        2lxFvOTrFKxlvFlBg3Mx
                        =QrH8
                        -----END PGP SIGNATURE-----
                      • Wietse Venema
                        ... Note: greater security against pre-computation attacks against EDH can be obtained by periodically regenerating the EDH parameters as above (an hourly or
                        Message 11 of 29 , Dec 23, 2013
                        • 0 Attachment
                          Tom Hendrikx:
                          > Setting the files (and refreshing them using a cronjob) specified by
                          > 'smtpd_tls_mumble_param_file' is a bit unclear though. The default for
                          > these params is empty, and setting them does not really show a
                          > different behavior in postfix (i.e. using different ciphers and keys)
                          > as far as visible from the logged information.
                          >
                          > But since forward secrecy is supported by default, what does it help
                          > to specify these params, and re-generate them once in a while? I've no

                          Note: greater security against "pre-computation" attacks against
                          EDH can be obtained by periodically regenerating the EDH
                          parameters as above (an hourly or daily cron job running as
                          root can automate this task). The parameter files are not secret,
                          after all these are sent to all SMTP clients in the clear. Mode
                          0644 is fine.

                          However, this comment is (still) in the wrong place. It should
                          precede the commands that compute the parameters and that set
                          smtpd_tls_mumble_param_file stuff.

                          Wietse
                        • Viktor Dukhovni
                          ... s/reading/skimming/ :-) ... They don t *need* tweaking. However, the tweaked settings are *recommended. ... As stated. ...
                          Message 12 of 29 , Dec 23, 2013
                          • 0 Attachment
                            On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote:

                            > > I am still fixing it for clarity, but it should be accurate.
                            > > Feedback is welcome.
                            > >
                            >
                            > After reading, I'm having some questions.

                            s/reading/skimming/ :-)

                            > The document states that forward secrecy is supported by default on
                            > recent postfix installs. However, the quick-start still has some
                            > settings that apparently need tweaking.

                            They don't *need* tweaking. However, the "tweaked" settings are
                            *recommended.

                            > Setting 'smtpd_tls_eecdh_grade = strong' is already available as
                            > default (tested with postfix 2.10), so no actual work here.

                            As stated.

                            > Setting the files (and refreshing them using a cronjob) specified by
                            > 'smtpd_tls_mumble_param_file' is a bit unclear though. The default for
                            > these params is empty, and setting them does not really show a
                            > different behavior in postfix (i.e. using different ciphers and keys)
                            > as far as visible from the logged information.

                            http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs

                            ...

                            Postfix >= 2.2 support 1024-bit-prime EDH out of the box, with no
                            additional configuration, but you may want to override the default
                            prime to be 2048 bits long, and you may want to regenerate your
                            primes periodically.

                            > But since forward secrecy is supported by default, what does it help
                            > to specify these params, and re-generate them once in a while?

                            The default non-export prime is 1024 bits. As explained in the
                            document, you should consider using a 2048 bit non-export prime.

                            The best-attacks on prime EDH are "pre-computation" attacks, where
                            one spends a bunch of time computing a bunch of data about a
                            particular prime, and is then able to quickly solve the underlying
                            problem much faster for any input.

                            Though prime lengths are chosen based such pre-computation attacks
                            (rule of thumb is that for equivalent security EDH primes should
                            be about as long as RSA moduli) which are believed to be out of
                            reach for 2048 bit primes and perhaps still out of reach even for
                            1024 bit primes, one can make the attacks much less attractive by
                            frequently generating new primes independently at each site.

                            The compiled-in default prime in the Postfix source code is perhaps
                            within reach of the best-funded adversaries, who may have performed
                            the requisite pre-computation. Primes you generate on your server,
                            and use for a short time are unlikely to warrant the extraordinary
                            cost of the pre-computation attack.

                            > I've no deep ssl knowledge, but the smtpd_tls_dh1024_param_file postconf
                            > documentation seems to indicate that openssl distributes some kind of
                            > defaults for these contents?

                            I don't believe that OpenSSL provides default parameters, but
                            Postfix does.

                            > Maybe it's a nice idea to make the
                            > forward secrecy and/or postconf documentation a bit verbose on how
                            > this works, and what benefits manual generation of these params has?

                            The more advanced material we put in the document, the more
                            intimidating it will be for the average reader. But of course an
                            empty document is not optimal, so we have to aim for the middle.

                            There is a range of reader sophistication we can support, it is a
                            trade-off between readable hands-on knowledge and a more detailed,
                            but technically demanding presentation of the rationale.


                            --
                            Viktor.
                          • Wietse Venema
                            ... In this section, the commands that compute the parameters PRECEDE the text that says why one might want to do this. This is not a skimming error, it is a
                            Message 13 of 29 , Dec 23, 2013
                            • 0 Attachment
                              Viktor Dukhovni:
                              > On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote:
                              >
                              > > > I am still fixing it for clarity, but it should be accurate.
                              > > > Feedback is welcome.
                              > > >
                              > >
                              > > After reading, I'm having some questions.
                              >
                              > s/reading/skimming/ :-)

                              In this section, the commands that compute the parameters PRECEDE
                              the text that says why one might want to do this.

                              This is not a skimming error, it is a presentation error.

                              Wietse
                            • Tom Hendrikx
                              ... Hash: SHA256 ... As stated, I assumed that the default primes came from openssl, based on the smtpd_tls_dh1024_param_file description in postconf(5). While
                              Message 14 of 29 , Dec 23, 2013
                              • 0 Attachment
                                -----BEGIN PGP SIGNED MESSAGE-----
                                Hash: SHA256

                                On 23-12-13 18:30, Viktor Dukhovni wrote:
                                > On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote:
                                >
                                >>> I am still fixing it for clarity, but it should be accurate.
                                >>> Feedback is welcome.
                                >>>
                                >>
                                >> After reading, I'm having some questions.
                                >
                                > s/reading/skimming/ :-)
                                >
                                >> The document states that forward secrecy is supported by default
                                >> on recent postfix installs. However, the quick-start still has
                                >> some settings that apparently need tweaking.
                                >
                                > They don't *need* tweaking. However, the "tweaked" settings are
                                > *recommended.
                                >
                                >> Setting 'smtpd_tls_eecdh_grade = strong' is already available as
                                >> default (tested with postfix 2.10), so no actual work here.
                                >
                                > As stated.
                                >
                                >> Setting the files (and refreshing them using a cronjob) specified
                                >> by 'smtpd_tls_mumble_param_file' is a bit unclear though. The
                                >> default for these params is empty, and setting them does not
                                >> really show a different behavior in postfix (i.e. using different
                                >> ciphers and keys) as far as visible from the logged information.
                                >
                                > http://www.postfix.org/FORWARD_SECRECY_README.html#server_fs
                                >
                                > ...
                                >
                                > Postfix >= 2.2 support 1024-bit-prime EDH out of the box, with no
                                > additional configuration, but you may want to override the default
                                > prime to be 2048 bits long, and you may want to regenerate your
                                > primes periodically.
                                >
                                >> But since forward secrecy is supported by default, what does it
                                >> help to specify these params, and re-generate them once in a
                                >> while?
                                >
                                > The default non-export prime is 1024 bits. As explained in the
                                > document, you should consider using a 2048 bit non-export prime.
                                >
                                > The best-attacks on prime EDH are "pre-computation" attacks, where
                                > one spends a bunch of time computing a bunch of data about a
                                > particular prime, and is then able to quickly solve the underlying
                                > problem much faster for any input.
                                >
                                > Though prime lengths are chosen based such pre-computation attacks
                                > (rule of thumb is that for equivalent security EDH primes should be
                                > about as long as RSA moduli) which are believed to be out of reach
                                > for 2048 bit primes and perhaps still out of reach even for 1024
                                > bit primes, one can make the attacks much less attractive by
                                > frequently generating new primes independently at each site.
                                >
                                > The compiled-in default prime in the Postfix source code is
                                > perhaps within reach of the best-funded adversaries, who may have
                                > performed the requisite pre-computation. Primes you generate on
                                > your server, and use for a short time are unlikely to warrant the
                                > extraordinary cost of the pre-computation attack.
                                >
                                >> I've no deep ssl knowledge, but the smtpd_tls_dh1024_param_file
                                >> postconf documentation seems to indicate that openssl distributes
                                >> some kind of defaults for these contents?
                                >
                                > I don't believe that OpenSSL provides default parameters, but
                                > Postfix does.
                                >
                                >> Maybe it's a nice idea to make the forward secrecy and/or
                                >> postconf documentation a bit verbose on how this works, and what
                                >> benefits manual generation of these params has?
                                >
                                > The more advanced material we put in the document, the more
                                > intimidating it will be for the average reader. But of course an
                                > empty document is not optimal, so we have to aim for the middle.

                                As stated, I assumed that the default primes came from openssl, based
                                on the smtpd_tls_dh1024_param_file description in postconf(5). While
                                reading 'using the exact same parameter sets as distributed with other
                                TLS packages', I was assuming 'other TLS packages' to be other
                                (non-postfix, non-SMTP) software packages also using openssl.

                                After another re-read of the forward secrecy document (and from your
                                reply), I now found the part that states that the default primes are
                                postfix builtins. I missed this link.

                                So it doesn't have to be more technical or advanced. There were some
                                connections between dots missing in the higher level picture.

                                Tom
                                -----BEGIN PGP SIGNATURE-----
                                Version: GnuPG v1.4.14 (GNU/Linux)
                                Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

                                iQIcBAEBCAAGBQJSuHsrAAoJEJPfMZ19VO/1MY0P/RkJMxLYu77l8QVfQjuwQdk1
                                4xgMXiyR0IC8tSKFuulwX/sl+YoFcv2wkjupx0ZwTkVg32feccAUgnzy3wVfe3UM
                                Di5sxIdNq7M2MOb/O3nuoGkKiFDTtd/PXpInI6iLtKL9ADKXPwsbikQda1BEbV++
                                lO9BsVA1sJsAJOl40nOvx639cFQCEoLyAkuIgk6dZ//7sn1jmIFpYnZhkFvPo2rT
                                Y+3xwGtK+kz2E/b2uutkCO203iCf6hSkyV/jSF2rHl9L/iOkH2ohwt3ICrlH3r38
                                9Q3TUeMkJzWrHC1ME+LHA5bPhmKdtFsPywZHCWEMK/91U1EQSw8MI6JLHwiC9SZQ
                                JspWkm2JroIrkHl1mKHWi3IazI2hRTgjhmGwkaHy8+m3Cvkq5u9W8jEIBQ045luF
                                gKnCQdaDnfA0htg1dGmvpFItQeddraG+7DcXFDKtPny/mo3oTfAoSgiO3dKIjEDm
                                NihRXgJAtfJRXZG+vLGW0G/+h1DHT5u+l0l9W+TntJi9F2gBk1L6Lz+RSH9Jg5Cc
                                WBAvu2FH1HpoiTNKfdJu3Oi8P0PaSIbnwtODWZ0VVaRVT+YQgGkgjyMcMsvJkEF7
                                WknGNWBGk5/2n5/x7E/yX1VIV0416ehZSom0C/eBUZxCWAiidZwrRB+hQrcqGJUU
                                UfgkVU/WR+i9bBSxByEa
                                =i2Yp
                                -----END PGP SIGNATURE-----
                              • Tom Hendrikx
                                ... Hash: SHA256 ... The text currently reads like: - - you need to generate the params files once - - for greater security, re-generate every now and then The
                                Message 15 of 29 , Dec 23, 2013
                                • 0 Attachment
                                  -----BEGIN PGP SIGNED MESSAGE-----
                                  Hash: SHA256

                                  On 23-12-13 18:40, Wietse Venema wrote:
                                  > Viktor Dukhovni:
                                  >> On Mon, Dec 23, 2013 at 05:49:40PM +0100, Tom Hendrikx wrote:
                                  >>
                                  >>>> I am still fixing it for clarity, but it should be accurate.
                                  >>>> Feedback is welcome.
                                  >>>>
                                  >>>
                                  >>> After reading, I'm having some questions.
                                  >>
                                  >> s/reading/skimming/ :-)
                                  >
                                  > In this section, the commands that compute the parameters PRECEDE
                                  > the text that says why one might want to do this.
                                  >

                                  The text currently reads like:
                                  - - you need to generate the params files once
                                  - - for greater security, re-generate every now and then

                                  The improved security that is gained in the first step is not obvious,
                                  which is why I went looking for the details on the params that Postfix
                                  uses when the settings are left untouched.

                                  You might want to make it clearer that providing customized params is
                                  more secure than using the builtins. After that, running a cronjob to
                                  refresh them is another improvement.

                                  Tom
                                  -----BEGIN PGP SIGNATURE-----
                                  Version: GnuPG v1.4.14 (GNU/Linux)
                                  Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

                                  iQIcBAEBCAAGBQJSuH0qAAoJEJPfMZ19VO/18wsQAIwzLUl26Q6+j43vXudQpEq2
                                  x8JUt/jjTcRz+PkurynM51YLlmikxzhwC3J/reUvp2zSvHojOAsbomDdp6NN72Km
                                  eJdvxSgxc5i05tcoPxtoUZ3aKZUHHFdQ/p/HtnG2zXiU77AWnBzPPBwaZd0qo0f0
                                  Ao22oL68qltuc23APMSYI78acwLFZO/X3Lky+UquyPiwn8qK1JkX3WtzOwsTiNX6
                                  Xv4taIxLSn6sje3DCyWv2lAX0mPTo6B9mKzi7zO1PyUtym/jBo/6WUbW9QxB8ZWC
                                  D3hRVkarDdUlWHPOHx1P3nkaA9aiZgy93rVCT0yrB14KS57GvGCBptjo36QHzsvP
                                  QUSPo79jjIL/Z3YE+g/HbonFMiHdP0vCioFVU8rgRBZXH1/UbdKHu7eJxxgR6Ggm
                                  GssbJkz3hx+JJNzXJcrPjlCrERn9cROKIY0gkE0shjMMcgUG41H9OGBR8GzEOYvm
                                  wUOoORAkzaJddeApRrEPGQqQcnlCRulbkQYk8UmnkxH+/P+YSHZqbMXFbxOZzW6Z
                                  +5ueiasIxlXA3+Dgmj0xlpOsWFRArFiJLBxfpvkE9Cl/ZhBV31t6DR09doCJznvn
                                  5fFS803QEiwVPuQc0OGg7xYJUG4iDv5gqRxZh27Zuzz2SF5zKxMzTYb7xBxcJCqf
                                  QGxvbqtkzTpKC1tE5wxv
                                  =bwAN
                                  -----END PGP SIGNATURE-----
                                • Wietse Venema
                                  ... Please check out the updated text at http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html#quick-start This clarifies what is/isn t optional
                                  Message 16 of 29 , Dec 23, 2013
                                  • 0 Attachment
                                    Tom Hendrikx:
                                    > So it doesn't have to be more technical or advanced. There were some
                                    > connections between dots missing in the higher level picture.

                                    Please check out the updated text at
                                    http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html#quick-start

                                    This clarifies what is/isn't optional and why one might want to
                                    make some change. Only those who want the gory details should
                                    have to consume the entire document.

                                    Wietse
                                  • Andreas Schulze
                                    ... I read up to the bottom. I find the Untrusted/Trusted/Verified explanation very usefull. But I m still unsure about what an SMTP client could do to change
                                    Message 17 of 29 , Dec 23, 2013
                                    • 0 Attachment
                                      Am 23.12.2013 13:13 schrieb Wietse Venema:
                                      > Please check out the updated text at
                                      > http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html#quick-start
                                      >
                                      > This clarifies what is/isn't optional and why one might want to
                                      > make some change. Only those who want the gory details should
                                      > have to consume the entire document.
                                      I read up to the bottom. I find the Untrusted/Trusted/Verified explanation
                                      very usefull. But I'm still unsure about what an SMTP client could do
                                      to change a remote servers state from Trusted to Verified.
                                      (or what's wrong on a server that is only Trusted but not Verified)

                                      Andreas
                                    • Wietse Venema
                                      ... The text says: Trusted (peer certificate signed by trusted CA, unverified peer name) Verified (peer certificate signed by trusted CA, verified peer name)
                                      Message 18 of 29 , Dec 23, 2013
                                      • 0 Attachment
                                        Andreas Schulze:
                                        > Am 23.12.2013 13:13 schrieb Wietse Venema:
                                        > > Please check out the updated text at
                                        > > http://www.porcupine.org/postfix-mirror/FORWARD_SECRECY_README.html#quick-start
                                        > >
                                        > > This clarifies what is/isn't optional and why one might want to
                                        > > make some change. Only those who want the gory details should
                                        > > have to consume the entire document.

                                        > I read up to the bottom. I find the Untrusted/Trusted/Verified
                                        > explanation very usefull. But I'm still unsure about what an SMTP
                                        > client could do to change a remote servers state from Trusted to
                                        > Verified.

                                        The text says:

                                        Trusted (peer certificate signed by trusted CA, unverified peer name)

                                        Verified (peer certificate signed by trusted CA, verified peer name)

                                        The difference is that the client verifies that the name(s) in the
                                        certificate match with the name of the host that the client wanted
                                        to connect to.

                                        TLS_README goes into the details of verification.

                                        > (or what's wrong on a server that is only Trusted but not Verified)

                                        You could be talking to the wrong server, some man in the middle,
                                        or anything else than the desired host.

                                        Wietse
                                      • Viktor Dukhovni
                                        ... Good. ... If you must-have MITM protection for a particular destination, configure in smtp_tls_policy_maps a suitable TLS security level that
                                        Message 19 of 29 , Dec 23, 2013
                                        • 0 Attachment
                                          On Mon, Dec 23, 2013 at 09:45:45PM +0100, Andreas Schulze wrote:

                                          > I read up to the bottom. I find the Untrusted/Trusted/Verified explanation
                                          > very useful.

                                          Good.

                                          > But I'm still unsure about what an SMTP client could do
                                          > to change a remote servers state from Trusted to Verified.

                                          If you must-have MITM protection for a particular destination,
                                          configure in smtp_tls_policy_maps a suitable TLS security level
                                          that unconditionally verifies the server, such as:

                                          - fingerprint
                                          - secure
                                          - dane-only (**)

                                          Or to authenticate all servers opportunistically via DANE TLSA records,
                                          set:

                                          smtp_tls_security_level = dane (*)

                                          > (or what's wrong on a server that is only Trusted but not Verified)

                                          If mail delivery proceeded anyway, nothing is wrong: Postfix was
                                          not configured to verify the server certificate. This is the norm,
                                          MX record indirection makes it impossible to verify SMTP servers
                                          without explicit policy entries or help from DNSSEC (hence all
                                          the work to implement DANE support in Postfix 2.11).

                                          If mail delivery did not proceed, then the server certificate did
                                          not contain any of the expected names.

                                          --
                                          Viktor.

                                          (*) Requires Postfix 2.11 on a platform with OpenSSL 1.0.0 or greater,
                                          with EC support not disabled by the vendor. Also requires minimal
                                          DNSSEC support in libresolv (the "DO" and "AD" bits must be
                                          implemented and the option RES_USE_DNSSEC must be defined).

                                          For actual security the MTA needs a DNSSEC validating caching
                                          nameserver on localhost.

                                          Systems with DNSSEC validated MX records and DNSSEC validated
                                          TLSA records for the MX hosts will be subject to mandatory
                                          TLS authentication. Other systems will be subject to
                                          opportunistic TLS.

                                          (**) As above, but secure TLSA RRs are required.
                                        • lists@rhsoft.net
                                          ... hopefully i do not get proven wrong here but: in the last few months i am about testing OpenSSL-Keys with RSA 3072 / SHA256 a far as i can see even old
                                          Message 20 of 29 , Dec 23, 2013
                                          • 0 Attachment
                                            Am 23.12.2013 16:09, schrieb Viktor Dukhovni:
                                            > On Tue, Dec 24, 2013 at 01:29:38AM +1100, nanotek wrote:
                                            >> Still, might be a good time to create my own CA and upgrade to 4096 bit
                                            >> keys/certificates
                                            >
                                            > You can deploy 4096-bit RSA key if it makes you feel more cool,
                                            > but there is little point in going beyond 2048-bit RSA at this
                                            > time. The further you stray away from current practice into the
                                            > land of "extreme" cryptography, the more likely you are to run into
                                            > interoperability problems, without any real security gains.
                                            >
                                            >> using SHA512 algorithms
                                            >
                                            > TLSv1 and TLSv1.2 does not support negotiation of digest algorithms.
                                            > Deploying digests beyond SHA1 will cause interoperability problems
                                            > with systems that don't yet support the SHA2 family

                                            hopefully i do not get proven wrong here but:

                                            in the last few months i am about testing OpenSSL-Keys with RSA 3072 / SHA256
                                            a far as i can see even old MSIE6 on Windows XP happily connects to a webserver
                                            which such a key - given that are you aware of systems / mailservers which would
                                            have a problem with it?

                                            my plans for 2014 originally are get a signed 3072 SHA 256 *wildcard* certificate
                                            for 2 years for use on several webservers as well as Postfix / Dovecot

                                            i am aware of the ironically domain below, but given that the NSA not only
                                            works on break into foreign systems but also protect US infracsturucture
                                            they may have a good reason to state 3072 Bit for AES128

                                            http://www.nsa.gov/business/programs/elliptic_curve.shtml
                                          • Voytek
                                            ... I use postfix (and dovecot) with self signed certificates, never had any issues, apart from initial accept? , use 587 and 143ssl, it just works, both k9
                                            Message 21 of 29 , Dec 23, 2013
                                            • 0 Attachment

                                              nanotek <nanotek@...> wrote:

                                              >I am receiving a "Certificate Error" when sending mail from K-9 on my
                                              >android. I do not receive any error on my PC client (Thunderbird).
                                              >
                                              >I only have a self-signed public certificate and private key configured
                                              >
                                              >for use by Postfix. Should I create my own Certificate Authority and
                                              >cat
                                              >its certificate into a .chn file with the Postfix server certificate
                                              >and
                                              >use this instead of the standalone Postfix cert?
                                              >
                                              >Or should I create my own CA and just make use of the:
                                              >
                                              >$smtpd_tls_CAfile
                                              >$smtpd_tls_CApath
                                              >
                                              >options in main.cf? Same result, I gather, via different means. But
                                              >will
                                              >it resolve this K-9 error? Thanks.
                                              >
                                              >--
                                              >syn.bsdbox.co

                                              I use postfix (and dovecot) with self signed certificates, never had any issues, apart from initial 'accept?' , use 587 and 143ssl, it just works, both k9 and kaiten.

                                              Though, recent upgrade of mail client, either k9 or k10, caused the need to re accept certificate.

                                              --
                                              Sent from Kaiten Mail. Please excuse my brevity.


                                              --
                                              Sent from Kaiten Mail. Please excuse my brevity.
                                            • Viktor Dukhovni
                                              ... Yes. Any OpenSSL based MTA, with OpenSSL older April 7 2010: OpenSSL_1_0_0-stable (first released as OpenSSL 1.0.0a): commit
                                              Message 22 of 29 , Dec 23, 2013
                                              • 0 Attachment
                                                On Tue, Dec 24, 2013 at 01:16:33AM +0100, lists@... wrote:

                                                > > Deploying digests beyond SHA1 will cause interoperability problems
                                                > > with systems that don't yet support the SHA2 family
                                                >
                                                > Are you aware of systems / mailservers which would have a
                                                > problem with it?

                                                Yes. Any OpenSSL based MTA, with OpenSSL older April 7 2010:

                                                OpenSSL_1_0_0-stable (first released as OpenSSL 1.0.0a):

                                                commit acc9938ba5aa32fc382399e9a8cbd3a0dea91b34
                                                Author: Dr. Stephen Henson <steve@...>
                                                Date: Wed Apr 7 13:18:30 2010 +0000

                                                Add SHA2 algorithms to SSL_library_init(). Although these aren't used
                                                directly by SSL/TLS SHA2 certificates are becoming more common and
                                                applications that only call SSL_library_init() and not
                                                OpenSSL_add_all_alrgorithms() will fail when verifying certificates.

                                                OpenSSL_0_9_8-stable (first released as OpenSSL 0.9.8o):

                                                commit bc06baca76534abc2048a3ac4d109b144da4b706
                                                Author: Dr. Stephen Henson <steve@...>
                                                Date: Wed Apr 7 13:19:48 2010 +0000

                                                Add SHA2 algorithms to SSL_library_init(). Although these aren't used
                                                directly by SSL/TLS SHA2 certificates are becoming more common and
                                                applications that only call SSL_library_init() and not
                                                OpenSSL_add_all_alrgorithms() will fail when verifying certificates.

                                                The symptom would be that your certificate chain is not verifiable,

                                                verify error:num=7:certificate signature failure

                                                which rather makes all those sha256 signatures pointless, since
                                                the whole certificate cannot be verified.

                                                > I am aware of the ironically domain below, but given that the NSA not only
                                                > works on break into foreign systems but also protect US infracsturucture
                                                > they may have a good reason to state 3072 Bit for AES128
                                                >
                                                > http://www.nsa.gov/business/programs/elliptic_curve.shtml

                                                The NIST (and/or NSA) recommended key sizes are for an ideal world
                                                without interoperability issues and implementation constraints.
                                                In the real world, you sometimes get better security from less
                                                ideal but more practical configurations.

                                                --
                                                Viktor.
                                              • lists@rhsoft.net
                                                ... thank you for that am i right that this does not break opportunistic TLS at a whole for such destinations? in that case i would still go with RSA 3072 /
                                                Message 23 of 29 , Dec 24, 2013
                                                • 0 Attachment
                                                  Am 24.12.2013 04:03, schrieb Viktor Dukhovni:
                                                  > On Tue, Dec 24, 2013 at 01:16:33AM +0100, lists@... wrote:
                                                  >>> Deploying digests beyond SHA1 will cause interoperability problems
                                                  >>> with systems that don't yet support the SHA2 family
                                                  >>
                                                  >> Are you aware of systems / mailservers which would have a
                                                  >> problem with it?
                                                  >
                                                  > Yes. Any OpenSSL based MTA, with OpenSSL older April 7 2010:
                                                  >
                                                  > OpenSSL_1_0_0-stable (first released as OpenSSL 1.0.0a):
                                                  > Date: Wed Apr 7 13:18:30 2010 +0000
                                                  > Add SHA2 algorithms to SSL_library_init(). Although these aren't used
                                                  > directly by SSL/TLS SHA2 certificates are becoming more common and
                                                  > applications that only call SSL_library_init() and not
                                                  > OpenSSL_add_all_alrgorithms() will fail when verifying certificates.
                                                  >
                                                  > OpenSSL_0_9_8-stable (first released as OpenSSL 0.9.8o):
                                                  > Date: Wed Apr 7 13:19:48 2010 +0000
                                                  >
                                                  > Add SHA2 algorithms to SSL_library_init(). Although these aren't used
                                                  > directly by SSL/TLS SHA2 certificates are becoming more common and
                                                  > applications that only call SSL_library_init() and not
                                                  > OpenSSL_add_all_alrgorithms() will fail when verifying certificates.
                                                  >
                                                  > The symptom would be that your certificate chain is not verifiable,
                                                  > verify error:num=7:certificate signature failure

                                                  thank you for that

                                                  am i right that this does not break opportunistic TLS at a whole for such destinations?
                                                  in that case i would still go with RSA 3072 / SHA256 for severar reasons

                                                  * recent distributions ship OpenSSL 1.0.0 or 1.0.1
                                                  * RHEL5: openssl-0.9.8e-26.el5_9.1 with backports

                                                  > which rather makes all those sha256 signatures pointless, since
                                                  > the whole certificate cannot be verified.

                                                  in that cases yes, but in context of a wildcard certificate also
                                                  used for webservers and internally TLS aware services on recent
                                                  machines the question is how far one needs to be behind

                                                  >> I am aware of the ironically domain below, but given that the NSA not only
                                                  >> works on break into foreign systems but also protect US infracsturucture
                                                  >> they may have a good reason to state 3072 Bit for AES128
                                                  >>
                                                  >> http://www.nsa.gov/business/programs/elliptic_curve.shtml
                                                  >
                                                  > The NIST (and/or NSA) recommended key sizes are for an ideal world
                                                  > without interoperability issues and implementation constraints.
                                                  > In the real world, you sometimes get better security from less
                                                  > ideal but more practical configurations.

                                                  well aware, but somewhere needs to be started technical
                                                  progress outside whitepapers..............
                                                • Viktor Dukhovni
                                                  ... With clients using OpenSSL, probably not. I can t say how other clients will react to certificates with unsupported digest agorithms. Perhaps in some
                                                  Message 24 of 29 , Dec 24, 2013
                                                  • 0 Attachment
                                                    On Tue, Dec 24, 2013 at 11:16:50AM +0100, lists@... wrote:

                                                    > > The symptom would be that your certificate chain is not verifiable,
                                                    > > verify error:num=7:certificate signature failure
                                                    >
                                                    > Thank you for that.
                                                    >
                                                    > Am I right that this does not break opportunistic TLS at a whole
                                                    > for such destinations?

                                                    With clients using OpenSSL, probably not. I can't say how other
                                                    clients will react to certificates with unsupported digest agorithms.
                                                    Perhaps in some cases they try to instantiate the digest algorithm
                                                    and fail to connect. You'd need to test with Microsoft Exchange
                                                    2003, various vendor appliances, ...

                                                    > In that case I would still go with RSA 3072 / SHA256 for severar reasons
                                                    >
                                                    > * recent distributions ship OpenSSL 1.0.0 or 1.0.1

                                                    Yes, but some servers continue to be used for a decade or more.

                                                    > * RHEL5: openssl-0.9.8e-26.el5_9.1 with backports

                                                    I don't know what RedHat backported to 0.9.8e, with 0.9.8 vendors
                                                    generally backported critical fixes only, you'd need to test whether
                                                    the SHA2 enablement in SSL was one of these backports.

                                                    --
                                                    Viktor.
                                                  • lists@rhsoft.net
                                                    ... thanks for feedback and understood maybe my position is somehow easier because the MX is a barracuda appliance and so there is only outgoing opportunistic
                                                    Message 25 of 29 , Dec 24, 2013
                                                    • 0 Attachment
                                                      Am 24.12.2013 17:33, schrieb Viktor Dukhovni:
                                                      > On Tue, Dec 24, 2013 at 11:16:50AM +0100, lists@... wrote:
                                                      >
                                                      >>> The symptom would be that your certificate chain is not verifiable,
                                                      >>> verify error:num=7:certificate signature failure
                                                      >>
                                                      >> Thank you for that.
                                                      >>
                                                      >> Am I right that this does not break opportunistic TLS at a whole
                                                      >> for such destinations?
                                                      >
                                                      > With clients using OpenSSL, probably not. I can't say how other
                                                      > clients will react to certificates with unsupported digest agorithms.
                                                      > Perhaps in some cases they try to instantiate the digest algorithm
                                                      > and fail to connect. You'd need to test with Microsoft Exchange
                                                      > 2003, various vendor appliances, ...

                                                      thanks for feedback and understood

                                                      maybe my position is somehow easier because the MX is a barracuda
                                                      appliance and so there is only outgoing opportunistic TLS

                                                      maybe a good idea to consider using the wildcard-certificate
                                                      with SHA2 for outgoing messages and order a 3072/SHA1 for the
                                                      MX and use the wildcard for all other services

                                                      at the same time i consider ignore TLS breakage for a minority because
                                                      i expect falling back to unencrypted but at the same time recent
                                                      systems talk to each other with state-of-the-art certificates

                                                      that's a really interesting topic at all....

                                                      >> In that case I would still go with RSA 3072 / SHA256 for severar reasons
                                                      >>
                                                      >> * recent distributions ship OpenSSL 1.0.0 or 1.0.1
                                                      >
                                                      > Yes, but some servers continue to be used for a decade or more.
                                                      >
                                                      >> * RHEL5: openssl-0.9.8e-26.el5_9.1 with backports
                                                      >
                                                      > I don't know what RedHat backported to 0.9.8e, with 0.9.8 vendors
                                                      > generally backported critical fixes only, you'd need to test whether
                                                      > the SHA2 enablement in SSL was one of these backports

                                                      i try to test this in 2014 before decide how the new SSL cert will look like
                                                    • Viktor Dukhovni
                                                      ... You don t need to, and SHOULD NOT, configure a client certificate for outbound Internet email. The only exception would be a dedicated transport for
                                                      Message 26 of 29 , Dec 24, 2013
                                                      • 0 Attachment
                                                        On Tue, Dec 24, 2013 at 05:45:21PM +0100, lists@... wrote:

                                                        > Maybe a good idea to consider using the wildcard-certificate
                                                        > with SHA2 for outgoing messages and order a 3072/SHA1 for the
                                                        > MX and use the wildcard for all other services

                                                        You don't need to, and SHOULD NOT, configure a client certificate
                                                        for outbound Internet email. The only exception would be a dedicated
                                                        transport for delivering mail to sites that accept mail only from
                                                        authorized (client certificate) authenticated clients.

                                                        Inbound, a free self-signed certificate will do just-fine for SMTP.
                                                        Probably, nobody is verifying your certificate. With DANE you can
                                                        make the self-signed certificate authentic. Purchasing SMTP certs
                                                        for SMTP is largely pointless (except when you have bilateral
                                                        arrangements with some sending domains).

                                                        --
                                                        Viktor.
                                                      • lists@rhsoft.net
                                                        ... *aahh* i removed the two config lines yet for me it looked logical that if i have the two params for smtpd_ and there are identical for smtp_ they should
                                                        Message 27 of 29 , Dec 24, 2013
                                                        • 0 Attachment
                                                          Am 24.12.2013 18:13, schrieb Viktor Dukhovni:
                                                          > On Tue, Dec 24, 2013 at 05:45:21PM +0100, lists@... wrote:
                                                          >
                                                          >> Maybe a good idea to consider using the wildcard-certificate
                                                          >> with SHA2 for outgoing messages and order a 3072/SHA1 for the
                                                          >> MX and use the wildcard for all other services
                                                          >
                                                          > You don't need to, and SHOULD NOT, configure a client certificate
                                                          > for outbound Internet email. The only exception would be a dedicated
                                                          > transport for delivering mail to sites that accept mail only from
                                                          > authorized (client certificate) authenticated clients.

                                                          *aahh* i removed the two config lines yet

                                                          for me it looked logical that if i have the two params for
                                                          smtpd_ and there are identical for smtp_ they should be both
                                                          used with the same cert

                                                          smtpd_tls_cert_file = /etc/postfix/certs/localhost.pem
                                                          smtpd_tls_key_file = /etc/postfix/certs/localhost.pem
                                                          smtp_tls_cert_file = /etc/postfix/certs/localhost.pem
                                                          smtp_tls_key_file = /etc/postfix/certs/localhost.pem

                                                          > Inbound, a free self-signed certificate will do just-fine for SMTP.
                                                          > Probably, nobody is verifying your certificate

                                                          except the same cerificate is used for https on the spamfirewall-appliance
                                                          which is the case, but that's not really a postfix topic, however, in that
                                                          case i still expect that if someone does not like the servers certificate
                                                          he falls back to unencrypted like postfix does
                                                        • Viktor Dukhovni
                                                          ... The roles of client and server in TLS are highly asymmetric. Don t confuse superficial resemblance with logic. :-) The documentation for the smtp_
                                                          Message 28 of 29 , Dec 24, 2013
                                                          • 0 Attachment
                                                            On Tue, Dec 24, 2013 at 06:36:08PM +0100, lists@... wrote:

                                                            > For me it looked logical that if I have the two params for
                                                            > smtpd_ and there are identical for smtp_ they should be both
                                                            > used with the same cert
                                                            >
                                                            > smtpd_tls_cert_file = /etc/postfix/certs/localhost.pem
                                                            > smtpd_tls_key_file = /etc/postfix/certs/localhost.pem
                                                            > smtp_tls_cert_file = /etc/postfix/certs/localhost.pem
                                                            > smtp_tls_key_file = /etc/postfix/certs/localhost.pem

                                                            The roles of client and server in TLS are highly asymmetric.
                                                            Don't confuse superficial resemblance with logic. :-)

                                                            The documentation for the "smtp_" certificate parameters explains
                                                            that these should generally be left unset.

                                                            > > Inbound, a free self-signed certificate will do just-fine for SMTP.
                                                            > > Probably, nobody is verifying your certificate
                                                            >
                                                            > Except the same cerificate is used for https on the spamfirewall-appliance

                                                            Certificates don't deploy themselves. You chose to configure a
                                                            single certificate for both services, you're free to configure
                                                            separate certificates.

                                                            --
                                                            Viktor.
                                                          • lists@rhsoft.net
                                                            ... you are right :-) ... yes, i managed most of the configurations by look at postconf outputs and by looking at the logs on testmachines ... no, only one
                                                            Message 29 of 29 , Dec 24, 2013
                                                            • 0 Attachment
                                                              Am 24.12.2013 19:13, schrieb Viktor Dukhovni:
                                                              > On Tue, Dec 24, 2013 at 06:36:08PM +0100, lists@... wrote:
                                                              >
                                                              >> For me it looked logical that if I have the two params for
                                                              >> smtpd_ and there are identical for smtp_ they should be both
                                                              >> used with the same cert
                                                              >>
                                                              >> smtpd_tls_cert_file = /etc/postfix/certs/localhost.pem
                                                              >> smtpd_tls_key_file = /etc/postfix/certs/localhost.pem
                                                              >> smtp_tls_cert_file = /etc/postfix/certs/localhost.pem
                                                              >> smtp_tls_key_file = /etc/postfix/certs/localhost.pem
                                                              >
                                                              > The roles of client and server in TLS are highly asymmetric.
                                                              > Don't confuse superficial resemblance with logic. :-)

                                                              you are right :-)

                                                              > The documentation for the "smtp_" certificate parameters explains
                                                              > that these should generally be left unset.

                                                              yes, i managed most of the configurations by look at "postconf" outputs
                                                              and by looking at the logs on testmachines

                                                              >>> Inbound, a free self-signed certificate will do just-fine for SMTP.
                                                              >>> Probably, nobody is verifying your certificate
                                                              >>
                                                              >> Except the same cerificate is used for https on the spamfirewall-appliance
                                                              >
                                                              > Certificates don't deploy themselves. You chose to configure a
                                                              > single certificate for both services, you're free to configure
                                                              > separate certificates

                                                              no, only one place to upload a certificate for the appliance
                                                              makes typically sense because you would not use different certs
                                                              for the same servername but in this bordercase maybe suboptimal
                                                              https://www.barracuda.com/products/spamandvirusfirewallvx
                                                            Your message has been successfully submitted and would be delivered to recipients shortly.