From af2ead5af8216520ca4e079b625b287fe435600d Mon Sep 17 00:00:00 2001 From: Wietse Venema Date: Tue, 8 Aug 2023 00:00:00 -0500 Subject: [PATCH] postfix-3.9-20230808 --- postfix/HISTORY | 7 ++++- postfix/RELEASE_NOTES | 37 +++++++++++++++----------- postfix/html/postconf.5.html | 44 ++++++++++++++++++++----------- postfix/man/man5/postconf.5 | 44 ++++++++++++++++++++----------- postfix/proto/postconf.proto | 44 ++++++++++++++++++++----------- postfix/src/global/mail_version.h | 2 +- 6 files changed, 115 insertions(+), 63 deletions(-) diff --git a/postfix/HISTORY b/postfix/HISTORY index d3ec99658..f37f294c3 100644 --- a/postfix/HISTORY +++ b/postfix/HISTORY @@ -27283,7 +27283,7 @@ Apologies for any names omitted. b) when the Postfix SMTP client initiates a TLS handshake with a remote SMTP server. See RELEASE_NOTES for details. Viktor Dukhovni. Files: mantools/postlink, proto/TLS_README.html, - proto/postconf.proto, global/mail_params.h, + proto/postconf.proto, RELEASE_NOTES, global/mail_params.h, posttls-finger/posttls-finger.c, smtp/lmtp_params.c, smtp/smtp.c, smtp/smtp.h, smtp/smtp_params.c, smtp/smtp_proto.c, smtp/smtp_tls_policy.c, smtpd/smtpd.c, smtpd/smtpd_check.c, @@ -27292,3 +27292,8 @@ Apologies for any names omitted. tls/tls_proxy_client_scan.c, tls/tls_proxy_context_print.c, tls/tls_proxy_context_scan.c, tls/tls_server.c, tls/tls_verify.c, tlsproxy/tlsproxy.c. + +20230808 + + Documentation loose ends. Files: proto/postconf.proto, + RELEASE_NOTES. diff --git a/postfix/RELEASE_NOTES b/postfix/RELEASE_NOTES index d4f2c1a5c..7f24aa4b1 100644 --- a/postfix/RELEASE_NOTES +++ b/postfix/RELEASE_NOTES @@ -48,12 +48,17 @@ Postfix with OpenSSL versions before 3.2). certificate. The Postfix SMTP client will still accept a server public key certificate instead of a public key. -- At the "dane" security level, the Postfix SMTP client will ignore - smtp_tls_enable_rpk or enable_rpk settings, and will request that - a remote SMTP server sends an RFC7250 raw public key instead of - an X.509 certificate when all valid TLSA records specify only - server public keys (no certificates). The Postfix SMTP client - will still accept a server public key certificate. +- At the "secure" and "verify" security level, the Postfix SMTP + client will ignore smtp_tls_enable_rpk or enable_rpk settings, + because these levels require a server certificate. + +- At the "dane" and "dane-only" security levels, the Postfix SMTP + client will ignore smtp_tls_enable_rpk or enable_rpk settings, + and will request that a remote SMTP server sends an RFC7250 raw + public key instead of an X.509 certificate when all valid TLSA + records specify only server public keys (no certificates). The + Postfix SMTP client will still accept a server public key + certificate. - The Postfix SMTP client and server always send a raw public key instead of a certificate, if solicited by the remote SMTP peer @@ -66,17 +71,17 @@ Postfix with OpenSSL versions before 3.2). Caution: enabling Postfix raw key support will break authentication based on certificate fingerprints in check_ccert_access or -smtp_policy_maps, when a remote peer's TLS implementation starts +smtp_tls_policy_maps, when a remote peer's TLS implementation starts to send a raw public key instead of a certificate. The solution is -to always use public key fingerprint patterns; these will match -not only a "raw" public key, but also the public key in a certificate. - -To detect such problems before they happen, the Postfix SMTP client -and server will log a warning when they request an RFC7250 raw -public key instead of an X.509 certificate, the remote peer sends -a certificate instead of a public key, and check_ccert_access or -smtp_policy_maps has a matching fingerprint for the certificate but -not for the public key in that certificate. +to always use public key fingerprint patterns; these will match not +only a "raw" public key, but also the public key in a certificate. + +To detect such problems before they happen, the Postfix SMTP server +will log a warning when it requests an RFC7250 raw public key instead +of an X.509 certificate, the remote peer sends a certificate instead +of a public key, and check_ccert_access has a matching fingerprint +for the certificate but not for the public key in that certificate. +There is no corresponding warning from the Postfix SMTP client. For instructions to generate public-key fingerprints, see the postconf(5) man pages for smtp_tls_enable_rpk and smtpd_tls_enable_rpk. diff --git a/postfix/html/postconf.5.html b/postfix/html/postconf.5.html index 84d7d093a..058d67214 100644 --- a/postfix/html/postconf.5.html +++ b/postfix/html/postconf.5.html @@ -13152,21 +13152,35 @@ the TLS handshake that it prefers to receive a raw server public key, but it will still accept a server public key certificate.

  • At the "fingerprint" security level, with parameter setting -"smtp_tls_enable_rpk = yes" or with "enable_rpk = yes" in a policy entry, -server authentication based on certificate fingerprints becomes more -fragile. Even if the server private key and certificate remain -unchanged, the remote SMTP server will fail fingerprint authentication -(won't match the configured list of fingerprints) when it starts sending -a raw public key instead of a certificate, after its TLS implementation -is updated with raw public key support. Therefore, DO NOT -enable raw public keys to remote destinations authenticated by server -certificate fingerprints. You should enable raw public keys -only for servers matched via their public key fingerprint.

    - -

  • At the "dane" security level, the Postfix SMTP client -always ignores the parameter setting smtp_tls_enable_rpk or the -enable_rpk policy attribute. When all valid TLSA records specify -only server public keys (no certificates) and the local TLS +"smtp_tls_enable_rpk = yes" or with "enable_rpk = yes" in a policy +entry, server authentication based on certificate fingerprints +becomes more fragile. Even if the server private key and certificate +remain unchanged, the remote SMTP server will fail fingerprint +authentication (won't match the configured list of fingerprints) +when it starts sending a raw public key instead of a certificate, +after its TLS implementation is updated with raw public key support. +Therefore, DO NOT enable raw public keys to remote destinations +authenticated by server certificate fingerprints. You should +enable raw public keys only for servers matched via their public +key fingerprint.

    + +

  • At the "verify" and "secure" security levels, the Postfix +SMTP client always ignores the parameter setting smtp_tls_enable_rpk +or the enable_rpk policy attribute.

    + +

  • At the opportunistic "dane" security level, the Postfix +SMTP client ignores the parameter setting smtp_tls_enable_rpk or +the enable_rpk policy attribute (but it will respect them when it +falls back to the "may" or "encrypt" level). When all valid TLSA +records specify only server public keys (no certificates) and the +local TLS implementation supports raw public keys, the client will +indicate in the TLS handshake that it prefers to receive a raw +public key, but it will still accept a public key certificate.

    + +

  • At the mandatory "dane-only" security level, the Postfix +SMTP client always ignores the parameter setting smtp_tls_enable_rpk +or the enable_rpk policy attribute. When all valid TLSA records +specify only server public keys (no certificates) and the local TLS implementation supports raw public keys, the client will indicate in the TLS handshake that it prefers to receive a raw public key, but it will still accept a public key certificate.

    diff --git a/postfix/man/man5/postconf.5 b/postfix/man/man5/postconf.5 index f8de63cf6..e373344ac 100644 --- a/postfix/man/man5/postconf.5 +++ b/postfix/man/man5/postconf.5 @@ -8597,21 +8597,35 @@ the TLS handshake that it prefers to receive a raw server public key, but it will still accept a server public key certificate. .IP \(bu At the "fingerprint" security level, with parameter setting -"smtp_tls_enable_rpk = yes" or with "enable_rpk = yes" in a policy entry, -server authentication based on certificate fingerprints becomes more -fragile. Even if the server private key and certificate remain -unchanged, the remote SMTP server will fail fingerprint authentication -(won't match the configured list of fingerprints) when it starts sending -a raw public key instead of a certificate, after its TLS implementation -is updated with raw public key support. Therefore, \fBDO NOT\fR -enable raw public keys to remote destinations authenticated by server -\fBcertificate\fR fingerprints. You should enable raw public keys -only for servers matched via their public key fingerprint. -.IP \(bu -At the "dane" security level, the Postfix SMTP client -always ignores the parameter setting smtp_tls_enable_rpk or the -enable_rpk policy attribute. When all valid TLSA records specify -only server public keys (no certificates) and the local TLS +"smtp_tls_enable_rpk = yes" or with "enable_rpk = yes" in a policy +entry, server authentication based on certificate fingerprints +becomes more fragile. Even if the server private key and certificate +remain unchanged, the remote SMTP server will fail fingerprint +authentication (won't match the configured list of fingerprints) +when it starts sending a raw public key instead of a certificate, +after its TLS implementation is updated with raw public key support. +Therefore, \fBDO NOT\fR enable raw public keys to remote destinations +authenticated by server \fBcertificate\fR fingerprints. You should +enable raw public keys only for servers matched via their public +key fingerprint. +.IP \(bu +At the "verify" and "secure" security levels, the Postfix +SMTP client always ignores the parameter setting smtp_tls_enable_rpk +or the enable_rpk policy attribute. +.IP \(bu +At the opportunistic "dane" security level, the Postfix +SMTP client ignores the parameter setting smtp_tls_enable_rpk or +the enable_rpk policy attribute (but it will respect them when it +falls back to the "may" or "encrypt" level). When all valid TLSA +records specify only server public keys (no certificates) and the +local TLS implementation supports raw public keys, the client will +indicate in the TLS handshake that it prefers to receive a raw +public key, but it will still accept a public key certificate. +.IP \(bu +At the mandatory "dane\-only" security level, the Postfix +SMTP client always ignores the parameter setting smtp_tls_enable_rpk +or the enable_rpk policy attribute. When all valid TLSA records +specify only server public keys (no certificates) and the local TLS implementation supports raw public keys, the client will indicate in the TLS handshake that it prefers to receive a raw public key, but it will still accept a public key certificate. diff --git a/postfix/proto/postconf.proto b/postfix/proto/postconf.proto index 1b60a9765..071d61e1c 100644 --- a/postfix/proto/postconf.proto +++ b/postfix/proto/postconf.proto @@ -18711,21 +18711,35 @@ the TLS handshake that it prefers to receive a raw server public key, but it will still accept a server public key certificate.

  • At the "fingerprint" security level, with parameter setting -"smtp_tls_enable_rpk = yes" or with "enable_rpk = yes" in a policy entry, -server authentication based on certificate fingerprints becomes more -fragile. Even if the server private key and certificate remain -unchanged, the remote SMTP server will fail fingerprint authentication -(won't match the configured list of fingerprints) when it starts sending -a raw public key instead of a certificate, after its TLS implementation -is updated with raw public key support. Therefore, DO NOT -enable raw public keys to remote destinations authenticated by server -certificate fingerprints. You should enable raw public keys -only for servers matched via their public key fingerprint.

    - -

  • At the "dane" security level, the Postfix SMTP client -always ignores the parameter setting smtp_tls_enable_rpk or the -enable_rpk policy attribute. When all valid TLSA records specify -only server public keys (no certificates) and the local TLS +"smtp_tls_enable_rpk = yes" or with "enable_rpk = yes" in a policy +entry, server authentication based on certificate fingerprints +becomes more fragile. Even if the server private key and certificate +remain unchanged, the remote SMTP server will fail fingerprint +authentication (won't match the configured list of fingerprints) +when it starts sending a raw public key instead of a certificate, +after its TLS implementation is updated with raw public key support. +Therefore, DO NOT enable raw public keys to remote destinations +authenticated by server certificate fingerprints. You should +enable raw public keys only for servers matched via their public +key fingerprint.

    + +

  • At the "verify" and "secure" security levels, the Postfix +SMTP client always ignores the parameter setting smtp_tls_enable_rpk +or the enable_rpk policy attribute.

    + +

  • At the opportunistic "dane" security level, the Postfix +SMTP client ignores the parameter setting smtp_tls_enable_rpk or +the enable_rpk policy attribute (but it will respect them when it +falls back to the "may" or "encrypt" level). When all valid TLSA +records specify only server public keys (no certificates) and the +local TLS implementation supports raw public keys, the client will +indicate in the TLS handshake that it prefers to receive a raw +public key, but it will still accept a public key certificate.

    + +

  • At the mandatory "dane-only" security level, the Postfix +SMTP client always ignores the parameter setting smtp_tls_enable_rpk +or the enable_rpk policy attribute. When all valid TLSA records +specify only server public keys (no certificates) and the local TLS implementation supports raw public keys, the client will indicate in the TLS handshake that it prefers to receive a raw public key, but it will still accept a public key certificate.

    diff --git a/postfix/src/global/mail_version.h b/postfix/src/global/mail_version.h index de4dce043..559191da0 100644 --- a/postfix/src/global/mail_version.h +++ b/postfix/src/global/mail_version.h @@ -20,7 +20,7 @@ * Patches change both the patchlevel and the release date. Snapshots have no * patchlevel; they change the release date only. */ -#define MAIL_RELEASE_DATE "20230807" +#define MAIL_RELEASE_DATE "20230808" #define MAIL_VERSION_NUMBER "3.9" #ifdef SNAPSHOT -- 2.47.3