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

Experimental TLS auth fallback code

Expand Messages
  • Viktor Dukhovni
    My github Postfix repo: https://github.com/vdukhovni/postfix has a tlsfallback branch, which extends Postfix with two new pairs (smtp and lmtp flavours) of
    Message 1 of 3 , Jul 14, 2014
    • 0 Attachment
      My github Postfix repo:

      https://github.com/vdukhovni/postfix

      has a "tlsfallback" branch, which extends Postfix with two new
      pairs (smtp and lmtp flavours) of parameters (postconf(5) documentation
      snippets below). I am soliciting feedback on the interface and
      any operational experience if anyone is willing to test the code
      on a live system. You can test just the "audit" feature if you
      wish, if audit-only "security" (log authentication failure and
      deliver anyway) is not your cup of tea.

      $ git clone https://github.com/vdukhovni/postfix.git
      $ cd postfix/postfix
      $ git checkout tlsfallback

      set shared=yes/no dynamimaps=yes/no to taste, tweak other compile-time
      options and build (see INSTALL file for details):

      $ make -f Makefile.init shared=yes dynamicmaps=yes \
      CCARGS="... -DUSE_TLS ..." \
      AUXLIBS="... -lssl -lcrypto ..." \
      AUXLIBS_CDB=... \
      AUXLIBS_PCRE=... \
      ... \
      makefiles
      $ make

      Install the new code:

      # make upgrade

      Even if running the code is too bleeding-edge, comments based on
      the documentation are welcome. Do you want/need the new features?
      Is the audit interface too complex (it errs on the side of flexibility,
      perhaps there should a handful of named templates whose definitions could
      be changed by the adventurous, but most users could use a standard setting?)

      Documentation snippets:
      -----------------------

      smtp_tls_fallback_level (default: empty)

      Optional fallback levels for authenticated TLS levels. Specify a
      white-space or comma-separate list of policy_level=fallback_level
      pairs. The policy_level must require authentication (be one of dane,
      dane-only, fingerprint, verify, secure). The fallback_level must be
      "encrypt" or "may". When an authenticated connection with a policy
      level equal to one of the specified values cannot be established,
      delivery will proceed at the fallback level if possible. A warning
      will be logged indicating the fallback reason. You can use
      smtp_tls_audit_template to record the TLS security status for each
      delivery.

      The TLS policy table can be used to specify a destination-specific
      fallback strategy via the "fallback" policy attribute. The value of
      the "fallback" attribute, if specified, must be "may", "encrypt" or
      "none". If not "none", this specifies the fallback level for the des-
      tination in question. If the attribute value is "none", fallback is
      suppressed for the destination even if enabled via a global setting of
      smtp_tls_fallback_level.

      Example:

      /etc/postfix/main.cf:
      # When authentication fails, log a warning and deliver anyway
      # over an unauthenticated TLS connection.
      #
      smtp_tls_fallback_level =
      dane=encrypt,
      dane-only=encrypt,
      fingerprint=encrypt,
      verify=encrypt,
      secure=encrypt
      indexed = ${default_database_type}:${config_directory}/
      smtp_tls_policy_maps = ${indexed}tls-policy

      /etc/postfix/tls-policy:
      # No fallback for example.com
      example.com secure fallback=none
      # For example.net tolerate cleartext fallback
      example.net dane fallback=may

      This feature is available in Postfix 2.12 and later.

      smtp_tls_audit_template (default: empty)

      Optional template for tls audit logging at the completion of each mes-
      sage data transfer. If empty (the default setting) no TLS audit log
      entries are generated.

      The following $name expansions are done on smtp_tls_audit_template:

      $relay The remote SMTP server.

      $level The effective TLS security level after any fallback.

      $policy
      The desired TLS security level before any fallback, undefined if
      no fallback took place.

      $auth The authentication level of the remote SMTP server. One of
      "Cleartext", "Anonymous", "Untrusted", "Trusted" or "Verified".

      $protocol
      The TLS protocol version, defined only when TLS is used.

      $cipher
      The TLS cipher name, defined only when TLS is used.

      $cert_digest
      The digest of the remote SMTP server's certificate, defined only
      when TLS is used and the remote server presented a certificate.
      The digest algorithm is that specified via smtp_tls_finger-
      print_digest.

      $spki_digest
      The digest of the remote SMTP server's public key (Subject Pub-
      lic Key Info or SPKI from X.509), defined only when TLS is used
      and the remote server presented a certificate. The digest algo-
      rithm is that specified via smtp_tls_fingerprint_digest.

      ${name?value}
      Expands to value when $name is non-empty.

      ${name:value}
      Expands to value when $name is empty.

      Example:

      /etc/postfix/main.cf:
      smtp_tls_audit_template =
      tlsaudit: relay=${relay}${auth?, auth=${auth}}${level?, level=${level}}${policy?, policy=${policy}}${protocol?, protocol=${protocol}}${cipher?, cipher=${cipher}}

      This feature is available in Postfix 2.12 and later.

      --
      Viktor.
    • Eray Aslan
      ... Nice. I am guessing the motivation is making dane easier to deploy, especially for early adaptors, by decreasing the fall out in case the receiver domain
      Message 2 of 3 , Jul 15, 2014
      • 0 Attachment
        On Tue, Jul 15, 2014 at 04:42:32AM +0000, Viktor Dukhovni wrote:
        > smtp_tls_fallback_level (default: empty)
        >
        > Optional fallback levels for authenticated TLS levels.

        Nice. I am guessing the motivation is making dane easier to deploy,
        especially for early adaptors, by decreasing the fall out in case the
        receiver domain makes a mistake in his/her settings. Thanks.

        > smtp_tls_audit_template (default: empty)
        >
        > Optional template for tls audit logging at the completion of each mes-
        > sage data transfer. If empty (the default setting) no TLS audit log
        > entries are generated.

        Flexibility is nice. Let's not lose it but my guess is having a/some
        predefined template(s) -none, low, high?- will make it easier to
        maintain. Otherwise, I am afraid it will just be copy and paste from
        some web page and parsing logs will be harder than it needs to be.
        There will be too many varations around to use a standart script.

        A general discussion for postfix logging might be in order as well.
        This parameter will set the expectations for (future?) log
        configuration.

        --
        Eray
      • Viktor Dukhovni
        ... Something like that, but potentially also useful with secure and especially fingerprint , where remote configuration changes make authentication
        Message 3 of 3 , Jul 15, 2014
        • 0 Attachment
          On Tue, Jul 15, 2014 at 07:17:47AM +0000, Eray Aslan wrote:

          > Nice. I am guessing the motivation is making dane easier to deploy,
          > especially for early adopters, by decreasing the fall out in case the
          > receiver domain makes a mistake in his/her settings. Thanks.

          Something like that, but potentially also useful with "secure" and
          especially "fingerprint", where remote configuration changes make
          authentication fragile.

          > > smtp_tls_audit_template (default: empty)
          > >
          > > Optional template for tls audit logging at the completion of each mes-
          > > sage data transfer. If empty (the default setting) no TLS audit log
          > > entries are generated.
          >
          > Flexibility is nice. Let's not lose it but my guess is having a/some
          > predefined template(s) -none, low, high?- will make it easier to
          > maintain. Otherwise, I am afraid it will just be copy and paste from
          > some web page and parsing logs will be harder than it needs to be.
          > There will be too many varations around to use a standart script.

          I mostly see two variants, one with spki digests, and one without.
          If you can suggest specific combinations, please do. I am not
          worried about parsers, all the logged fields are of the ", key=value"
          variety. The "tlsaudit:" prefix should perhaps be a fixed element of
          the tls audit log (when enabled).

          > A general discussion for postfix logging might be in order as well.
          > This parameter will set the expectations for (future?) log
          > configuration.

          There could be a lot more templates I guess, not sure whether this
          is worth the trouble. As for the TLS audit log, another option is
          perhaps to log this as part of the delivery-agent per-recipient
          log entry, but then it is repeated lots of times, and absent for
          recipients deferred by a non-final MX.

          The current log entry is written for any transaction which gets
          past EHLO/STARTTLS/AUTH to attempt to deliver an envelope. (XFORWARD,
          MAIL FROM, ...). There is no TLS audit logging when SMTP session
          setup fails.

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