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

Can Postfix verify client certificate fingerprint when supporting StartTLS?

Expand Messages
  • Atze Zitman
    Hello everyone, I hope I have the correct mailing list for my question. Initially I asked this question at:
    Message 1 of 7 , Jul 29, 2014
    • 0 Attachment
      Hello everyone,

      I hope I have the correct mailing list for my question. Initially I asked this question at: http://stackoverflow.com/questions/24999580/can-postfix-verify-client-certificate-fingerprint-when-supporting-starttls

      According to the Postfix TLS Readme there are 3 ways to configure the server-side to support access control:
      * permit_tls_clientcerts
      * permit_tls_all_clientcerts
      * check_ccert_access type:table

      But these three options are only configurable for the configuration property:
      * smtpd_client_restrictions

      This property will trigger the verification at the time the connection is established with the client. This is useful when you support SSL (SMTPS or SSMTP), but not when you are using StartTLS. A client connecting to SMTPS will first start the TLS negotiation and authenticate with the client certificate. When using StartTLS, the client is already connected (may even already have stated "EHLO stackoverflow.com") and then starts the TLS negotiation.

      I actually created a policy daemon and used the "check_ccert_access type:table" for "smtpd_client_restrictions". That way I was able to confirm that postfix was at CONNECT state, and no client certificate information was available.

      The only alternative I have, is to use my policy daemon, and verify the authentication at the first "MAIL FROM" (MAIL STATE). At this point I am rejecting the sender address, based on the authentication. But I would like to reject the client right after the TLS negotiation.

      Is this possible? Otherwise, can I request this as a feature? (How? Where?)

      So instead of:
      openssl s_client -connect localhost:25 -starttls smtp -cert cert.crt -key key.pem -ign_eof
      ----
      250 DSN

      I would like:
      openssl s_client -connect localhost:25 -starttls smtp -cert cert.crt -key key.pem -ign_eof
      ----
      535 5.7.8 Error: authentication failed: authentication failure

      Regards Atze Zitman
      atze.zitman@...
    • Wietse Venema
      ... As documented they are also available for smtpd_{helo,sender,recipient, data,end_of_data}_restrictions. ... Why? What problem are you trying to solve?
      Message 2 of 7 , Jul 29, 2014
      • 0 Attachment
        Atze Zitman:
        > Hello everyone,
        >
        > I hope I have the correct mailing list for my question. Initially I asked this question at: http://stackoverflow.com/questions/24999580/can-postfix-verify-client-certificate-fingerprint-when-supporting-starttls
        >
        > According to the Postfix TLS Readme there are 3 ways to configure the server-side to support access control:
        > * permit_tls_clientcerts
        > * permit_tls_all_clientcerts
        > * check_ccert_access type:table
        >
        > But these three options are only configurable for the configuration property:
        > * smtpd_client_restrictions

        As documented they are also available for smtpd_{helo,sender,recipient,
        data,end_of_data}_restrictions.

        > The only alternative I have, is to use my policy daemon, and verify
        > the authentication at the first "MAIL FROM" (MAIL STATE). At this
        > point I am rejecting the sender address, based on the authentication.
        > But I would like to reject the client right after the TLS negotiation.

        Why? What problem are you trying to solve? Please explain the
        problem instead of the solution (reject client immediately
        after the TLS handshake).

        Wietse
      • Atze Zitman
        Thank you Wietse for your reply. The only real problem is clear communication to the client. I will always validate the sender address. When the client is
        Message 3 of 7 , Jul 29, 2014
        • 0 Attachment
          Thank you Wietse for your reply.

          The only real problem is clear communication to the client.

          I will always validate the sender address. When the client is authenticated, it is validated differently than when the client is not authenticated (using policyd). For example:
          * Unauthenticated user must use an external (unknown) domain for sender address.
          * An authenticated user must use a local (known) domain for sender address.
          When client certificate-authentication fails, the client gets no feedback about this. But does get rejected, stating that he is using an invalid domain in the sender address. This is very misleading to the real problem, wrong or expired credentials.
          Of course, if we enable SASL authentication (not an option in my case), this situation would not occur, because the client gets a reject based on the failed credentials, before the sender address is provided.

          Regards,
           
          Atze Zitman

          -----Oorspronkelijk bericht-----
          Van: owner-postfix-users@... [mailto:owner-postfix-users@...] Namens Wietse Venema
          Verzonden: dinsdag 29 juli 2014 13:17
          Aan: Postfix users
          Onderwerp: Re: Can Postfix verify client certificate fingerprint when supporting StartTLS?
          Urgentie: Laag

          Atze Zitman:
          > Hello everyone,
          >
          > I hope I have the correct mailing list for my question. Initially I
          > asked this question at:
          > http://stackoverflow.com/questions/24999580/can-postfix-verify-client-
          > certificate-fingerprint-when-supporting-starttls
          >
          > According to the Postfix TLS Readme there are 3 ways to configure the server-side to support access control:
          > * permit_tls_clientcerts
          > * permit_tls_all_clientcerts
          > * check_ccert_access type:table
          >
          > But these three options are only configurable for the configuration property:
          > * smtpd_client_restrictions

          As documented they are also available for smtpd_{helo,sender,recipient, data,end_of_data}_restrictions.

          > The only alternative I have, is to use my policy daemon, and verify
          > the authentication at the first "MAIL FROM" (MAIL STATE). At this
          > point I am rejecting the sender address, based on the authentication.
          > But I would like to reject the client right after the TLS negotiation.

          Why? What problem are you trying to solve? Please explain the problem instead of the solution (reject client immediately after the TLS handshake).

          Wietse
        • Wietse Venema
          Why don t you use client (certificate or public-key) fingerprints? Wietse
          Message 4 of 7 , Jul 29, 2014
          • 0 Attachment
            Why don't you use client (certificate or public-key) fingerprints?

            Wietse
          • Viktor Dukhovni
            ... As Wietse pointed out, also with smtpd_{helo,sender,relay,recipient,data,end_of_data}_restrictions. ... No, by default smtpd_delay_reject = yes , and thus
            Message 5 of 7 , Jul 29, 2014
            • 0 Attachment
              On Tue, Jul 29, 2014 at 11:42:01AM +0200, Atze Zitman wrote:

              > According to the Postfix TLS Readme there are 3 ways to configure the server-side to support access control:
              >
              > * permit_tls_clientcerts
              > * permit_tls_all_clientcerts
              > * check_ccert_access type:table
              >
              > But these three options are only configurable for the configuration property:
              >
              > * smtpd_client_restrictions

              As Wietse pointed out, also with smtpd_{helo,sender,relay,recipient,data,end_of_data}_restrictions.

              > This property will trigger the verification at the time the connection is
              > established with the client.

              No, by default "smtpd_delay_reject = yes", and thus no restrictions
              are evaluated before "RCPT TO", at which point each of

              smtpd_client_retrictions,
              smtpd_helo_retrictions,
              smtpd_sender_retrictions,
              smtpd_relay_retrictions,
              smtpd_recipient_retrictions

              is evaled in turn for *each* recipient.

              > This is useful when you support SSL (SMTPS
              > or SSMTP), but not when you are using StartTLS.

              A false premise, yields a false conclusion. Don't set "smtpd_delay_reject
              = no", and (almost) all the restrictions are available for use with
              all the built-in restriction classes, the exception being that
              recipient address checks don't work at the data and end_of_data
              stages.

              > I actually created a policy daemon and used the "check_ccert_access
              > type:table" for "smtpd_client_restrictions". That way I was able to confirm
              > that postfix was at CONNECT state, and no client certificate information
              > was available.

              Perhaps you set "smtpd_delay_reject = no". In that case, if there is good
              reason to do so, use "check_ccert_access" in "smtpd_recipient_restrictions" or
              "smtpd_relay_restrictions" (Postfix 2.10 or later IIRC).

              > The only alternative I have, is to use my policy daemon, and verify the
              > authentication at the first "MAIL FROM" (MAIL STATE). At this point I am
              > rejecting the sender address, based on the authentication. But I would
              > like to reject the client right after the TLS negotiation.

              False premise, false conclusion. However, early reject (before
              RCPT TO) is unwise, since your logs won't contain any sender or
              recipient information about the rejected clients. It is far preferrable
              to not reject early. Also many systems will not bounce mail when the
              server returns 5XX before "MAIL FROM". Thus the client will keep on
              trying until the message expires. This is a bad idea.

              > Is this possible? Otherwise, can I request this as a feature? (How? Where?)

              You're asking the wrong questions.

              > So instead of:
              > openssl s_client -connect localhost:25 -starttls smtp -cert cert.crt -key key.pem -ign_eof
              > ----
              > 250 DSN
              >
              > I would like:
              > openssl s_client -connect localhost:25 -starttls smtp -cert cert.crt -key key.pem -ign_eof
              > ----
              > 535 5.7.8 Error: authentication failed: authentication failure

              Actually, if you knew what this entailed, you would not want this.
              What you really want is to reject at "RCPT TO".

              --
              Viktor.
            • Atze Zitman
              Hi Viktor, Thank you for your reply. It is true that I have smtpd_delay_reject = no . I have done this, so the sender restrictions would not be evaluated for
              Message 6 of 7 , Jul 29, 2014
              • 0 Attachment
                Hi Viktor,

                Thank you for your reply.

                It is true that I have "smtpd_delay_reject = no". I have done this, so the sender restrictions would not be evaluated for each recipient address, but for the sender address only (tested long time ago, hope I'm not wrong). When the policyd rejects a sender address (smtpd_sender_restrictions), the reject is given after each "RCPT TO" with a clear message that the sender address is rejected. The postfix logging and policyd logging contain both sender & recipient address. I am missing something else about this property, why I really should change it back to the default?

                I can understand that it is strongly undesirable to return any 5XX before the "MAIL FROM" as you describe the behavior of most mail servers. However, don't you have the same problem for SASL authentication? When the SASL authentication fails, Postfix returns 535 prior to the MAIL FROM. Why not have the same behavior for a different kind of authentication (client-certificate)?

                I understand why and how authentication failures can be rejected after the "RCPT TO". But for now, I see this more as a workaround, instead of preferred behavior. Or at the very least, inconsistent between SASL & client-certificate authentication.

                PS: I am still not able to determine smtpd_{helo,sender,relay,recipient,data,end_of_data}_restrictions are also available for the other three options, when I am looking at postconf.5.html. For example, I would also expect those options at "smtpd_sender_restrictions". But I will take your word for it.
                Further, I see that I indeed misread the documentation about "smtpd_delay_reject = no" having influence on smtpd_client_restrictions. My assumption that it only influences


                Regards,
                 
                Atze Zitman



                -----Oorspronkelijk bericht-----
                Van: owner-postfix-users@... [mailto:owner-postfix-users@...] Namens Viktor Dukhovni
                Verzonden: dinsdag 29 juli 2014 14:56
                Aan: postfix-users@...
                Onderwerp: Re: Can Postfix verify client certificate fingerprint when supporting StartTLS?
                Urgentie: Laag

                On Tue, Jul 29, 2014 at 11:42:01AM +0200, Atze Zitman wrote:

                > According to the Postfix TLS Readme there are 3 ways to configure the server-side to support access control:
                >
                > * permit_tls_clientcerts
                > * permit_tls_all_clientcerts
                > * check_ccert_access type:table
                >
                > But these three options are only configurable for the configuration property:
                >
                > * smtpd_client_restrictions

                As Wietse pointed out, also with smtpd_{helo,sender,relay,recipient,data,end_of_data}_restrictions.

                > This property will trigger the verification at the time the connection
                > is established with the client.

                No, by default "smtpd_delay_reject = yes", and thus no restrictions are evaluated before "RCPT TO", at which point each of

                smtpd_client_retrictions,
                smtpd_helo_retrictions,
                smtpd_sender_retrictions,
                smtpd_relay_retrictions,
                smtpd_recipient_retrictions

                is evaled in turn for *each* recipient.

                > This is useful when you support SSL (SMTPS or SSMTP), but not when you
                > are using StartTLS.

                A false premise, yields a false conclusion. Don't set "smtpd_delay_reject = no", and (almost) all the restrictions are available for use with all the built-in restriction classes, the exception being that recipient address checks don't work at the data and end_of_data stages.

                > I actually created a policy daemon and used the "check_ccert_access
                > type:table" for "smtpd_client_restrictions". That way I was able to
                > confirm that postfix was at CONNECT state, and no client certificate
                > information was available.

                Perhaps you set "smtpd_delay_reject = no". In that case, if there is good reason to do so, use "check_ccert_access" in "smtpd_recipient_restrictions" or "smtpd_relay_restrictions" (Postfix 2.10 or later IIRC).

                > The only alternative I have, is to use my policy daemon, and verify
                > the authentication at the first "MAIL FROM" (MAIL STATE). At this
                > point I am rejecting the sender address, based on the authentication.
                > But I would like to reject the client right after the TLS negotiation.

                False premise, false conclusion. However, early reject (before RCPT TO) is unwise, since your logs won't contain any sender or recipient information about the rejected clients. It is far preferrable to not reject early. Also many systems will not bounce mail when the server returns 5XX before "MAIL FROM". Thus the client will keep on trying until the message expires. This is a bad idea.

                > Is this possible? Otherwise, can I request this as a feature? (How?
                > Where?)

                You're asking the wrong questions.

                > So instead of:
                > openssl s_client -connect localhost:25 -starttls smtp -cert cert.crt
                > -key key.pem -ign_eof
                > ----
                > 250 DSN
                >
                > I would like:
                > openssl s_client -connect localhost:25 -starttls smtp -cert cert.crt
                > -key key.pem -ign_eof
                > ----
                > 535 5.7.8 Error: authentication failed: authentication failure

                Actually, if you knew what this entailed, you would not want this.
                What you really want is to reject at "RCPT TO".

                --
                Viktor.
              • Viktor Dukhovni
                On Tue, Jul 29, 2014 at 04:05:51PM +0200, Atze Zitman wrote: ... If this is what you inadvisably decide to do, then indeed client and helo restrictions are too
                Message 7 of 7 , Jul 29, 2014
                • 0 Attachment
                  On Tue, Jul 29, 2014 at 04:05:51PM +0200, Atze Zitman wrote:

                  My final response in this thread:

                  > It is true that I have "smtpd_delay_reject = no". I have done this, so
                  > the sender restrictions would not be evaluated for each recipient address,
                  > but for the sender address only (tested long time ago, hope I'm not wrong).

                  If this is what you inadvisably decide to do, then indeed client
                  and helo restrictions are too early for check_ccert_access, but
                  you can still use smtpd_{sender,relay,recipient}_restrictions which
                  evaluate after STARTTLS (the "smtpd_relay_restrictions" feature is
                  Postfix >= 2.10).

                  > When the policyd rejects a sender address (smtpd_sender_restrictions),
                  > the reject is given after each "RCPT TO" with a clear message that the
                  > sender address is rejected.

                  Only with "smtpd_delay_reject = yes", but if the client employs
                  ESMTP PIPELINING, any RCPT TO commands sent with "MAIL FROM" will
                  also be rejected for the same reason (provided the MAIL FROM reject
                  is not a 421 or 521).

                  > The postfix logging and policyd logging contain
                  > both sender & recipient address. I am missing something else about this
                  > property, why I really should change it back to the default?

                  This is not the case with "smtpd_delay_reject = no" except by accident
                  due to pipelining.

                  > I can understand that it is strongly undesirable to return any 5XX before
                  > the "MAIL FROM" as you describe the behavior of most mail servers.

                  That should be sufficient to avoid the mistake.

                  > However, don't you have the same problem for SASL authentication?

                  SASL authentication is on the MSA port (587). MTA to MTA traffic does
                  not employ SASL authentication.

                  More critically, you're confusing authentication with authorization.
                  When SASL auth fails it is similar to the TLS client failing to
                  complete the TLS handshake correctly (private key mismatch with
                  public key, ...). The actual authorization check is
                  "permit_sasl_authenticated", which is used in:

                  smtpd_relay_restrictions, or
                  smtpd_recipient_restrictions

                  just like "check_ccert_access".

                  > When the SASL
                  > authentication fails, Postfix returns 535 prior to the MAIL FROM. Why not
                  > have the same behavior for a different kind of authentication
                  > (client-certificate)?

                  The TLS client auth fails, the connection fails. You're talking about
                  authorization checks.

                  > I understand why and how authentication failures can be rejected after
                  > the "RCPT TO". But for now, I see this more as a workaround, instead of
                  > preferred behavior. Or at the very least, inconsistent between SASL &
                  > client-certificate authentication.

                  No, *authorization failures* can and should be rejected at RCPT TO.
                  And there is no inconsistency, apart from trivial details due to
                  protocol differences.

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