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

per domain TLS

Expand Messages
  • Vernon A. Fort
    We have a few companies that we need have ALL email traffic encrypted. We can no longer blindly trust the end user to not include sensitive information in
    Message 1 of 10 , Aug 24, 2010
      We have a few companies that we need have ALL email traffic encrypted.
      We can no longer 'blindly trust' the end user to not include sensitive
      information in email. A VPN would be a easier solution but its not an
      option at this point.

      So, the outbound appears to be simple:

      smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
      with
      domain.com encrypt
      .domain.com encrypt

      basically, if the email is destine for THIS (or these) domain(s),
      enforce encryption. If we cannot, immediately return the email.

      But how to i enforce email connections FROM specific sites (ip's) to be
      encrypted, i.e. reject_if_NOT_tls_connection?

      Vernon
    • Noel Jones
      ... http://www.postfix.org/postconf.5.html#reject_plaintext_session abbreviated example of selective usage: smtpd_sender_restrictions = check_client_access
      Message 2 of 10 , Aug 24, 2010
        On 8/24/2010 10:24 AM, Vernon A. Fort wrote:
        > We have a few companies that we need have ALL email traffic encrypted.
        > We can no longer 'blindly trust' the end user to not include sensitive
        > information in email. A VPN would be a easier solution but its not an
        > option at this point.
        >
        > So, the outbound appears to be simple:
        >
        > smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
        > with
        > domain.com encrypt
        > .domain.com encrypt
        >
        > basically, if the email is destine for THIS (or these) domain(s),
        > enforce encryption. If we cannot, immediately return the email.
        >
        > But how to i enforce email connections FROM specific sites (ip's) to be
        > encrypted, i.e. reject_if_NOT_tls_connection?
        >
        > Vernon
        >


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


        abbreviated example of selective usage:

        smtpd_sender_restrictions =
        check_client_access cidr:/path/force_tls


        # force_tls
        5.4.3.2/32 reject_plaintext_session




        -- Noel Jones
      • Victor Duchovni
        ... See however, http://www.postfix.org/TLS_README.html#client_tls_limits the responsibility to encrypt falls largely on the sender. I would encourage you to
        Message 3 of 10 , Aug 24, 2010
          On Tue, Aug 24, 2010 at 10:29:43AM -0500, Noel Jones wrote:

          > On 8/24/2010 10:24 AM, Vernon A. Fort wrote:
          >> We have a few companies that we need have ALL email traffic encrypted.
          >> We can no longer 'blindly trust' the end user to not include sensitive
          >> information in email. A VPN would be a easier solution but its not an
          >> option at this point.
          >>
          >> So, the outbound appears to be simple:
          >>
          >> smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
          >> with
          >> domain.com encrypt
          >> .domain.com encrypt
          >>
          >> basically, if the email is destine for THIS (or these) domain(s),
          >> enforce encryption. If we cannot, immediately return the email.
          >>
          >> But how to i enforce email connections FROM specific sites (ip's) to be
          >> encrypted, i.e. reject_if_NOT_tls_connection?
          >>
          >> Vernon
          >
          > http://www.postfix.org/postconf.5.html#reject_plaintext_session
          >
          > abbreviated example of selective usage:
          >
          > smtpd_sender_restrictions =
          > check_client_access cidr:/path/force_tls
          >
          > # force_tls
          > 5.4.3.2/32 reject_plaintext_session

          See however,

          http://www.postfix.org/TLS_README.html#client_tls_limits

          the responsibility to encrypt falls largely on the sender. I would
          encourage you to work with the peer organization to have them encrypt
          traffic to your domains. Tracking their sending IPs scales poorly.

          --
          Viktor.
        • Vernon A. Fort
          ... i agree Victor but I m approaching this from what I know and don t know perspective. I am evaluation IF postfix is the right solution so i haven t (at
          Message 4 of 10 , Aug 24, 2010
            On Tue, 2010-08-24 at 11:42 -0400, Victor Duchovni wrote:
            > On Tue, Aug 24, 2010 at 10:29:43AM -0500, Noel Jones wrote:
            >
            > > On 8/24/2010 10:24 AM, Vernon A. Fort wrote:
            > >> We have a few companies that we need have ALL email traffic encrypted.
            > >> We can no longer 'blindly trust' the end user to not include sensitive
            > >> information in email. A VPN would be a easier solution but its not an
            > >> option at this point.
            > >>
            > >> So, the outbound appears to be simple:
            > >>
            > >> smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
            > >> with
            > >> domain.com encrypt
            > >> .domain.com encrypt
            > >>
            > >> basically, if the email is destine for THIS (or these) domain(s),
            > >> enforce encryption. If we cannot, immediately return the email.
            > >>
            > >> But how to i enforce email connections FROM specific sites (ip's) to be
            > >> encrypted, i.e. reject_if_NOT_tls_connection?
            > >>
            > >> Vernon
            > >
            > > http://www.postfix.org/postconf.5.html#reject_plaintext_session
            > >
            > > abbreviated example of selective usage:
            > >
            > > smtpd_sender_restrictions =
            > > check_client_access cidr:/path/force_tls
            > >
            > > # force_tls
            > > 5.4.3.2/32 reject_plaintext_session
            >
            > See however,
            >
            > http://www.postfix.org/TLS_README.html#client_tls_limits
            >
            > the responsibility to encrypt falls largely on the sender. I would
            > encourage you to work with the peer organization to have them encrypt
            > traffic to your domains. Tracking their sending IPs scales poorly.
            >

            i agree Victor but I'm approaching this from what I know and don't know
            perspective. I am evaluation IF postfix is the right solution so i
            haven't (at this point) setup the configuration(s). These emails are in
            the medical/hippa regulations area so a simple check_box (so to speak)
            may not suffice for an auditor. I'm working with the other side to get
            this email encryption setup but before we commit to a specific solution,
            I want some type of verification that they ARE connecting with TLS. A
            keeping honest people honest kind of thing. The
            reject_plaintext_session is what i was looking for but your right, it
            may not scale very well. Especially if the sending domain has their
            email hosted and connection are from 20 different smtp hosts that keep
            changing.

            Vernon
          • Vernon A. Fort
            ... Thanks Noel - would this work with a domain configuration, like smtpd_sender_restrictions = check_client_access hash:/etc/postfix/force_tls # force_tls
            Message 5 of 10 , Aug 24, 2010
              On Tue, 2010-08-24 at 10:29 -0500, Noel Jones wrote:
              > On 8/24/2010 10:24 AM, Vernon A. Fort wrote:
              > > We have a few companies that we need have ALL email traffic encrypted.
              > > We can no longer 'blindly trust' the end user to not include sensitive
              > > information in email. A VPN would be a easier solution but its not an
              > > option at this point.
              > >
              > > So, the outbound appears to be simple:
              > >
              > > smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
              > > with
              > > domain.com encrypt
              > > .domain.com encrypt
              > >
              > > basically, if the email is destine for THIS (or these) domain(s),
              > > enforce encryption. If we cannot, immediately return the email.
              > >
              > > But how to i enforce email connections FROM specific sites (ip's) to be
              > > encrypted, i.e. reject_if_NOT_tls_connection?
              > >
              > > Vernon
              > >
              >
              >
              > http://www.postfix.org/postconf.5.html#reject_plaintext_session
              >
              >
              > abbreviated example of selective usage:
              >
              > smtpd_sender_restrictions =
              > check_client_access cidr:/path/force_tls
              >
              >
              > # force_tls
              > 5.4.3.2/32 reject_plaintext_session

              Thanks Noel - would this work with a domain configuration, like
              smtpd_sender_restrictions =
              check_client_access hash:/etc/postfix/force_tls

              # force_tls
              domain.com reject_plaintext_session

              Meaning I do NOT accept email from domain.com thats not encrypted. The
              cidr approach may be the best solution - just exploring my options.
              Again, just seeing if there is a way to ENSURE/VALIDATE the other side
              is doing what they said they would do.

              Vernon
            • Victor Duchovni
              ... The issues raised in the above URL are product neutral. All MTAs are subject to at least the limitations listed in TLS_README. Postfix is not subject to
              Message 6 of 10 , Aug 24, 2010
                On Tue, Aug 24, 2010 at 11:37:26AM -0500, Vernon A. Fort wrote:

                > > > # force_tls
                > > > 5.4.3.2/32 reject_plaintext_session
                > >
                > > See however,
                > >
                > > http://www.postfix.org/TLS_README.html#client_tls_limits
                > >
                > > the responsibility to encrypt falls largely on the sender. I would
                > > encourage you to work with the peer organization to have them encrypt
                > > traffic to your domains. Tracking their sending IPs scales poorly.
                > >
                >
                > I agree Victor but I'm approaching this from what I know and don't know
                > perspective. I am evaluation IF postfix is the right solution so I
                > haven't (at this point) setup the configuration(s).

                The issues raised in the above URL are product neutral. All MTAs are
                subject to at least the limitations listed in TLS_README. Postfix is not
                subject to further substantive limitations, but it does not escape logic.

                > These emails are in
                > the medical/hippa regulations area so a simple check_box (so to speak)
                > may not suffice for an auditor. I'm working with the other side to get
                > this email encryption setup but before we commit to a specific solution,
                > I want some type of verification that they ARE connecting with TLS.

                Your "Received:" headers and mail logs (if the TLS loglevel is 1 rather
                than 0) will provide an audit-trail of TLS use.

                > A keeping honest people honest kind of thing. The
                > reject_plaintext_session is what I was looking for but you're right, it
                > may not scale very well. Especially if the sending domain has their
                > email hosted and connection are from 20 different smtp hosts that keep
                > changing.

                It is not possible to ensure communications security at just one end of
                a connection. It may be possible to achieve greater regulatory compliance
                (legally satisfactory appearance of security).

                For the reasons explained in TLS_README, TLS policy is best left to
                sender.

                --
                Viktor.
              • Vernon A. Fort
                ... Concerning outbound email to a specific domain that i need encrypted, i use smtp_tls_policy_maps. I would like some level of verification that the remote
                Message 7 of 10 , Sep 2, 2010
                  On Tue, 2010-08-24 at 11:43 -0500, Vernon A. Fort wrote:
                  > On Tue, 2010-08-24 at 10:29 -0500, Noel Jones wrote:
                  > > On 8/24/2010 10:24 AM, Vernon A. Fort wrote:
                  > > > We have a few companies that we need have ALL email traffic encrypted.
                  > > > We can no longer 'blindly trust' the end user to not include sensitive
                  > > > information in email. A VPN would be a easier solution but its not an
                  > > > option at this point.
                  > > >
                  > > > So, the outbound appears to be simple:
                  > > >
                  > > > smtp_tls_policy_maps = hash:/etc/postfix/tls_policy
                  > > > with
                  > > > domain.com encrypt
                  > > > .domain.com encrypt
                  > > >
                  > > > basically, if the email is destine for THIS (or these) domain(s),
                  > > > enforce encryption. If we cannot, immediately return the email.
                  > > >
                  > > > But how to i enforce email connections FROM specific sites (ip's) to be
                  > > > encrypted, i.e. reject_if_NOT_tls_connection?
                  > > >
                  > > > Vernon
                  > > >
                  > >
                  > >
                  > > http://www.postfix.org/postconf.5.html#reject_plaintext_session
                  > >
                  > >
                  > > abbreviated example of selective usage:
                  > >
                  > > smtpd_sender_restrictions =
                  > > check_client_access cidr:/path/force_tls
                  > >
                  > >
                  > > # force_tls
                  > > 5.4.3.2/32 reject_plaintext_session
                  >
                  > Thanks Noel - would this work with a domain configuration, like
                  > smtpd_sender_restrictions =
                  > check_client_access hash:/etc/postfix/force_tls
                  >
                  > # force_tls
                  > domain.com reject_plaintext_session
                  >
                  > Meaning I do NOT accept email from domain.com thats not encrypted. The
                  > cidr approach may be the best solution - just exploring my options.
                  > Again, just seeing if there is a way to ENSURE/VALIDATE the other side
                  > is doing what they said they would do.


                  Concerning outbound email to a specific domain that i need encrypted, i
                  use smtp_tls_policy_maps. I would like some level of verification that
                  the remote server IS the server I think it is. I see the
                  smtp_tls_security_level as encrypt, fingerprint, verify or secure. What
                  would be the best overall solution.

                  If I do the fingerprint, do i MD5sum their public or private key?

                  Vernon
                • Victor Duchovni
                  ... You don t have their private key, you should use SHA-1, not MD5 and certificate fingerprints are computed via: openssl x509 -in .pem -noout -sha1
                  Message 8 of 10 , Sep 2, 2010
                    On Thu, Sep 02, 2010 at 12:41:47PM -0500, Vernon A. Fort wrote:

                    > Concerning outbound email to a specific domain that I need encrypted, I
                    > use smtp_tls_policy_maps. I would like some level of verification that
                    > the remote server IS the server I think it is. I see the
                    > smtp_tls_security_level as encrypt, fingerprint, verify or secure. What
                    > would be the best overall solution.
                    >
                    > If I do the fingerprint, do I MD5sum their public or private key?

                    You don't have their private key, you should use SHA-1, not MD5 and
                    certificate fingerprints are computed via:

                    openssl x509 -in <cert>.pem -noout -sha1 -fingerprint

                    Where <cert>.pem is the file containing the remote certificate in
                    PEM format. Don't forget to set:

                    smtp_tls_fingerprint_digest = sha1

                    The choice between "fingerprint" and "secure" depends on whether the
                    remote cert is self-signed and stable, or signed public CA and changes
                    each time it expires.

                    --
                    Viktor.
                  • Vernon A. Fort
                    ... OK - so i get them to send me their cert file - then create a fingerprint. Now, what kind of overhead does this cause. Meaning will our server request
                    Message 9 of 10 , Sep 2, 2010
                      On Thu, 2010-09-02 at 13:47 -0400, Victor Duchovni wrote:
                      > On Thu, Sep 02, 2010 at 12:41:47PM -0500, Vernon A. Fort wrote:
                      >
                      > > Concerning outbound email to a specific domain that I need encrypted, I
                      > > use smtp_tls_policy_maps. I would like some level of verification that
                      > > the remote server IS the server I think it is. I see the
                      > > smtp_tls_security_level as encrypt, fingerprint, verify or secure. What
                      > > would be the best overall solution.
                      > >
                      > > If I do the fingerprint, do I MD5sum their public or private key?
                      >
                      > You don't have their private key, you should use SHA-1, not MD5 and
                      > certificate fingerprints are computed via:
                      >
                      > openssl x509 -in <cert>.pem -noout -sha1 -fingerprint
                      >
                      > Where <cert>.pem is the file containing the remote certificate in
                      > PEM format. Don't forget to set:
                      >
                      > smtp_tls_fingerprint_digest = sha1
                      >
                      > The choice between "fingerprint" and "secure" depends on whether the
                      > remote cert is self-signed and stable, or signed public CA and changes
                      > each time it expires.
                      >

                      OK - so i get them to send me their cert file - then create a
                      fingerprint. Now, what kind of overhead does this cause. Meaning will
                      our server request THEIR cert (then do the match) on every mail
                      submission?

                      Also (dummy question), whats the 'brief' difference between MD5 and
                      sha1?

                      Vernon
                    • Victor Duchovni
                      ... The actual sending of the cert is not necessary, their server makes it available to anyone who connects. You do however need to coordinate the security
                      Message 10 of 10 , Sep 2, 2010
                        On Thu, Sep 02, 2010 at 01:30:24PM -0500, Vernon A. Fort wrote:

                        > > The choice between "fingerprint" and "secure" depends on whether the
                        > > remote cert is self-signed and stable, or signed public CA and changes
                        > > each time it expires.
                        > >
                        >
                        > OK - so i get them to send me their cert file - then create a
                        > fingerprint.

                        The actual sending of the cert is not necessary, their server makes it
                        available to anyone who connects. You do however need to coordinate the
                        security level with them, and get mutual agreement on the authentication
                        strategy.

                        For example, you can get the cert (chain) via:

                        $ openssl s_client -starttls smtp -showcerts -connect mail.example.com:25

                        > Now, what kind of overhead does this cause. Meaning will
                        > our server request THEIR cert (then do the match) on every mail
                        > submission?

                        This is part of the SSL handshake, even when you don't check the
                        certificate, unless both sides support and use anonymous ciphers.

                        > Also (dummy question), whats the 'brief' difference between MD5 and
                        > sha1?

                        MD5 is more obsolete than SHA-1.

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