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

Re: Anyone use this email server configuration ?

Expand Messages
  • Ansgar Wiechers
    ... Read again. Regards Ansgar Wiechers -- Abstractions save us time working, but they don t save us time learning. --Joel Spolsky
    Message 1 of 26 , Sep 2, 2013
      On 2013-09-02 Littlefield, Tyler wrote:
      > On 9/2/2013 9:35 AM, Bruce Markey wrote:
      >> The only way to "nsa proof" is to encrypt end to end with pgp.
      ^^^^^^^^^^^^^^^^^^^
      >> I run postfix with gpg-mailgate.
      >> All incoming mail is encrypted with that users public key as it
      >> comes in for any mail that is not already encrypted client side
      >> using pgp.
      >
      > This makes sense, but this still isn't secure. Even if you use TLS
      > from endpoint to endpoint, mail is usually sent through multiple
      > servers until it gets to that point. You can send mail through your
      > own server, but it can not be encrypted when you send it out to
      > another server, which pretty much breaks any concept of NSA-proof
      > email.

      Read again.

      Regards
      Ansgar Wiechers
      --
      "Abstractions save us time working, but they don't save us time learning."
      --Joel Spolsky
    • DTNX Postmaster
      ... He makes the wrong point, but is partly right; PGP encrypts the content of the message only, and not the metadata contained in the headers. And that
      Message 2 of 26 , Sep 2, 2013
        On Sep 2, 2013, at 17:43, Ansgar Wiechers <lists@...> wrote:

        > On 2013-09-02 Littlefield, Tyler wrote:
        >> On 9/2/2013 9:35 AM, Bruce Markey wrote:
        >>> The only way to "nsa proof" is to encrypt end to end with pgp.
        > ^^^^^^^^^^^^^^^^^^^
        >>> I run postfix with gpg-mailgate.
        >>> All incoming mail is encrypted with that users public key as it
        >>> comes in for any mail that is not already encrypted client side
        >>> using pgp.
        >>
        >> This makes sense, but this still isn't secure. Even if you use TLS
        >> from endpoint to endpoint, mail is usually sent through multiple
        >> servers until it gets to that point. You can send mail through your
        >> own server, but it can not be encrypted when you send it out to
        >> another server, which pretty much breaks any concept of NSA-proof
        >> email.
        >
        > Read again.

        He makes the wrong point, but is partly right; PGP encrypts the content
        of the message only, and not the metadata contained in the headers. And
        that metadata can show very interesting patterns, patterns that
        sometimes tell you more than the content of the messages themselves.

        Mvg,
        Joni
      • LuKreme
        ... Encrypting your hard drive is trivial, at least in OS X and, I hear, even in Windows. I suspect it s more difficult in linux/freebsd, but I bet not much
        Message 3 of 26 , Sep 2, 2013
          On 02 Sep 2013, at 07:10 , Littlefield, Tyler <tyler@...> wrote:
          > Second, you'll need to encrypt your harddrive, which I doubt this whole blog covers.

          Encrypting your hard drive is trivial, at least in OS X and, I hear, even in Windows. I suspect it's more difficult in linux/freebsd, but I bet not much more than trivial.

          --
          You could save people. You could get there in the nick of time. And
          something could snap its fingers and say, no , it has to be that way.
          Let me tell you how it has to be. This is how the legend goes. --Soul
          Music
        • LuKreme
          Top-posting this once. This is obnoxious. Stop it. ... -- For more than a thousand generations the Jedi were the guardians of peace and justice in the galaxy.
          Message 4 of 26 , Sep 2, 2013
            Top-posting this once.

            This is obnoxious. Stop it.

            On 02 Sep 2013, at 07:35 , Bruce Markey <bruce@...> wrote:
            >
            > -----BEGIN PGP PUBLIC KEY BLOCK-----
            > Version: GnuPG v1.4.12 (GNU/Linux)
            >
            > mQINBFIjp+0BEACohL2HkOtWdsFyR+PUltMawCIfXgo4JWYElCLKWSRdwy8H+z2/
            > PmwHS2YMsNB5GX+jbv0m3EMJlqCZBRKXISeczFKSj/2Fit7vgplrimdYDtvy3vIN
            > MpLObFyrB3CS81OuFDyxQV7SXt4pCcfnt7b9Vg2Y3XHB38jK9YEMyGp95JW6pY82
            > /OvGkEs3EDTpv5uS8rzlxSJQH0jWhw0Fxmh3bH248J6EXJswxw/wIl++3fGTwY9V
            > G+pHRTiXB5iQkE9HpkZtAdkIHVW9s2APNDpwCCJUxvP4TY0qbGaYWzAoSIPZQHXY
            > iWv+JTOBZ9boZREZggoxNwn7By3C9zQhB6SIr0P1vZ8RD0LYcWJ5+X34Vw7BVGzD
            > +KXduqQ7ILjA8y1Ns9UgGsQ3RxEWsMehFoCkBfLpeAopm6Xk0ktBn/YSdCrUwc1k
            > IAUd2KFUTJrW48rPzbZd03ogqoMM2QE94VWjI3RCoBgc4amWQDlxHLqsmO22qe13
            > FgObJQUNBv43zMgTvHkowxBCrlxvDYnHnh7GK4h3mn5WihsexAv1fMeTNAEWO5gt
            > ZO47dCpq/mlArFFnTnQIJsMf7wp6nub/H83ByQNCaBxXG82VEtkTGh2x3I1TENP7
            > zNhOTCK1BDVHWCjyx0Le53nVnRt6I/yBqFDxHFkNvo0NeQo28ovHghbPOQARAQAB
            > tDRCcnVjZSBNYXJrZXkgKFNlY3J5cHRpb24uY29tKSA8YnJ1Y2VAc2VjcnlwdGlv
            > bi5jb20+iQI4BBMBAgAiBQJSI6ftAhsDBgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIX
            > gAAKCRDIVcS4Lgc6WLfMD/9KXmF9KDUrQ9yRZ/YSsrppr1yZa+ykY9cnKBYsiS/U
            > RZdZL7UhYF+zThPPVFBJPTua9OHbL53Famy5IfDuNiTTiMre0RZer2f3Me0zJJvP
            > sxnqbAFsOlhMpznpUK7kISutfor+fu8KezI9v8gZB8OLUp+c1LNYFHa+ACnY16NM
            > VCtfwkU9et+JykgK0Xc3E8ff5zP4hWtNeKRAaRqUsyipFjsOjbaN4i0nO6edoz/4
            > Y0Euyolzz9llP7HBfTmg/oHLSAqprnGzw8hRtYiUFqZyHRFgPIi1BgUNTAg6czEU
            > PZcv0zxbdAFOeE21LtC0ElA9WCPPjltRcJsTvfOUkepd2v3fmY8uUKL3HHAg7FzX
            > KtlOx+w5svdyKgJEmFM3aYsZKVQvuFH0Jq7vbB5+BqFj8iq2Rj8guvcNwLOzIQF0
            > R/CNgTWDzmYNO03+bVqveBPnNlFL5MsGL7A2JwW7tesxvepnQUWv+a9qT7SU+TxB
            > n0ez9VY/4FlcQndoiraRu7Mt6HSvUM6SQFc07RrR/SINOrRVnkbY16On9fKSr7u1
            > Dfiqlk+6RjJg3GFJ6iOf3oHV3FQ1aw+X4oaDx4XclqOejp8J+HETSTh9soKGG1sR
            > CPs2eRfIfFjLn5TfkiWS0t4NovCEHgFbgo+XLuvHvzh/sTCyTMD9Jr6+KO/ZB/RH
            > PbkCDQRSI6ftARAA4/FeX0a1kCHYoRtp9TEzASTzplVddX8Tv3Ha7aigA71BBVB5
            > jGZj/bFg0XWOSjAZxpl27rqyGQTqomNnX11Nn1+RC0tle4uJnh97qs7ot4vJfzfO
            > S7GBxFHBTzd+EJnVFHeJJZTHsp51VqI9YFaNFDjms2TUTFQ54SOE0fE9/Q3///Hh
            > LqF8lJFmwVi/OMSxmyrf4Q9aDoo3QKL4zX3o2OP3m1F92ltMyphZTPYwamPwu765
            > 0nr6rDwYnEQeFSa3SmA1eUT+bKSkZ7TUm/OBJyt8RK+hjNou+epV5IsREcApe2Px
            > BWwNOVx7oYM8seM87QGFe1iXuD+qrlU1JUsoZDTqovVqE1lBxm7UzlcyH3AkJnbh
            > GTbt/DvGYOo1d4pYbtjbrgM3+kFckmgP/DYPJE9ukbbWwpFEiC5AMkPKiSNKqxd7
            > U7xgmnpM5nfBbYO3/sPAv6QZvJTtKdnWrN8aOU0iuyHx07JYY0WjYqjc6+0PD9zi
            > 5LAs86PqC984/wll8QyxntpnDuasm3gzsllU+or7CEZXtJnkGqHZY3t4PBszH0rF
            > 7QC5JHNHNI9YuwUfRKj93H04RhB9FOOUJJsV4PJSjlSEt4GjwPGWmzI2DgXXag0x
            > ZIrzcZ6YxKrQsj/vu/yh/1yUfHzKZnqpQhuoZqGn2RqDKurBz4f86z5HcsUAEQEA
            > AYkCHwQYAQIACQUCUiOn7QIbDAAKCRDIVcS4Lgc6WNLdD/46JABUVO2KnwrgErQV
            > idTfdGh0jQE5K4BiLCKTjXsNEHvaKilfbU6kW/3fb9GrNS/VmTMqn30zjw80Y4ga
            > 1j2i3vi8yUZhl65pxh+sIsPE25fBvFIR+mnI1s6sHkCEMSVKBuSe4XskxQV4hwCW
            > P7kh/W9jpCv1tGW681SqUFsCqvPHGnNJeX8vDugh+X9EJGst/EmRHcFumP8BcMiK
            > aoqbS3qQNGhA6UoZMY7CH9DysbcTG59ABAv24dq2fDuZdVIFEVsNGYPorA6QIeC9
            > el+MD+WtSlA2+g9a6cUp6UX1ba765B2rYJrtXqHxepJFw63KqJzRUdXZ9zs+XrXn
            > GmfCQ1fb3+4fPYqvObFDYQXr7EayacIOlu8ctbRQqCibvWX/ECJm5vpwWgfZPkJz
            > Ms5t9FJM7ShrUw8dW0TPD7IdUk92GnEj+ZiuQjOMbkunpcHH8fDT/fwYY44exmaS
            > oJPsGpoO+TtUFMcMDvYcaPBlxy9e4JWGxAp8pWPBtb5ZW7wFgRXHYBRLD+Pr/q3+
            > 5lcS7Mhy5lztq654s4d37nZfRMbnm46kvDk9zSvLERm+WK6maTWmTVMvqHNxvYot
            > UWhPgy6CzbAcz91UiGa6lL6ky1OE+ZUT41ZZu9BVCdNBYSo2K4aQY/PdMbzcQhzN
            > evN13R2qLKotuTlIA9Im7lJZqw==
            > =q1E0
            > -----END PGP PUBLIC KEY BLOCK-----

            --
            For more than a thousand generations the Jedi were the guardians of
            peace and justice in the galaxy. Before the dark times. Before the
            Empire.
          • lists@rhsoft.net
            ... and after that? I suspect it s more difficult in linux/freebsd, but I bet not much more than trivial it is trivial on *every* OS but it does help you
            Message 5 of 26 , Sep 2, 2013
              Am 02.09.2013 22:55, schrieb LuKreme:
              > On 02 Sep 2013, at 07:10 , Littlefield, Tyler <tyler@...> wrote:
              >> Second, you'll need to encrypt your harddrive, which I doubt this whole blog covers.
              >
              > Encrypting your hard drive is trivial, at least in OS X and, I hear, even in Windows.

              and after that?

              I suspect it's more difficult in linux/freebsd, but I bet not much more than trivial

              it is trivial on *every* OS
              but it does help you *nothing* in reality

              it does help you only if someone takes oyur hardware and is running
              in *any* other case the encrypted disk is unlocked and any intrusion
              has the same success as for an unencrypted devive

              so why do people insist claim encrypted drives gain any security if
              they are not talking about notebooks stolen in a cafe?
            • LuKreme
              ... I was making no point about the securing of mail, just about encrypting the hard drive. ... Um... no, that s not right. Encrypting drives is quite useful.
              Message 6 of 26 , Sep 2, 2013
                On 02 Sep 2013, at 15:02 , lists@... wrote:

                >
                >
                > Am 02.09.2013 22:55, schrieb LuKreme:
                >> On 02 Sep 2013, at 07:10 , Littlefield, Tyler <tyler@...> wrote:
                >>> Second, you'll need to encrypt your harddrive, which I doubt this whole blog covers.
                >>
                >> Encrypting your hard drive is trivial, at least in OS X and, I hear, even in Windows.
                >
                > and after that?

                I was making no point about the securing of mail, just about encrypting the hard drive.

                > it does help you *nothing* in reality

                Um... no, that's not right. Encrypting drives is quite useful.

                > it does help you only if someone takes oyur hardware and is running
                > in *any* other case the encrypted disk is unlocked and any intrusion
                > has the same success as for an unencrypted devive

                No, when I have my laptop the drive is encrypted until one of the users authorized to unencrypted the drive logs in, or enters their password to wake the machine from sleep.

                > so why do people insist claim encrypted drives gain any security if
                > they are not talking about notebooks stolen in a cafe?

                For servers? Encrypting the drive on a always-on server seems a bit pointless. Once the machine is up and running, the drive is, as you said, unencrypted. However, if someone comes in to seize the machines, they will have to power them off and then the contents of the drives are protected.

                --
                "I can't see the point in the theatre. All that sex and violence. I get
                enough of that at home. Apart from the sex, of course." - Baldrick -
                Sense and Senility
              • lists@rhsoft.net
                ... without *context* *nothing* is useful ... interesting argument on a *server list*
                Message 7 of 26 , Sep 2, 2013
                  Am 02.09.2013 23:13, schrieb LuKreme:
                  > On 02 Sep 2013, at 15:02 , lists@... wrote:
                  >
                  >> Am 02.09.2013 22:55, schrieb LuKreme:
                  >>> On 02 Sep 2013, at 07:10 , Littlefield, Tyler <tyler@...> wrote:
                  >>>> Second, you'll need to encrypt your harddrive, which I doubt this whole blog covers.
                  >>>
                  >>> Encrypting your hard drive is trivial, at least in OS X and, I hear, even in Windows.
                  >>
                  >> and after that?
                  >
                  > I was making no point about the securing of mail, just about encrypting the hard drive.
                  >
                  >> it does help you *nothing* in reality
                  >
                  > Um... no, that's not right. Encrypting drives is quite useful.

                  without *context* *nothing* is useful

                  >> so why do people insist claim encrypted drives gain any security if
                  >> they are not talking about notebooks stolen in a cafe?
                  >
                  > For servers? Encrypting the drive on a always-on server seems a bit pointless

                  interesting argument on a *server list*
                • DTNX Postmaster
                  ... Not true. For servers with redundant power supplies, one just swaps in a UPS one power lead at a time. For servers with a single PSU, you can splice in
                  Message 8 of 26 , Sep 3, 2013
                    On Sep 2, 2013, at 23:13, LuKreme <kremels@...> wrote:

                    > For servers? Encrypting the drive on a always-on server seems a bit pointless. Once the machine is up and running, the drive is, as you said, unencrypted. However, if someone comes in to seize the machines, they will have to power them off and then the contents of the drives are protected.

                    Not true. For servers with redundant power supplies, one just swaps in a UPS one power lead at a time. For servers with a single PSU, you can splice in power from a UPS, and still move the server without powering it down.

                    Once they have direct access, you are pretty much fooked. And when it concerned No Such Agency, you might be fooked regardless if you're targeted directly. So in terms of 'NSA proofing' your e-mail server, all you can do as a server administrator is what you should have been doing already.

                    Mvg,
                    Joni
                  • Ralf Hildebrandt
                    ... I finally got around reading this. I wonder if it should be more strict regaring the used ciphers (both in Postfix and Dovecot), given that it s for
                    Message 9 of 26 , Sep 11, 2013
                      * Frank Bonnet <frank.bonnet@...>:
                      > Hello
                      >
                      > Anyone has tested such server in real life ?
                      >
                      > http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/

                      I finally got around reading this.
                      I wonder if it should be more strict regaring the used ciphers (both
                      in Postfix and Dovecot), given that it's for self-hosting only.

                      --
                      [*] sys4 AG

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

                      Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
                      Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
                      Aufsichtsratsvorsitzender: Florian Kirstein
                    • Viktor Dukhovni
                      ... With opportunistic TLS, reducing the set of ciphers available always reduces security, since when the handshake fails mail is subsequently sent in the
                      Message 10 of 26 , Sep 11, 2013
                        On Wed, Sep 11, 2013 at 01:26:25PM +0200, Ralf Hildebrandt wrote:

                        > > Anyone has tested such server in real life ?
                        > >
                        > > http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/
                        >
                        > I finally got around reading this.
                        >
                        > I wonder if it should be more strict regaring the used ciphers (both
                        > in Postfix and Dovecot), given that it's for self-hosting only.

                        With opportunistic TLS, reducing the set of ciphers available always
                        reduces security, since when the handshake fails mail is subsequently
                        sent in the clear. The Postfix SMTP client and server cipherlists
                        are *ordered* sensibly, and with SSLv2 disabled (default), there
                        should be no downgrade attacks.

                        It only makes sense to restrict the cipherlist to a more secure
                        subset when TLS is mandatory. The default cipher grade for mandatory
                        TLS is "medium". The "medium" grade is essentially just 128-bit RC4:

                        AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1
                        ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5
                        IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1
                        IDEA-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5
                        RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5
                        ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
                        ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
                        ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1
                        ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1
                        RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
                        RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
                        RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5

                        so if not using RC4 is a requirement, raising the mandatory grade to
                        high can be tried with care, but the effect is not always necessarily for
                        the better:

                        $ posttls-finger -c -L summary gmail.com
                        posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)

                        $ posttls-finger -c -L summary -g high gmail.com
                        posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher AES128-SHA (128/128 bits)

                        So with "medium" you get RC4 with PFS, and with "high" you get
                        AES128 without PFS. Which is better, we don't know for sure.

                        On a related note, in the Postfix SMTP client, I'd like at some
                        point to disable not only SSLv2, but also SSLv3, leaving only TLSv1
                        and up enabled. This ensures that TLSv1 extensions are sent in
                        the SSL client HELO message. Extensions can signal the list of
                        supported EECDH curves, support for session tickets, ...

                        The right time for this would probably be after OpenSSL 1.0.2 is
                        released, because then with an appropriate small change to Postfix,
                        the best EECDH curve can be negotiated, rather than fixed by the
                        server.

                        SSLv3 is already disabled in Postfix 2.11 when the remote server
                        is authenticated via DNSSEC DANE TLSA records, because in this case
                        the Postfix SMTP client needs to send the SNI extension to the
                        server (just in case the right certificate is contingent on SNI).

                        --
                        Viktor.
                      • DTNX Postmaster
                        ... I was looking at this yesterday, and this already answers some of the questions I had, thanks Victor :-) The cry to drop RC4 as quick as possible seems to
                        Message 11 of 26 , Sep 11, 2013
                          On Sep 11, 2013, at 16:34, Viktor Dukhovni <postfix-users@...> wrote:

                          > On Wed, Sep 11, 2013 at 01:26:25PM +0200, Ralf Hildebrandt wrote:
                          >
                          >>> Anyone has tested such server in real life ?
                          >>>
                          >>> http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/
                          >>
                          >> I finally got around reading this.
                          >>
                          >> I wonder if it should be more strict regaring the used ciphers (both
                          >> in Postfix and Dovecot), given that it's for self-hosting only.
                          >
                          > With opportunistic TLS, reducing the set of ciphers available always
                          > reduces security, since when the handshake fails mail is subsequently
                          > sent in the clear. The Postfix SMTP client and server cipherlists
                          > are *ordered* sensibly, and with SSLv2 disabled (default), there
                          > should be no downgrade attacks.
                          >
                          > It only makes sense to restrict the cipherlist to a more secure
                          > subset when TLS is mandatory. The default cipher grade for mandatory
                          > TLS is "medium". The "medium" grade is essentially just 128-bit RC4:
                          >
                          > AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1
                          > ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5
                          > IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1
                          > IDEA-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5
                          > RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5
                          > ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1
                          > ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1
                          > ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1
                          > ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1
                          > RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1
                          > RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
                          > RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5
                          >
                          > so if not using RC4 is a requirement, raising the mandatory grade to
                          > high can be tried with care, but the effect is not always necessarily for
                          > the better:
                          >
                          > $ posttls-finger -c -L summary gmail.com
                          > posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
                          >
                          > $ posttls-finger -c -L summary -g high gmail.com
                          > posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher AES128-SHA (128/128 bits)
                          >
                          > So with "medium" you get RC4 with PFS, and with "high" you get
                          > AES128 without PFS. Which is better, we don't know for sure.
                          >
                          > On a related note, in the Postfix SMTP client, I'd like at some
                          > point to disable not only SSLv2, but also SSLv3, leaving only TLSv1
                          > and up enabled. This ensures that TLSv1 extensions are sent in
                          > the SSL client HELO message. Extensions can signal the list of
                          > supported EECDH curves, support for session tickets, ...
                          >
                          > The right time for this would probably be after OpenSSL 1.0.2 is
                          > released, because then with an appropriate small change to Postfix,
                          > the best EECDH curve can be negotiated, rather than fixed by the
                          > server.
                          >
                          > SSLv3 is already disabled in Postfix 2.11 when the remote server
                          > is authenticated via DNSSEC DANE TLSA records, because in this case
                          > the Postfix SMTP client needs to send the SNI extension to the
                          > server (just in case the right certificate is contingent on SNI).

                          I was looking at this yesterday, and this already answers some of the
                          questions I had, thanks Victor :-) The cry to drop RC4 as quick as
                          possible seems to be getting stronger again this week, but of course in
                          SMTP interop it's never that simple. And then there's the BEAST attack,
                          which RC4 seems to be immune to?

                          One could in theory disable only the MD5 based RC4 ciphers for now, as
                          they are not used by the ECDHE based options?

                          We did disable SSLv3 for incoming connections yesterday, as TLS
                          connection statistics over August suggest that they make up only 0,005%
                          of the total. Will see if that causes any trouble with the few big
                          senders that seem to be stuck on SSLv3/RC4-MD5. May do the same for
                          outgoing connections.

                          Google seems to be only major user of 'ECDHE-RSA-RC4-SHA' at the
                          moment, by the way, not seen that anywhere else. And the AES based
                          ciphers make up the vast majority of connections seen.

                          Mvg,
                          Joni
                        • Viktor Dukhovni
                          ... The BEAST, CRIME, ... attacks are HTTPS specific, and do not generally apply to other TLS applications, in particular they are not relevant to SMTP. ...
                          Message 12 of 26 , Sep 11, 2013
                            On Wed, Sep 11, 2013 at 04:57:01PM +0200, DTNX Postmaster wrote:

                            > > SSLv3 is already disabled in Postfix 2.11 when the remote server
                            > > is authenticated via DNSSEC DANE TLSA records, because in this case
                            > > the Postfix SMTP client needs to send the SNI extension to the
                            > > server (just in case the right certificate is contingent on SNI).
                            >
                            > I was looking at this yesterday, and this already answers some of the
                            > questions I had, thanks Victor :-) The cry to drop RC4 as quick as
                            > possible seems to be getting stronger again this week, but of course in
                            > SMTP interop it's never that simple. And then there's the BEAST attack,
                            > which RC4 seems to be immune to?

                            The BEAST, CRIME, ... attacks are HTTPS specific, and do not
                            generally apply to other TLS applications, in particular they are
                            not relevant to SMTP.

                            > One could in theory disable only the MD5 based RC4 ciphers for now, as
                            > they are not used by the ECDHE based options?

                            SMTP servers don't know whether the client is doing opportunistic
                            TLS or authenticating the server. They should generally allow all
                            ciphersuites on port 25 (they can if desired switch from client
                            cipher order to server cipher order). Shrinking the server cipherlist
                            increases the odds of plaintext re-transmission with little gain.
                            Port 25 TLS security is in the hands of the client. On 587, servers
                            can be more selective.

                            > We did disable SSLv3 for incoming connections yesterday, as TLS
                            > connection statistics over August suggest that they make up only 0,005%
                            > of the total.

                            This is counter-productive. You get TLSv1 whenever the client supports
                            it, so rejecting SSLv3 at the server does not improve security.

                            > May do the same for outgoing connections.

                            This is more reasonable, provided systems you send mail to all
                            support TLSv1 and up. What fraction of outbound handshakes end up
                            with SSLv3?

                            In a couple of years time, when OpenSSL 1.0.2 is out, and Postfix
                            2.12 or 2.13 ships, I think we can safely turn off SSLv3 by default
                            in the Postfix SMTP *client*. The rationale is improved EECDH
                            support (servers can offer more trust-worthy curves when clients
                            support them) and a negligible and diminishing set of servers that
                            only support SSLv3.

                            At this time, the only plausibly useful TLS extension for the client
                            to send is session ticket support, and this mostly breaks session
                            caching in Postfix SMTP servers other than the just released 2.10.2,
                            2.9.8, 2.8.16 and 2.7.15.

                            So it is premature to disable SSLv3. The Postfix default TLS
                            settings are chosen with care, most efforts to "improve" them
                            are counter-productive.

                            The only change justified by recent events is perhaps forcing the
                            non-export EDH prime to 2048-bits as described in recent threads.

                            --
                            Viktor.
                          • Viktor Dukhovni
                            ... The blog recommends at least one of smtp[d]_tls_loglevel = 2 , this is unwise except when debugging. -- Viktor.
                            Message 13 of 26 , Sep 11, 2013
                              On Wed, Sep 11, 2013 at 01:26:25PM +0200, Ralf Hildebrandt wrote:

                              > > Anyone has tested such server in real life ?
                              > >
                              > > http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/
                              >
                              > I finally got around reading this.
                              > I wonder if it should be more strict regaring the used ciphers (both
                              > in Postfix and Dovecot), given that it's for self-hosting only.

                              The blog recommends at least one of "smtp[d]_tls_loglevel = 2",
                              this is unwise except when debugging.

                              --
                              Viktor.
                            • DTNX Postmaster
                              ... Ah, I thought I had read that it affected other applications as well, must have misunderstood, thanks. ... It rejects the systems that only support SSLv3,
                              Message 14 of 26 , Sep 11, 2013
                                On Sep 11, 2013, at 17:24, Viktor Dukhovni <postfix-users@...> wrote:

                                > On Wed, Sep 11, 2013 at 04:57:01PM +0200, DTNX Postmaster wrote:
                                >
                                >>> SSLv3 is already disabled in Postfix 2.11 when the remote server
                                >>> is authenticated via DNSSEC DANE TLSA records, because in this case
                                >>> the Postfix SMTP client needs to send the SNI extension to the
                                >>> server (just in case the right certificate is contingent on SNI).
                                >>
                                >> I was looking at this yesterday, and this already answers some of the
                                >> questions I had, thanks Victor :-) The cry to drop RC4 as quick as
                                >> possible seems to be getting stronger again this week, but of course in
                                >> SMTP interop it's never that simple. And then there's the BEAST attack,
                                >> which RC4 seems to be immune to?
                                >
                                > The BEAST, CRIME, ... attacks are HTTPS specific, and do not
                                > generally apply to other TLS applications, in particular they are
                                > not relevant to SMTP.

                                Ah, I thought I had read that it affected other applications as well,
                                must have misunderstood, thanks.

                                >> One could in theory disable only the MD5 based RC4 ciphers for now, as
                                >> they are not used by the ECDHE based options?
                                >
                                > SMTP servers don't know whether the client is doing opportunistic
                                > TLS or authenticating the server. They should generally allow all
                                > ciphersuites on port 25 (they can if desired switch from client
                                > cipher order to server cipher order). Shrinking the server cipherlist
                                > increases the odds of plaintext re-transmission with little gain.
                                > Port 25 TLS security is in the hands of the client. On 587, servers
                                > can be more selective.
                                >
                                >> We did disable SSLv3 for incoming connections yesterday, as TLS
                                >> connection statistics over August suggest that they make up only 0,005%
                                >> of the total.
                                >
                                > This is counter-productive. You get TLSv1 whenever the client supports
                                > it, so rejecting SSLv3 at the server does not improve security.

                                It rejects the systems that only support SSLv3, does it not? Or am I
                                understanding it incorrectly?

                                The reasoning was that accepting SSLv3/RC4-MD5 connections from systems
                                for which that is apparently the maximum they can support, even today,
                                constitutes a false sense of security. It being the low-hanging fruit,
                                and the most likely to be brute-forcable by the Powers That Be, if they
                                indeed have that capability. And even if they don't, systems which have
                                that as the maximum would be more likely to have backdoors or
                                vulnerabilities that would allow for the recovery of private keys.

                                Also, I think it was like five servers that had this as their maximum,
                                in the entire month. Given those numbers, we figured we could run some
                                tests and see what happens with those rare connections.

                                It may simply turn out to be misguided paranoia, however ;-)

                                >> May do the same for outgoing connections.
                                >
                                > This is more reasonable, provided systems you send mail to all
                                > support TLSv1 and up. What fraction of outbound handshakes end up
                                > with SSLv3?

                                I'll have a look, I only checked for incoming connections yesterday.

                                > In a couple of years time, when OpenSSL 1.0.2 is out, and Postfix
                                > 2.12 or 2.13 ships, I think we can safely turn off SSLv3 by default
                                > in the Postfix SMTP *client*. The rationale is improved EECDH
                                > support (servers can offer more trust-worthy curves when clients
                                > support them) and a negligible and diminishing set of servers that
                                > only support SSLv3.
                                >
                                > At this time, the only plausibly useful TLS extension for the client
                                > to send is session ticket support, and this mostly breaks session
                                > caching in Postfix SMTP servers other than the just released 2.10.2,
                                > 2.9.8, 2.8.16 and 2.7.15.
                                >
                                > So it is premature to disable SSLv3. The Postfix default TLS
                                > settings are chosen with care, most efforts to "improve" them
                                > are counter-productive.

                                I am aware of this, and we generally do not override the defaults
                                unless it is to solve problems. Had to disable 'DES-CBC3-SHA' as a
                                cipher in the client because it was bugging out vs. an Exchange 2003
                                server that should be phased out before year's end, for example.

                                > The only change justified by recent events is perhaps forcing the
                                > non-export EDH prime to 2048-bits as described in recent threads.

                                That was the problem with certain versions of Exim, was it not?

                                Mvg,
                                Joni
                              • Viktor Dukhovni
                                ... Forcing the traffic to be sent clear-text is not an improvement. People also have a false sense of security about mail they send in the clear. Pedantry is
                                Message 15 of 26 , Sep 11, 2013
                                  On Wed, Sep 11, 2013 at 09:12:40PM +0200, DTNX Postmaster wrote:

                                  > > This is counter-productive. You get TLSv1 whenever the client supports
                                  > > it, so rejecting SSLv3 at the server does not improve security.
                                  >
                                  > It rejects the systems that only support SSLv3, does it not? Or am I
                                  > understanding it incorrectly?
                                  >
                                  > The reasoning was that accepting SSLv3/RC4-MD5 connections from systems
                                  > for which that is apparently the maximum they can support, even today,
                                  > constitutes a false sense of security. It being the low-hanging fruit,
                                  > and the most likely to be brute-forcable by the Powers That Be, if they
                                  > indeed have that capability. And even if they don't, systems which have
                                  > that as the maximum would be more likely to have backdoors or
                                  > vulnerabilities that would allow for the recovery of private keys.

                                  Forcing the traffic to be sent clear-text is not an improvement.
                                  People also have a false sense of security about mail they send in
                                  the clear. Pedantry is counter-productive in security. Think
                                  about the practical results of proposed policy changes.

                                  > Also, I think it was like five servers that had this as their maximum,
                                  > in the entire month. Given those numbers, we figured we could run some
                                  > tests and see what happens with those rare connections.

                                  There is little to gain by breaking TLS from those 5 servers unless
                                  they are spammers, and you would reject their traffic anyway.

                                  > > In a couple of years time, when OpenSSL 1.0.2 is out, and Postfix
                                  > > 2.12 or 2.13 ships, I think we can safely turn off SSLv3 by default
                                  > > in the Postfix SMTP *client*. The rationale is improved EECDH
                                  > > support (servers can offer more trust-worthy curves when clients
                                  > > support them) and a negligible and diminishing set of servers that
                                  > > only support SSLv3.
                                  > >
                                  > > At this time, the only plausibly useful TLS extension for the client
                                  > > to send is session ticket support, and this mostly breaks session
                                  > > caching in Postfix SMTP servers other than the just released 2.10.2,
                                  > > 2.9.8, 2.8.16 and 2.7.15.
                                  > >
                                  > > So it is premature to disable SSLv3. The Postfix default TLS
                                  > > settings are chosen with care, most efforts to "improve" them
                                  > > are counter-productive.
                                  >
                                  > I am aware of this, and we generally do not override the defaults
                                  > unless it is to solve problems. Had to disable 'DES-CBC3-SHA' as a
                                  > cipher in the client because it was bugging out vs. an Exchange 2003
                                  > server that should be phased out before year's end, for example.

                                  That's a very old problem! Historically the Microsoft systems with
                                  this problem selected RC4 in preference to 3DES. I am surprised
                                  to hear that the problem is still not fixed, and that the server
                                  selected 3DES.

                                  > > The only change justified by recent events is perhaps forcing the
                                  > > non-export EDH prime to 2048-bits as described in recent threads.
                                  >
                                  > That was the problem with certain versions of Exim, was it not?

                                  Yes, current Exim on Debian "squeeze" (6.0) or stale Exim (before
                                  4.80-3) on Debian "wheezy" (7.x). The road to hell is paved with
                                  good intentions. In this case one of the Debian maintainers wanted
                                  to "improve" Exim security, as a result of which a lot more mail
                                  was sent in the clear as Exim TLS stopped interoperating with most
                                  other MTAs.

                                  Avoid counter-productive knee-jerk designs. If you want better
                                  email security, consider deploying to DNSSEC and publishing DANE
                                  TLSA RRs. When you deploy Postfix 2.11, consider making "dane"
                                  the default client TLS security level:

                                  smtp_dns_support_level = dnssec
                                  smtp_tls_security_level = dane

                                  With DANE you take advantage of ECDSA self-signed certificates in
                                  parallel with RSA self-signed certificates. Clients that support
                                  EECDH and ECDSA will be able to authenticate your server via stronger
                                  high-performance public keys and DH groups.

                                  At some point in the not too distant future there will be specifications
                                  for new EC curves with TLS that are not tainted by the mystery
                                  seeds of the NIST curves, making use of these will require OpenSSL
                                  1.0.2 or later, so it will be some time before the state of the
                                  art moves beyond what is best-practice today. Stay tuned, but
                                  don't expect things to get much better very fast.

                                  --
                                  Viktor.
                                • DTNX Postmaster
                                  ... Outbound is an even smaller percentage of total TLS connections established in August; 0,0002%. Interestingly, they are both banks; one Dutch, and one
                                  Message 16 of 26 , Sep 11, 2013
                                    On Sep 11, 2013, at 17:24, Viktor Dukhovni <postfix-users@...> wrote:

                                    >> May do the same for outgoing connections.
                                    >
                                    > This is more reasonable, provided systems you send mail to all
                                    > support TLSv1 and up. What fraction of outbound handshakes end up
                                    > with SSLv3?

                                    Outbound is an even smaller percentage of total TLS connections established in August; 0,0002%. Interestingly, they are both banks; one Dutch, and one Swiss. Both using SSLv3 with AES256-SHA, wouldn't be surprised if that means they are using the same brand of security product.

                                    The odd thing is that both banks drop to RC4-MD5 when sending to us. I've seen this on another product that we support ourselves as well; the Postfix client negotiates a higher protocol level and better cipher for outgoing mail than the server does for incoming mail. There is probably a good reason for this, but it feels to me like they should support the same protocol and cipher level regardless of direction?

                                    Re-enabled SSLv3 for incoming connections again, by the way; turns out that about half of those incoming connections are from an outsourcing firm that handles payment notifications for, yes, another Dutch bank. Sigh ;-)

                                    Mvg,
                                    Joni
                                  • Viktor Dukhovni
                                    ... For many large organizations inbound and outbound email are handled by completely separate infrastructure. Inbound mail is often first received by various
                                    Message 17 of 26 , Sep 11, 2013
                                      On Wed, Sep 11, 2013 at 09:39:57PM +0200, DTNX Postmaster wrote:

                                      > > This is more reasonable, provided systems you send mail to all
                                      > > support TLSv1 and up. What fraction of outbound handshakes end up
                                      > > with SSLv3?
                                      >
                                      > Outbound is an even smaller percentage of total TLS connections
                                      > established in August; 0,0002%. Interestingly, they are both banks;
                                      > one Dutch, and one Swiss. Both using SSLv3 with AES256-SHA, wouldn't
                                      > be surprised if that means they are using the same brand of security
                                      > product.

                                      For many large organizations inbound and outbound email are handled
                                      by completely separate infrastructure. Inbound mail is often first
                                      received by various anti-spam appliances. Outbound mail often
                                      bypasses these, and for bulk transactional mail, may be handled by
                                      other appliances that handle deliverability tracking, ...

                                      > The odd thing is that both banks drop to RC4-MD5 when sending to
                                      > us. I've seen this on another product that we support ourselves as
                                      > well; the Postfix client negotiates a higher protocol level and
                                      > better cipher for outgoing mail than the server does for incoming
                                      > mail. There is probably a good reason for this, but it feels to me
                                      > like they should support the same protocol and cipher level regardless
                                      > of direction?

                                      I am not surprised.

                                      > Re-enabled SSLv3 for incoming connections again, by the way;
                                      > turns out that about half of those incoming connections are from
                                      > an outsourcing firm that handles payment notifications for, yes,
                                      > another Dutch bank. Sigh ;-)

                                      As I mentioned, at this time, deprecating SSLv3 is most likely
                                      counter-productive. I am hoping that in a couple of years it will
                                      be a practical default for the SMTP client only, where you can
                                      define exceptions for problem destinations via smtp_tls_policy_maps.

                                      A polite note to their postmaster linking to this thread may
                                      encourage them to start making plans to upgrade to inbound systems
                                      that can support TLSv1 and up (strictly speaking the STARTTLS EHLO
                                      response in SMTP promises support of TLS an IETF standard, not SSLv3).

                                      --
                                      Viktor.
                                    • DTNX Postmaster
                                      ... Aye, true. Change has been reversed. Misguided paranoia ;-) ... It is possible to install AES extensions on Windows 2003 servers and upgrade the encryption
                                      Message 18 of 26 , Sep 11, 2013
                                        On Sep 11, 2013, at 21:37, Viktor Dukhovni <postfix-users@...> wrote:

                                        > On Wed, Sep 11, 2013 at 09:12:40PM +0200, DTNX Postmaster wrote:
                                        >
                                        >> The reasoning was that accepting SSLv3/RC4-MD5 connections from systems
                                        >> for which that is apparently the maximum they can support, even today,
                                        >> constitutes a false sense of security. It being the low-hanging fruit,
                                        >> and the most likely to be brute-forcable by the Powers That Be, if they
                                        >> indeed have that capability. And even if they don't, systems which have
                                        >> that as the maximum would be more likely to have backdoors or
                                        >> vulnerabilities that would allow for the recovery of private keys.
                                        >
                                        > Forcing the traffic to be sent clear-text is not an improvement.
                                        > People also have a false sense of security about mail they send in
                                        > the clear. Pedantry is counter-productive in security. Think
                                        > about the practical results of proposed policy changes.
                                        >
                                        >> Also, I think it was like five servers that had this as their maximum,
                                        >> in the entire month. Given those numbers, we figured we could run some
                                        >> tests and see what happens with those rare connections.
                                        >
                                        > There is little to gain by breaking TLS from those 5 servers unless
                                        > they are spammers, and you would reject their traffic anyway.

                                        Aye, true. Change has been reversed. Misguided paranoia ;-)

                                        >> I am aware of this, and we generally do not override the defaults
                                        >> unless it is to solve problems. Had to disable 'DES-CBC3-SHA' as a
                                        >> cipher in the client because it was bugging out vs. an Exchange 2003
                                        >> server that should be phased out before year's end, for example.
                                        >
                                        > That's a very old problem! Historically the Microsoft systems with
                                        > this problem selected RC4 in preference to 3DES. I am surprised
                                        > to hear that the problem is still not fixed, and that the server
                                        > selected 3DES.

                                        It is possible to install AES extensions on Windows 2003 servers and
                                        upgrade the encryption support that way, but given that this server is
                                        the last Exchange 2003 server we have to support, on its way out, and
                                        Microsoft gives you a gazillion warnings, we decided that it was just
                                        not worth the hassle. Supposedly you can disable that particular cipher
                                        via registry settings, too, but that didn't work either.

                                        In other words, after spending two hours trying to figure out where it
                                        was going wrong, we decided that all parties involved would be better
                                        off speeding up migration to the new Exchange server instead.

                                        >>> The only change justified by recent events is perhaps forcing the
                                        >>> non-export EDH prime to 2048-bits as described in recent threads.
                                        >>
                                        >> That was the problem with certain versions of Exim, was it not?
                                        >
                                        > Yes, current Exim on Debian "squeeze" (6.0) or stale Exim (before
                                        > 4.80-3) on Debian "wheezy" (7.x). The road to hell is paved with
                                        > good intentions. In this case one of the Debian maintainers wanted
                                        > to "improve" Exim security, as a result of which a lot more mail
                                        > was sent in the clear as Exim TLS stopped interoperating with most
                                        > other MTAs.

                                        We generally love Debian, but sadly, these things are one of the
                                        drawbacks of using the distribution. They too are misguided at times,
                                        heh :-( We haven't seen the issue yet, though, so perhaps we'll stay
                                        lucky and be able to avoid the workaround for it.

                                        > Avoid counter-productive knee-jerk designs. If you want better
                                        > email security, consider deploying to DNSSEC and publishing DANE
                                        > TLSA RRs. When you deploy Postfix 2.11, consider making "dane"
                                        > the default client TLS security level:
                                        >
                                        > smtp_dns_support_level = dnssec
                                        > smtp_tls_security_level = dane
                                        >
                                        > With DANE you take advantage of ECDSA self-signed certificates in
                                        > parallel with RSA self-signed certificates. Clients that support
                                        > EECDH and ECDSA will be able to authenticate your server via stronger
                                        > high-performance public keys and DH groups.
                                        >
                                        > At some point in the not too distant future there will be specifications
                                        > for new EC curves with TLS that are not tainted by the mystery
                                        > seeds of the NIST curves, making use of these will require OpenSSL
                                        > 1.0.2 or later, so it will be some time before the state of the
                                        > art moves beyond what is best-practice today. Stay tuned, but
                                        > don't expect things to get much better very fast.

                                        I will keep it in mind. Thanks for the valuable feedback, Victor :-)

                                        Mvg,
                                        Joni
                                      • DTNX Postmaster
                                        ... Ahh, yes. It s the same IP address, but that could just as well be the firewall itself that fronts multiple devices. ... In our own case though this is
                                        Message 19 of 26 , Sep 11, 2013
                                          On Sep 11, 2013, at 21:52, Viktor Dukhovni <postfix-users@...> wrote:

                                          > On Wed, Sep 11, 2013 at 09:39:57PM +0200, DTNX Postmaster wrote:
                                          >
                                          >>> This is more reasonable, provided systems you send mail to all
                                          >>> support TLSv1 and up. What fraction of outbound handshakes end up
                                          >>> with SSLv3?
                                          >>
                                          >> Outbound is an even smaller percentage of total TLS connections
                                          >> established in August; 0,0002%. Interestingly, they are both banks;
                                          >> one Dutch, and one Swiss. Both using SSLv3 with AES256-SHA, wouldn't
                                          >> be surprised if that means they are using the same brand of security
                                          >> product.
                                          >
                                          > For many large organizations inbound and outbound email are handled
                                          > by completely separate infrastructure. Inbound mail is often first
                                          > received by various anti-spam appliances. Outbound mail often
                                          > bypasses these, and for bulk transactional mail, may be handled by
                                          > other appliances that handle deliverability tracking, ...

                                          Ahh, yes. It's the same IP address, but that could just as well be the
                                          firewall itself that fronts multiple devices.

                                          >> The odd thing is that both banks drop to RC4-MD5 when sending to
                                          >> us. I've seen this on another product that we support ourselves as
                                          >> well; the Postfix client negotiates a higher protocol level and
                                          >> better cipher for outgoing mail than the server does for incoming
                                          >> mail. There is probably a good reason for this, but it feels to me
                                          >> like they should support the same protocol and cipher level regardless
                                          >> of direction?
                                          >
                                          > I am not surprised.

                                          In our own case though this is with current software, a direct
                                          connection without firewall tomfoolery and whatnot. I shall see if
                                          their support department can explain it to me and satisfy my curiosity
                                          as to what causes the difference.

                                          >> Re-enabled SSLv3 for incoming connections again, by the way;
                                          >> turns out that about half of those incoming connections are from
                                          >> an outsourcing firm that handles payment notifications for, yes,
                                          >> another Dutch bank. Sigh ;-)
                                          >
                                          > As I mentioned, at this time, deprecating SSLv3 is most likely
                                          > counter-productive. I am hoping that in a couple of years it will
                                          > be a practical default for the SMTP client only, where you can
                                          > define exceptions for problem destinations via smtp_tls_policy_maps.
                                          >
                                          > A polite note to their postmaster linking to this thread may
                                          > encourage them to start making plans to upgrade to inbound systems
                                          > that can support TLSv1 and up (strictly speaking the STARTTLS EHLO
                                          > response in SMTP promises support of TLS an IETF standard, not SSLv3).

                                          Noted. In our experience however the postmaster account rarely works,
                                          and if it does you run into a mess of red tape where even the most
                                          simple change requires multiple signatures, several hours of consulting
                                          billed and whatnot.

                                          Mvg,
                                          Joni
                                        • Viktor Dukhovni
                                          ... One thing too keep in mind is that in many cases servers honour client cipher preferences. When your SMTP client connects to their server the cipher-suite
                                          Message 20 of 26 , Sep 11, 2013
                                            On Wed, Sep 11, 2013 at 10:03:52PM +0200, DTNX Postmaster wrote:

                                            > >> The odd thing is that both banks drop to RC4-MD5 when sending to
                                            > >> us. I've seen this on another product that we support ourselves as
                                            > >> well; the Postfix client negotiates a higher protocol level and
                                            > >> better cipher for outgoing mail than the server does for incoming
                                            > >> mail. There is probably a good reason for this, but it feels to me
                                            > >> like they should support the same protocol and cipher level regardless
                                            > >> of direction?
                                            > >
                                            > > I am not surprised.
                                            >
                                            > In our own case though this is with current software, a direct
                                            > connection without firewall tomfoolery and whatnot. I shall see if
                                            > their support department can explain it to me and satisfy my curiosity
                                            > as to what causes the difference.

                                            One thing too keep in mind is that in many cases servers honour
                                            client cipher preferences. When your SMTP client connects to their
                                            server the cipher-suite chosen is the highest on your preference
                                            list that they support. When their client connects to your server
                                            the cipher-suite chosen is the highest on their preference list
                                            that you support. The two cipher-suites need not be the same even
                                            with the same software on their side sending and receiving.

                                            http://www.postfix.org/postconf.5.html#tls_preempt_cipherlist

                                            --
                                            Viktor.
                                          • Ralf Hildebrandt
                                            ... On a low traffic server? -- [*] sys4 AG http://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München,
                                            Message 21 of 26 , Sep 12, 2013
                                              * Viktor Dukhovni <postfix-users@...>:
                                              > On Wed, Sep 11, 2013 at 01:26:25PM +0200, Ralf Hildebrandt wrote:
                                              >
                                              > > > Anyone has tested such server in real life ?
                                              > > >
                                              > > > http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/
                                              > >
                                              > > I finally got around reading this.
                                              > > I wonder if it should be more strict regaring the used ciphers (both
                                              > > in Postfix and Dovecot), given that it's for self-hosting only.
                                              >
                                              > The blog recommends at least one of "smtp[d]_tls_loglevel = 2",
                                              > this is unwise except when debugging.

                                              On a low traffic server?

                                              --
                                              [*] sys4 AG

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

                                              Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
                                              Vorstand: Patrick Ben Koetter, Axel von der Ohe, Marc Schiffbauer
                                              Aufsichtsratsvorsitzender: Florian Kirstein
                                            • Viktor Dukhovni
                                              ... Even on a low traffic server the voluminous TLS logging just obfuscates the useful content in the logs. -- Viktor.
                                              Message 22 of 26 , Sep 12, 2013
                                                On Thu, Sep 12, 2013 at 03:36:30PM +0200, Ralf Hildebrandt wrote:

                                                > > The blog recommends at least one of "smtp[d]_tls_loglevel = 2",
                                                > > this is unwise except when debugging.
                                                >
                                                > On a low traffic server?

                                                Even on a low traffic server the voluminous TLS logging just obfuscates
                                                the useful content in the logs.

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