mirror of
https://github.com/vdukhovni/postfix
synced 2025-08-31 06:05:37 +00:00
postfix-3.5.3
This commit is contained in:
committed by
Viktor Dukhovni
parent
e4cc71a388
commit
a322901c7e
@@ -24737,3 +24737,19 @@ Apologies for any names omitted.
|
||||
session may cause a false 'lost connection' error for a
|
||||
concurrent TLS session in the same tlsproxy process. File:
|
||||
tlsproxy/tlsproxy.c.
|
||||
|
||||
20200530
|
||||
|
||||
Bugfix (introduced: Postfix 3.1): "postfix tls deploy-server-cert"
|
||||
did not handle a missing optional argument. File:
|
||||
conf/postfix-tls-script.
|
||||
|
||||
20200610
|
||||
|
||||
Bugfix (introduced: Postfix 3.4): in the Postfix SMTP server,
|
||||
the SNI callback reported an error when it was called a
|
||||
second time. This happened after the server-side TLS engine
|
||||
sent a TLSv1.3 HelloRetryRequest (HRR) to a remote SMTP
|
||||
client. Reported by Ján Máté, fixed by Viktor Dukhovni.
|
||||
File: tls/tls_misc.c.
|
||||
|
||||
|
@@ -777,7 +777,7 @@ get_cache_db_type() {
|
||||
deploy_server_cert() {
|
||||
certfile=$1; shift
|
||||
keyfile=$1; shift
|
||||
deploy=$1; shift
|
||||
case $# in 0) deploy=;; *) deploy=$1; shift;; esac
|
||||
|
||||
# Sets key_algo, key_param and cert_param
|
||||
check_key "$keyfile" || return 1
|
||||
|
@@ -20,8 +20,8 @@
|
||||
* Patches change both the patchlevel and the release date. Snapshots have no
|
||||
* patchlevel; they change the release date only.
|
||||
*/
|
||||
#define MAIL_RELEASE_DATE "20200516"
|
||||
#define MAIL_VERSION_NUMBER "3.5.2"
|
||||
#define MAIL_RELEASE_DATE "20200614"
|
||||
#define MAIL_VERSION_NUMBER "3.5.3"
|
||||
|
||||
#ifdef SNAPSHOT
|
||||
#define MAIL_VERSION_DATE "-" MAIL_RELEASE_DATE
|
||||
|
@@ -686,6 +686,27 @@ static int server_sni_callback(SSL *ssl, int *alert, void *arg)
|
||||
TLScontext->namaddr, sni);
|
||||
return SSL_TLSEXT_ERR_NOACK;
|
||||
}
|
||||
|
||||
/*
|
||||
* With TLS 1.3, when the client's proposed key share is not supported by
|
||||
* the server, the server may issue a HelloRetryRequest (HRR), and the
|
||||
* client will then retry with a new key share on a curve supported by
|
||||
* the server. This results in the SNI callback running twice for the
|
||||
* same connection.
|
||||
*
|
||||
* When that happens, The client MUST send the essentially the same hello
|
||||
* message, including the SNI name, and since we've already loaded our
|
||||
* certificate chain, we don't need to do it again! Therefore, if we've
|
||||
* already recorded the peer SNI name, just check that it has not
|
||||
* changed, and return success.
|
||||
*/
|
||||
if (TLScontext->peer_sni) {
|
||||
if (strcmp(sni, TLScontext->peer_sni) == 0)
|
||||
return SSL_TLSEXT_ERR_OK;
|
||||
msg_warn("TLS SNI changed from %s initially %s, %s after hello retry",
|
||||
TLScontext->namaddr, TLScontext->peer_sni, sni);
|
||||
return SSL_TLSEXT_ERR_NOACK;
|
||||
}
|
||||
do {
|
||||
/* Don't silently skip maps opened with the wrong flags. */
|
||||
pem = maps_file_find(tls_server_sni_maps, cp, 0);
|
||||
|
Reference in New Issue
Block a user