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

Re: postfix hardening - what can we do?

Expand Messages
  • Viktor Dukhovni
    ... What would be the point? You accept plaintext mail, but reject mail encrypted with algorithms vulnerable to a costly, but not infeasible brute-force
    Message 1 of 14 , Oct 2, 2013
    • 0 Attachment
      On Wed, Oct 02, 2013 at 07:38:42PM -0400, micah wrote:

      > I suppose there is no way to achieve some middle ground of doing
      > opportunistic encryption, but for those who are only talking with bad
      > protocols and ciphers (or clear-text) do a non-permanent failure with a
      > message about their bad protocol so at least some admin eventually may
      > see that information (perhaps when the user complains that their
      > messages are slow to be delivered).

      What would be the point? You accept plaintext mail, but reject
      mail encrypted with algorithms vulnerable to a costly, but not
      infeasible brute-force effort?

      > > > smtpd_tls_eecdh_grade = ultra
      > >
      > > Perhaps, though if the NIST curves are "cooked", it is not clear
      > > that 512 bits is better than 256, and if not, then 256 may well be
      > > enough. Here you need new non-suspect curves, and none are described
      > > in relevant RFCs or available in OpenSSL at this time.
      >
      > When you say 'Here you need new non-suspect curves' - do you mean with
      > using eecdh ciphers in general? If there is suspicion that they are
      > cooked, maybe these should be disabled?

      I don't have anything substantive to say on the topic of the NIST
      EC curves. All I know is that some people no longer trust them,
      apparently not because they know the curves have backdoors, but
      because they no longer trust the good faith of those who proposed
      the curve parameters. The magic PRNG seed constants that generate
      the "verifiably random" curve parameters remain a mystery. They
      could be simply random in the first place, or the SHA-1 digests of
      some (unpublished) inside joke, or the result of exhaustive
      brute-force search for desirably weak curves (based on mathematical
      results not known outside NSA).

      This said, I also see a great deal of over-reaction, with bogus
      rumours about deliberate weakening of AES-256 by NIST (false), or
      deliberate sabotage of SHA3 (I am confident also false).

      So it is far from clear whether:

      - The NIST curves are cooked and should be avoided

      - Prime EDH is weak as a result of NSA break-throughs and should
      be avoided.

      - RSA is weak as a result of NSA break-throughs and should be avoided.

      ...

      So, when security matters, use the strongest crypto available, but
      worry a lot more about end-point security, not the crypto. With SMTP,
      I do nothing other than perhaps implement DNSSEC + DANE.

      > >> What are some ways that we could improve the situation?
      > >
      > > You could disable SSLv3 in the SMTP client, and use only TLSv1,
      > > TLSv1.1 or TLSv1.2.
      >
      > Do you mean in the MUA, or in the 'smtp' configurations in postfix? If
      > the latter, what happens when you disable SSLv3 and connect to a remote
      > MTA to make a delivery and they do not support anything but SSLv3?

      In all SMTP clients, since SMTP servers almost universally support
      TLSv1. There are exceedingly few servers that don't. You'd end
      up sending in the clear to these. Disabling SSLv3 is not very
      useful yet, the benefits only become real when TLS extensions sent
      by the client allow servers to choose more secure parameters for
      EECDH or EDH, which is not possible yet due to API and protocol
      limitations. This said it is unlikely to cause any significant
      problems.

      > > Neither Postfix nor OpenSSL actually care about the size of the
      > > prime in "smtpd_tls_dh1024_param_file". You can make it 2048 bits,
      > > and likely get away with it. See recent thread on Exim TLS interop.
      > > YMMV, some clients may choke on 2048-bit EDH (though more typically
      > > these limited implementations are in are browsers, ... not MTAs).
      >
      > Interesting, what interoperability problems are there here? If you set
      > the smtpd_tls_dh1024_param_file to a 2048bit file, what happens when a
      > client chokes on this? Does it fall back to clear text, or a non-EDH
      > cipher, or does it cause a connection reset... or?

      Some clients don't implement EDH for primes larger than some limit,
      possibly as low as 1024 bits. Such issues are common in browsers,
      and perhaps MUAs, but very uncommon in MTAs. When the TLS handshake
      fails, the MTA behaviour is implementation dependent. Postfix (which
      does not have such limits) retries with plaintext, unless constrained
      by out-of-band policy (administrative or DANE).

      --
      Viktor.
    • micah
      ... No, both plaintext and bad crypto would either be soft rejected with message to give a delay annoyance. ... Thanks for the explanation. micah
      Message 2 of 14 , Oct 2, 2013
      • 0 Attachment
        Viktor Dukhovni <postfix-users@...> writes:

        > On Wed, Oct 02, 2013 at 07:38:42PM -0400, micah wrote:
        >
        >> I suppose there is no way to achieve some middle ground of doing
        >> opportunistic encryption, but for those who are only talking with bad
        >> protocols and ciphers (or clear-text) do a non-permanent failure with a
        >> message about their bad protocol so at least some admin eventually may
        >> see that information (perhaps when the user complains that their
        >> messages are slow to be delivered).
        >
        > What would be the point? You accept plaintext mail, but reject
        > mail encrypted with algorithms vulnerable to a costly, but not
        > infeasible brute-force effort?

        No, both plaintext and bad crypto would either be soft rejected with
        message to give a delay annoyance.

        >> > You could disable SSLv3 in the SMTP client, and use only TLSv1,
        >> > TLSv1.1 or TLSv1.2.
        >>
        >> Do you mean in the MUA, or in the 'smtp' configurations in postfix? If
        >> the latter, what happens when you disable SSLv3 and connect to a remote
        >> MTA to make a delivery and they do not support anything but SSLv3?
        >
        > In all SMTP clients, since SMTP servers almost universally support
        > TLSv1. There are exceedingly few servers that don't. You'd end
        > up sending in the clear to these. Disabling SSLv3 is not very
        > useful yet, the benefits only become real when TLS extensions sent
        > by the client allow servers to choose more secure parameters for
        > EECDH or EDH, which is not possible yet due to API and protocol
        > limitations. This said it is unlikely to cause any significant
        > problems.
        >
        >> > Neither Postfix nor OpenSSL actually care about the size of the
        >> > prime in "smtpd_tls_dh1024_param_file". You can make it 2048 bits,
        >> > and likely get away with it. See recent thread on Exim TLS interop.
        >> > YMMV, some clients may choke on 2048-bit EDH (though more typically
        >> > these limited implementations are in are browsers, ... not MTAs).
        >>
        >> Interesting, what interoperability problems are there here? If you set
        >> the smtpd_tls_dh1024_param_file to a 2048bit file, what happens when a
        >> client chokes on this? Does it fall back to clear text, or a non-EDH
        >> cipher, or does it cause a connection reset... or?
        >
        > Some clients don't implement EDH for primes larger than some limit,
        > possibly as low as 1024 bits. Such issues are common in browsers,
        > and perhaps MUAs, but very uncommon in MTAs. When the TLS handshake
        > fails, the MTA behaviour is implementation dependent. Postfix (which
        > does not have such limits) retries with plaintext, unless constrained
        > by out-of-band policy (administrative or DANE).

        Thanks for the explanation.

        micah
      • Viktor Dukhovni
        ... You d reject more than half of your input stream. TLS clients are last I checked in the minority by message volume. This is completely impractical. --
        Message 3 of 14 , Oct 3, 2013
        • 0 Attachment
          On Wed, Oct 02, 2013 at 09:51:52PM -0400, micah wrote:

          > > What would be the point? You accept plaintext mail, but reject
          > > mail encrypted with algorithms vulnerable to a costly, but not
          > > infeasible brute-force effort?
          >
          > No, both plaintext and bad crypto would either be soft rejected with
          > message to give a delay annoyance.

          You'd reject more than half of your input stream. TLS clients are
          last I checked in the minority by message volume. This is completely
          impractical.

          --
          Viktor.
        • micah
          ... Regarding tighter mandatory parameters on the submission port - any idea what these could reasonably be? For example, if I disable SSLv2/v3 am I going to
          Message 4 of 14 , Oct 3, 2013
          • 0 Attachment
            Viktor Dukhovni <postfix-users@...> writes:

            > On Wed, Oct 02, 2013 at 03:39:06PM -0400, Micah Anderson wrote:
            >
            >> From my understanding of the way postfix currently operates, there is no
            >> smtpd/stmp TLS setting that can be set that would provide a
            >> configuration that would result in a more 'hardened' configuration,
            >> without causing interoperability problems. If I am wrong, I'm very
            >> interested in knowing where.
            >
            > You get no benefit from hardening the Postfix SMTP server on port
            > 25 (tighter mandatory parameters on the submission port may work
            > for some). This has little to do with Postfix and everything to
            > do with the fact that SMTP servers accept messages from total
            > strangers (many of the clients don't support TLS at all).

            Regarding tighter mandatory parameters on the submission port - any idea
            what these could reasonably be? For example, if I disable SSLv2/v3 am I
            going to cut off Outlook users?

            It would be nice if we had a good survey of clients that are still out
            there.

            I looked at some of my logs and found the following from a small sample
            over the last day:

            # zgrep 'TLS connection' /var/log/postfix.log* |grep 'TLS connection'|awk '{print $12, $15}' |sort | uniq -c |sort -nr
            301849 TLSv1 DHE-RSA-AES256-SHA
            109117 TLSv1 AES128-SHA
            30032 TLSv1 RC4-SHA
            14446 SSLv3 DHE-RSA-AES256-SHA
            2532 TLSv1 AES256-SHA
            1552 TLSv1 DHE-RSA-AES128-SHA
            424 SSLv3 AES256-SHA
            178 SSLv3 DHE-RSA-AES128-SHA
            69 TLSv1 DES-CBC3-SHA
            26 SSLv3 AES128-SHA
            18 SSLv3 DES-CBC3-SHA
            17 SSLv3 RC4-SHA

            but...the way this works: the server gets offered a list of ciphersuites
            from the client, and then the server picks a ciphersuite, so without
            knowing how the server picks its ciphersuites from the client, these
            results are not clear. The client is expected to offer ciphersuites in
            preferred order (https://tools.ietf.org/html/rfc5246#page-41), so if the
            server just chooses the client's earliest-listed ciphersuite that the
            server supports, then you have this situation.

            So that leaves us with the unanswered question of what does that
            translate into for restricting those paramters on the server?

            On a slightly other subject, I know that the smtps port 465 has already
            been reallocated as a port number, because it is considered deprecated,
            but I dont understand why. Providing a TLS-wrapped, from the beginning,
            port is better than offering STARTTLS. The STARTTLS offering is easily
            stripped by a MiTM, and I know that clients are supposed to handle that,
            but this seems incredibly brittle and prone to errors or manipulation,
            or minor configuration mistakes. XMPP threw out the TLS-wrapped
            connection as well, but they recently have brought it back because of
            this very reason.
          • micah
            ... Ups, this machine is not yet on openssl1.0 yet, so these results are somewhat useless. I ll have to get better ones from a newer machine. micah
            Message 5 of 14 , Oct 3, 2013
            • 0 Attachment
              micah <micah@...> writes:

              > Viktor Dukhovni <postfix-users@...> writes:
              >
              >> On Wed, Oct 02, 2013 at 03:39:06PM -0400, Micah Anderson wrote:
              >>
              >>> From my understanding of the way postfix currently operates, there is no
              >>> smtpd/stmp TLS setting that can be set that would provide a
              >>> configuration that would result in a more 'hardened' configuration,
              >>> without causing interoperability problems. If I am wrong, I'm very
              >>> interested in knowing where.
              >>
              >> You get no benefit from hardening the Postfix SMTP server on port
              >> 25 (tighter mandatory parameters on the submission port may work
              >> for some). This has little to do with Postfix and everything to
              >> do with the fact that SMTP servers accept messages from total
              >> strangers (many of the clients don't support TLS at all).
              >
              > Regarding tighter mandatory parameters on the submission port - any idea
              > what these could reasonably be? For example, if I disable SSLv2/v3 am I
              > going to cut off Outlook users?
              >
              > It would be nice if we had a good survey of clients that are still out
              > there.
              >
              > I looked at some of my logs and found the following from a small sample
              > over the last day:
              >
              > # zgrep 'TLS connection' /var/log/postfix.log* |grep 'TLS connection'|awk '{print $12, $15}' |sort | uniq -c |sort -nr
              > 301849 TLSv1 DHE-RSA-AES256-SHA
              > 109117 TLSv1 AES128-SHA
              > 30032 TLSv1 RC4-SHA
              > 14446 SSLv3 DHE-RSA-AES256-SHA
              > 2532 TLSv1 AES256-SHA
              > 1552 TLSv1 DHE-RSA-AES128-SHA
              > 424 SSLv3 AES256-SHA
              > 178 SSLv3 DHE-RSA-AES128-SHA
              > 69 TLSv1 DES-CBC3-SHA
              > 26 SSLv3 AES128-SHA
              > 18 SSLv3 DES-CBC3-SHA
              > 17 SSLv3 RC4-SHA

              Ups, this machine is not yet on openssl1.0 yet, so these results are
              somewhat useless. I'll have to get better ones from a newer machine.

              micah
            • Viktor Dukhovni
              ... With Postfix SSLv2 is off by default in the SMTP and LMTP clients. The Postfix SMTP server accepts SSLv2 by default. Other clients should likewise disable
              Message 6 of 14 , Oct 3, 2013
              • 0 Attachment
                On Thu, Oct 03, 2013 at 02:48:37PM -0400, micah wrote:

                > Regarding tighter mandatory parameters on the submission port - any idea
                > what these could reasonably be? For example, if I disable SSLv2/v3 am I
                > going to cut off Outlook users?

                With Postfix SSLv2 is off by default in the SMTP and LMTP clients.
                The Postfix SMTP server accepts SSLv2 by default. Other clients
                should likewise disable SSLv2. If you want, you can disable it in
                the server. This almost certainly makes no difference.

                > I looked at some of my logs and found the following from a small sample
                > over the last day:

                No SSLv2 as expected, but a good deal of SSLv3. You should break
                this down by submission vs. port 25 traffic. There is negligible
                benefit from disabling SSLv3 at this point, you gain TLSv1 extensions
                on the first client SSL HELLO, but at this time these don't yield
                substantive additional security.

                If you have opportunistic TLS enabled in both directions, you're
                ahead of the pack. Beyond that, secure your end-point systems,
                routers, firewalls, ...

                > but...the way this works: the server gets offered a list of ciphersuites
                > from the client, and then the server picks a ciphersuite, so without
                > knowing how the server picks its ciphersuites from the client, these
                > results are not clear.

                By default the server picks the client's most preferred cipher that
                is also available on the server. You can set "tls_preempt_cipherlist
                = yes" to have the server use its most preferred cipher supported
                by the client. This could break some fragile clients that offer
                ciphers (at a low preference) whose implementation is broken.

                > So that leaves us with the unanswered question of what does that
                > translate into for restricting those paramters on the server?

                Postfix defaults are chosen carefully, and you'll get very little
                mileage from changing them. You're likely spending time on the
                wrong problem. The real issues are not the crypto settings, rather:

                - Most SMTP clients don't do TLS and sent plaintext.

                - Even when TLS is used, it is typically unauthenticated.

                All the crypto algorithm issues pale in comparison. Therefore, if
                you want more secure SMTP, migrate to DNSSEC and publish TLSA RRs.
                Then wait for the world to migrate to DANE-capable SMTP clients.
                Postfix is leading the pack, Exim will likely be a year behind, and
                perhaps if we're lucky one of the larger cloud providers will adopt
                DANE at some point.

                > On a slightly other subject, I know that the smtps port 465 has already
                > been reallocated as a port number, because it is considered deprecated,
                > but I dont understand why.

                Because that's the standard. With "smtpd_tls_security_level =
                encrypt" set for the submission service, it really does not matter
                which protocol wraps which.

                --
                Viktor.
              • LuKreme
                ... No, it really isnÆt. IÆm not clear on what problem you ae trying to solve. You seem to want ômo securityö without any evidence that the current
                Message 7 of 14 , Oct 4, 2013
                • 0 Attachment
                  On 03 Oct 2013, at 12:48 , micah <micah@...> wrote:
                  > Providing a TLS-wrapped, from the beginning, port is better than offering STARTTLS.

                  No, it really isn’t.

                  I’m not clear on what problem you ae trying to solve. You seem to want “mo security” without any evidence that the current security is insufficient.

                  And rejecting plain text email acceptance? Well’s you might as well not have a mailserver.

                  --
                  "He is a self-made man and worships his creator." - John Bright
                • lists@rhsoft.net
                  ... keep in mind you are very new in context of mailservers http://www.postfix.org/CVE-2011-0411.html ... yes this is fixed, but without the plaintext start it
                  Message 8 of 14 , Oct 4, 2013
                  • 0 Attachment
                    Am 04.10.2013 13:43, schrieb LuKreme:
                    > On 03 Oct 2013, at 12:48 , micah <micah@...> wrote:
                    >> Providing a TLS-wrapped, from the beginning, port is better than offering STARTTLS.
                    >
                    > No, it really isn’t.
                    >
                    > I’m not clear on what problem you ae trying to solve. You seem to want “mo security” without
                    > any evidence that the current security is insufficient.

                    keep in mind you are very new in context of mailservers

                    http://www.postfix.org/CVE-2011-0411.html

                    >> SMTP over TLS uses the same TLS protocol that is also used to encrypt
                    >> traffic between web clients and web servers. But, there is a subtle
                    >> difference in the way TLS is used, and that makes this flaw possible

                    yes this is fixed, but without the plaintext start it would not have been possible

                    > And rejecting plain text email acceptance? Well’s you might as well not have a mailserver.

                    he is speaking about *submission* which is *always* authenticated and
                    there it is a good idea to enforce encryption if you rae in the position
                    to start with a new mailserver and need not to care about existing
                    client configurations which would break if you enforce it later
                  • micah
                    ... That is interesting. I tried to preempt the cipherlist and disable ECDHE to avoid the NIST curves, but couldn t get postfix to exclude that cipher using
                    Message 9 of 14 , Oct 4, 2013
                    • 0 Attachment
                      Viktor Dukhovni <postfix-users@...> writes:

                      >> but...the way this works: the server gets offered a list of ciphersuites
                      >> from the client, and then the server picks a ciphersuite, so without
                      >> knowing how the server picks its ciphersuites from the client, these
                      >> results are not clear.
                      >
                      > By default the server picks the client's most preferred cipher that
                      > is also available on the server. You can set "tls_preempt_cipherlist
                      > = yes" to have the server use its most preferred cipher supported
                      > by the client. This could break some fragile clients that offer
                      > ciphers (at a low preference) whose implementation is broken.

                      That is interesting. I tried to preempt the cipherlist and disable ECDHE
                      to avoid the NIST curves, but couldn't get postfix to exclude that
                      cipher using smtpd_tls_exclude_ciphers. It wasn't clear to me from
                      http://www.postfix.org/postconf.5.html#smtpd_tls_exclude_ciphers what
                      the correct syntax to use there is, I tried kxECDHE but that didn't work
                      either. Do you what format those are specified in?

                      micah
                    • Viktor Dukhovni
                      ... You using an interface that is too low level. To disable EECDH support set the EECDH grade to none smtpd_tls_eecdh_grade = none You don t need to
                      Message 10 of 14 , Oct 4, 2013
                      • 0 Attachment
                        On Fri, Oct 04, 2013 at 11:21:34AM -0400, micah wrote:

                        > > By default the server picks the client's most preferred cipher that
                        > > is also available on the server. You can set "tls_preempt_cipherlist
                        > > = yes" to have the server use its most preferred cipher supported
                        > > by the client. This could break some fragile clients that offer
                        > > ciphers (at a low preference) whose implementation is broken.
                        >
                        > That is interesting. I tried to preempt the cipherlist and disable ECDHE
                        > to avoid the NIST curves, but couldn't get postfix to exclude that
                        > cipher using smtpd_tls_exclude_ciphers.

                        You using an interface that is too low level. To disable EECDH support
                        set the EECDH grade to "none"

                        smtpd_tls_eecdh_grade = none

                        You don't need to change the preempt setting for this, disabled
                        algorithms are never selected.

                        > It wasn't clear to me from
                        > http://www.postfix.org/postconf.5.html#smtpd_tls_exclude_ciphers what
                        > the correct syntax to use there is, I tried kxECDHE but that didn't work
                        > either. Do you what format those are specified in?

                        I prefer to discourage explicit use of the low level OpenSSL cipher
                        settings. They are there for emergencies, but Postfix works hard
                        to avoid any need for users to set these.

                        As I mentioned before, there is really no rational basis for making
                        any changes in this space. We don't know which of the crypto
                        primitives are compromised if any. If you are using TLS, that's
                        much stronger than plaintext, the rest is largely immaterial.

                        --
                        Viktor.
                      Your message has been successfully submitted and would be delivered to recipients shortly.