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

Is there the opposite of $permit_tls_clientcerts available?

Expand Messages
  • micah
    For the purposes of better scaling things out, I would prefer to maintain a table of certificate fingerprints that I want to deny, rather than a table of
    Message 1 of 2 , Oct 10, 2013
    • 0 Attachment
      For the purposes of better scaling things out, I would prefer to
      maintain a table of certificate fingerprints that I want to deny, rather
      than a table of certificates that I want to allow. Such a table would
      need to be updated a small fraction of the time that an allow list would
      need to be updated, and would produce the same effect, but more
      efficiently.

      However, from what I can tell, postfix only has $permit_tls_clientcerts,
      and no $denied_tls_clientcerts. Because I will have a lot of churn with
      new certs being generated continually, I would rather have the
      opposite.

      Are there any options to do that?

      thanks,
      micah
    • Viktor Dukhovni
      ... You might think so, but you probably have not fully thought this through. ... It would generally not produce the same effect. Every client with some
      Message 2 of 2 , Oct 10, 2013
      • 0 Attachment
        On Thu, Oct 10, 2013 at 02:20:40PM -0400, micah wrote:

        > For the purposes of better scaling things out, I would prefer to
        > maintain a table of certificate fingerprints that I want to deny, rather
        > than a table of certificates that I want to allow.

        You might think so, but you probably have not fully thought this
        through.

        > Such a table would
        > need to be updated a small fraction of the time that an allow list would
        > need to be updated, and would produce the same effect, but more
        > efficiently.

        It would generally not produce the same effect. Every client with
        some random self-signed certificate would be allowed, not just the
        ones you issued. The only plausible way to make this work is with:

        http://wwwp.postfix.org/postconf.5.html#permit_tls_all_clientcerts
        http://wwwp.postfix.org/postconf.5.html#tls_append_default_CA

        where all trusted clients are issued from a small set of your own
        CAs, exclusively for the purpose of allowing SMTP client access,
        you have configured *only* these CAs in smtpd_tls_CAfile and
        set tls_append_default_CA=no. Then you can use:

        main.cf:
        indexed = ${default_database_type}:${config_directory}/
        tls_append_default_CA = no
        smtpd_tls_fingerprint_digest = sha1

        submission_CAfile = ${config_directory}/submission-CAs.pem
        submission_restrictions =
        check_ccert_access ${indexed}submission-ccerts,
        permit_tls_all_clientcerts,
        reject

        master.cf:
        submission inet n ... smtpd
        -o smtpd_tls_security_level=encrypt
        -o smtpd_tls_req_ccert=yes
        -o smtpd_tls_CAfile=$submission_CAfile
        -o smtpd_client_restrictions=
        -o smtpd_helo_restrictions=
        -o smtpd_sender_restrictions=
        -o smtpd_relay_restrictions=
        -o smtpd_recipient_restrictions=$submission_restrictions
        -o smtpd_data_restrictions=
        -o smtpd_end_of_data_restrictions=

        submission-ccerts:
        da:39:a3:ee:5e:6b:4b:0d:32:55:bf:ef:95:60:18:90:af:d8:07:09
        REJECT client certificate revoked
        b7:87:76:f1:1e:a4:17:ae:64:d4:e2:34:92:c9:b2:4a:7b:1b:b5:3b
        OK exception to trusted CA constraint

        > However, from what I can tell, postfix only has $permit_tls_clientcerts,
        > and no $denied_tls_clientcerts. Because I will have a lot of churn with
        > new certs being generated continually, I would rather have the
        > opposite.

        The opposite is still not a good idea. Keep track of what you've issued,
        and permit only the ones not revoked. Negative entitlements are fragile.

        Failure to properly constrain the trusted CAs will be rather severe
        and not easily seen to be a problem when someone is naively trying
        to suppress log warnings or similar.

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