Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Can Postfix verify client certificate fingerprint when supporting StartTLS?
175 views
Skip to first unread message
Atze Zitman
Jul 29, 2014, 5:42:01 AM7/29/14
to
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....@enovation.nl
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....@enovation.nl
Wietse Venema
Jul 29, 2014, 7:17:03 AM7/29/14
to
Atze Zitman:
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
> 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,
>
> 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
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.
problem instead of the solution (reject client immediately
after the TLS handshake).
Wietse
Atze Zitman
Jul 29, 2014, 7:59:25 AM7/29/14
to
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-pos...@postfix.org [mailto:owner-pos...@postfix.org] 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
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-pos...@postfix.org [mailto:owner-pos...@postfix.org] 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
Wietse Venema
Jul 29, 2014, 8:21:26 AM7/29/14
to
Why don't you use client (certificate or public-key) fingerprints?
Wietse
Wietse
Viktor Dukhovni
Jul 29, 2014, 8:55:33 AM7/29/14
to
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.
> 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.
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.
= 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.
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.
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?)
> 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
What you really want is to reject at "RCPT TO".
--
Viktor.
Atze Zitman
Jul 29, 2014, 10:05:51 AM7/29/14
to
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-pos...@postfix.org [mailto:owner-pos...@postfix.org] Namens Viktor Dukhovni
Verzonden: dinsdag 29 juli 2014 14:56
Aan: postfi...@postfix.org
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-----
Verzonden: dinsdag 29 juli 2014 14:56
Aan: postfi...@postfix.org
Onderwerp: Re: Can Postfix verify client certificate fingerprint when supporting StartTLS?
Urgentie: Laag
Urgentie: Laag
Viktor Dukhovni
Jul 29, 2014, 10:30:06 AM7/29/14
to
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.
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).
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.
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?
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.
> However, don't you have the same problem for SASL authentication?
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)?
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.
And there is no inconsistency, apart from trivial details due to
protocol differences.
--
Viktor.
0 new messages