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

Re: postfix hardening - what can we do?

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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.