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

Anyone use this email server configuration ?

Expand Messages
  • Frank Bonnet
    Hello Anyone has tested such server in real life ? http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ Thank you
    Message 1 of 26 , Sep 2, 2013
    • 0 Attachment
      Hello

      Anyone has tested such server in real life ?

      http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/

      Thank you
    • Littlefield, Tyler
      FWIW, I seen the url and stopped there. there is literally no way to NSA-proof your email for a number of reasons: First, email is sent cleartext. Even if you
      Message 2 of 26 , Sep 2, 2013
      • 0 Attachment
        FWIW, I seen the url and stopped there. there is literally no way to
        NSA-proof your email for a number of reasons:
        First, email is sent cleartext. Even if you authenticate to send and you
        authenticate to receive, it's going through servers cleartext. A tap
        before your server is all it would take.
        Second, you'll need to encrypt your harddrive, which I doubt this whole
        blog covers. Encrypting individual emails will not be enough.
        On 9/2/2013 9:06 AM, Frank Bonnet wrote:
        > Hello
        >
        > Anyone has tested such server in real life ?
        >
        > http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/
        >
        > Thank you
        >
        >


        --
        Take care,
        Ty
        http://tds-solutions.net
        He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.
        Sent from my Toaster (tm).
      • Bruce Markey
        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
        Message 3 of 26 , Sep 2, 2013
        • 0 Attachment
          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.

          Bruce.

          --
          Please use PGP, ENCRYPT everything.
          For information about acquiring a secryption.com account, email me.

          -----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-----
        • Littlefield, Tyler
          ... 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
          Message 4 of 26 , Sep 2, 2013
          • 0 Attachment
            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.
            > Bruce.
            >


            --
            Take care,
            Ty
            http://tds-solutions.net
            He that will not reason is a bigot; he that cannot reason is a fool; he that dares not reason is a slave.
            Sent from my Toaster (tm).
          • Ansgar Wiechers
            ... Read again. Regards Ansgar Wiechers -- Abstractions save us time working, but they don t save us time learning. --Joel Spolsky
            Message 5 of 26 , Sep 2, 2013
            • 0 Attachment
              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 6 of 26 , Sep 2, 2013
              • 0 Attachment
                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 7 of 26 , Sep 2, 2013
                • 0 Attachment
                  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 8 of 26 , Sep 2, 2013
                  • 0 Attachment
                    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 9 of 26 , Sep 2, 2013
                    • 0 Attachment
                      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 10 of 26 , Sep 2, 2013
                      • 0 Attachment
                        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 11 of 26 , Sep 2, 2013
                        • 0 Attachment
                          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 12 of 26 , Sep 3, 2013
                          • 0 Attachment
                            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 13 of 26 , Sep 11, 2013
                            • 0 Attachment
                              * 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 14 of 26 , Sep 11, 2013
                              • 0 Attachment
                                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 15 of 26 , Sep 11, 2013
                                • 0 Attachment
                                  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 16 of 26 , Sep 11, 2013
                                  • 0 Attachment
                                    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 17 of 26 , Sep 11, 2013
                                    • 0 Attachment
                                      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 18 of 26 , Sep 11, 2013
                                      • 0 Attachment
                                        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 19 of 26 , Sep 11, 2013
                                        • 0 Attachment
                                          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 20 of 26 , Sep 11, 2013
                                          • 0 Attachment
                                            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 21 of 26 , Sep 11, 2013
                                            • 0 Attachment
                                              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 22 of 26 , Sep 11, 2013
                                              • 0 Attachment
                                                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 23 of 26 , Sep 11, 2013
                                                • 0 Attachment
                                                  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 24 of 26 , Sep 11, 2013
                                                  • 0 Attachment
                                                    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 25 of 26 , Sep 12, 2013
                                                    • 0 Attachment
                                                      * 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 26 of 26 , Sep 12, 2013
                                                      • 0 Attachment
                                                        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.