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

Enforced TLS per MX

Expand Messages
  • Jan P. Kessler
    Dear list, we are trying to establish enforced TLS with a partner that hosts about 2000 recipient domains. All of these point to the same four MX records:
    Message 1 of 7 , Feb 22, 2013
      Dear list,

      we are trying to establish enforced TLS with a partner that hosts about
      2000 recipient domains. All of these point to the same four MX records:

      host[1-4].example.com

      As I did not want to specify all of these domains in our tls_policy
      file, I wanted to ask if there is any option to enforce TLS by those MX
      addresses.

      I already tried to set up a new instance with the setting
      "smtp_tls_security_level=encrypt" at port 26. On the main instance I
      have set up a restriction that redirects all mails to the partner's MX
      by the following configuration:

      main.cf:
      ----------
      check_recipient_mx_access=pcre:$data_directory/TLSMX.pcre

      $data_directory/TLSMX.pcre:
      -----------------------------------------
      /^host[1-4]\.example.com$/ FILTER smtp:[localhost]:26

      Unfortunately this does not work as expected for multi-recipient mails,
      because the FILTER action affects all recipients (even those to other MX
      destinations):

      recipient1@... --> OK
      recipient2@... --> Fails, because the MX for example.net
      does not offer TLS

      So: Does anybody see a chance to enforce TLS with our partner without
      the requirement to configure all of their recipient domains in the
      tls_policy file?

      Best regards, Jan
    • Wietse Venema
      ... Surely, the policy table is indexed by MX hostname as well as recipient domain. Wietse
      Message 2 of 7 , Feb 22, 2013
        Jan P. Kessler:
        > Dear list,
        >
        > we are trying to establish enforced TLS with a partner that hosts about
        > 2000 recipient domains. All of these point to the same four MX records:
        >
        > host[1-4].example.com
        >
        > As I did not want to specify all of these domains in our tls_policy
        > file, I wanted to ask if there is any option to enforce TLS by those MX
        > addresses.

        Surely, the policy table is indexed by MX hostname as well as
        recipient domain.

        Wietse
      • Viktor Dukhovni
        ... No, it is not. Only the nexthop domain is used since the MX host is derived from unauthenicated MX lookups and is trivially subject to MITM attacks. Just
        Message 3 of 7 , Feb 22, 2013
          On Fri, Feb 22, 2013 at 08:48:31AM -0500, Wietse Venema wrote:

          > > We are trying to establish enforced TLS with a partner that hosts about
          > > 2000 recipient domains. All of these point to the same four MX records:
          > >
          > > host[1-4].example.com
          > >
          > > As I did not want to specify all of these domains in our tls_policy
          > > file, I wanted to ask if there is any option to enforce TLS by those MX
          > > addresses.
          >
          > Surely, the policy table is indexed by MX hostname as well as
          > recipient domain.

          No, it is not. Only the nexthop domain is used since the MX host
          is derived from unauthenicated MX lookups and is trivially subject
          to MITM attacks.

          Just enabling opportunistic TLS pratically guarantees that TLS
          will be used whenever the partner supports TLS, and there is no
          MITM attack. When there is an MITM attack, the attacker could spoof
          DNS MX replies and turn off TLS if we supported per-host policy.

          The only way to securely integrate MX lookups into TLS policy is
          to use DNSSEC. As mentioned in a previous post to this list, that
          code is already under development, and many pieces are in already
          in place.

          If the DNS for all the hosted domains is managed by a provider who
          has implemented DNSSEC for all the domains in question, the OP will
          eventually be able to set TLS policy based on the MX. Even better,
          (much more scalably) the policy can be based on RFC 6698 (DANE)
          records in DNS with no local policy at all.

          All of this will take a while to become widespread, as DNSSEC is
          still the exception, not the rule. The operational issues need to
          be worked out.

          I expect to complete DANE support for Postfix 2.11 some time in
          the next few months. My time is somewhat constrained, as is Wietse's
          so it will take a bit of time, but there is no rush...

          I only know of one domain with DNSSEC MX records and DANE records
          for their MX host, that's nlnetlabs.nl (the developers of unbound
          and nsd, which are my recommendations for recursive and authoritative
          name servers with DNSSEC support). Even they make it tricky to
          fully secure email with TLS, since their MX RRset includes 3rd party
          backup MX hosts which DO NOT have DNSSEC and DANE.

          $ drill -D mx nlnetlabs.nl; # Note the "ad" flag in the respose!
          ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 57956
          ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 5
          ;; QUESTION SECTION:
          ;; nlnetlabs.nl. IN MX

          ;; ANSWER SECTION:
          nlnetlabs.nl. 10200 IN MX 50 open.nlnetlabs.nl.
          nlnetlabs.nl. 10200 IN MX 100 omval.tednet.nl.
          nlnetlabs.nl. 10200 IN MX 150 xs4all.dacht.net.
          nlnetlabs.nl. 10200 IN RRSIG MX 8 2 10200 ...

          $ drill -D TLSA _25._tcp.open.nlnetlabs.nl
          ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 60823
          ;; flags: qr rd ra ad ; QUERY: 1, ANSWER: 4, AUTHORITY: 4, ADDITIONAL: 5
          ;; QUESTION SECTION:
          ;; _25._tcp.open.nlnetlabs.nl. IN TLSA

          ;; ANSWER SECTION:
          _25._tcp.open.nlnetlabs.nl. 10200 IN CNAME 3.1.1._dane.nlnetlabs.nl.
          _25._tcp.open.nlnetlabs.nl. 10200 IN RRSIG CNAME 8 5 10200 ...
          3.1.1._dane.nlnetlabs.nl. 10200 IN TLSA 3 1 1 0d1fcbd7...
          3.1.1._dane.nlnetlabs.nl. 10200 IN RRSIG TLSA 8 6 10200 ...


          $ drill -D TLSA _25._tcp.omval.tednet.nl; # Note lack of "ad" in this case!
          ;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 61315
          ;; flags: qr rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
          ;; QUESTION SECTION:
          ;; _25._tcp.omval.tednet.nl. IN TLSA

          ;; ANSWER SECTION:

          ;; AUTHORITY SECTION:
          tednet.nl. 18000 IN SOA omval.tednet.nl. ...

          --
          Viktor.
        • Wietse Venema
          ... I see. This was a property of the legacy tls-per-site table. Wietse
          Message 4 of 7 , Feb 22, 2013
            Viktor Dukhovni:
            > On Fri, Feb 22, 2013 at 08:48:31AM -0500, Wietse Venema wrote:
            >
            > > > We are trying to establish enforced TLS with a partner that hosts about
            > > > 2000 recipient domains. All of these point to the same four MX records:
            > > >
            > > > host[1-4].example.com
            > > >
            > > > As I did not want to specify all of these domains in our tls_policy
            > > > file, I wanted to ask if there is any option to enforce TLS by those MX
            > > > addresses.
            > >
            > > Surely, the policy table is indexed by MX hostname as well as
            > > recipient domain.
            >
            > No, it is not. Only the nexthop domain is used since the MX host

            I see. This was a property of the legacy tls-per-site table.

            Wietse
          • Viktor Dukhovni
            ... Yep, security is a pain. I did not want to provide a false sense of security with the new policy table. None of the fancy certificate verification is worth
            Message 5 of 7 , Feb 22, 2013
              On Fri, Feb 22, 2013 at 11:33:53AM -0500, Wietse Venema wrote:

              > Viktor Dukhovni:
              > > On Fri, Feb 22, 2013 at 08:48:31AM -0500, Wietse Venema wrote:
              > >
              > > > > We are trying to establish enforced TLS with a partner that hosts about
              > > > > 2000 recipient domains. All of these point to the same four MX records:
              > > > >
              > > > > host[1-4].example.com
              > > > >
              > > > > As I did not want to specify all of these domains in our tls_policy
              > > > > file, I wanted to ask if there is any option to enforce TLS by those MX
              > > > > addresses.
              > > >
              > > > Surely, the policy table is indexed by MX hostname as well as
              > > > recipient domain.
              > >
              > > No, it is not. Only the nexthop domain is used since the MX host
              >
              > I see. This was a property of the legacy tls-per-site table.

              Yep, security is a pain. I did not want to provide a false sense
              of security with the new policy table. None of the fancy certificate
              verification is worth much if it is trivially subverted with a
              forged DNS response. We will be able to meet user expectations
              once DNSSEC is more pervasive (5-10 years with a bit of luck,
              they will typically be running 2.11 or later by then too).

              --
              Viktor.
            • Jan P. Kessler
              ... So it would have the same quality as the encrypt action, no? Something between 0 and 100, that could be explicitly mentioned in the docs. Doesn t help
              Message 6 of 7 , Feb 27, 2013
                Am 22.02.2013 17:06, schrieb Viktor Dukhovni:
                > On Fri, Feb 22, 2013 at 08:48:31AM -0500, Wietse Venema wrote:
                >
                >>> We are trying to establish enforced TLS with a partner that hosts about
                >>> 2000 recipient domains. All of these point to the same four MX records:
                >>>
                >>> host[1-4].example.com
                >>>
                >>> As I did not want to specify all of these domains in our tls_policy
                >>> file, I wanted to ask if there is any option to enforce TLS by those MX
                >>> addresses.
                >> Surely, the policy table is indexed by MX hostname as well as
                >> recipient domain.
                > No, it is not. Only the nexthop domain is used since the MX host
                > is derived from unauthenicated MX lookups and is trivially subject
                > to MITM attacks.

                So it would have the same "quality" as the "encrypt" action, no?
                Something between 0 and 100, that could be explicitly mentioned in the
                docs. Doesn't help with a MITM but keeps out the firewall/provider guy
                with debug/snoop/tcpdump - and your idp of course :-(

                But I understand the point and agree with it although it doesn't make me
                very happy. We are replacing an interconnection between some companies
                with several 1000s of domains (actively used, frequently enhanced) via
                leased lines. This required (and unfortunately still requires) a
                database for domain exchange and some kind of 'administrative
                discipline' to keep it updated in time. My expectation is that DNSSEC
                will be globally used before the last point is going to function properly ;)
              • Viktor Dukhovni
                ... Yes. -- Viktor.
                Message 7 of 7 , Feb 27, 2013
                  On Thu, Feb 28, 2013 at 12:25:53AM +0100, Jan P. Kessler wrote:

                  > Am 22.02.2013 17:06, schrieb Viktor Dukhovni:
                  >
                  > > > Surely, the policy table is indexed by MX hostname as well as
                  > > > recipient domain.
                  > >
                  > > No, it is not. Only the nexthop domain is used since the MX host
                  > > is derived from unauthenicated MX lookups and is trivially subject
                  > > to MITM attacks.
                  >
                  > So it would have the same "quality" as the "encrypt" action, no?

                  Yes.

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