Bugfix (introduced: Postfix 2.11): minor memory leak when
minting issuer certs. This affects a tiny minority of use
cases. Viktor Dukhovni, based on a fix by Juan Altmayer
- Pizzorno for the ssl_dane library.
+ Pizzorno for the ssl_dane library. File: tls/tls_dane.c.
20181104
tickets, and to allow OpenSSL >= 1.1.0 run-time micro version
bumps without complaining about library version mismatches.
Viktor Dukhovni. Files: proto/postconf.proto,
- proto/TLS_README.html, tls/tls.h, tls/tls_dane.c,
- tls/tls_server.c, tls/tls_misc.c.
+ proto/TLS_README.html, tls/tls.h, tls/tls_server.c,
+ tls/tls_misc.c.
+
+20181110
+
+ Documentation: update documentation for Postfix versions
+ that support disabling TLS 1.3. File: proto/postconf.proto.
versions of Postfix ≥ 2.10 can explicitly disable support for
"TLSv1.1" or "TLSv1.2". </p>
-<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix ≥ 3.4,
+<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix
+≥ 3.4 (or patch releases ≥ 3.0.14, 3.1.10, 3.2.7 and 3.3.2)
this can be disabled, if need be, via "!TLSv1.3". </p>
<p> At the <a href="TLS_README.html#client_tls_dane">dane</a> and
versions of Postfix ≥ 2.10 can explicitly disable support for
"TLSv1.1" or "TLSv1.2"</p>
-<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix ≥ 3.4,
+<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix
+≥ 3.4 (or patch releases ≥ 3.0.14, 3.1.10, 3.2.7 and 3.3.2)
this can be disabled, if need be, via "!TLSv1.3". </p>
<p> To include a protocol list its name, to exclude it, prefix the name
versions of Postfix ≥ 2.10 can disable support for "TLSv1.1" or
"TLSv1.2". </p>
-<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix ≥ 3.4,
+<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix
+≥ 3.4 (or patch releases ≥ 3.0.14, 3.1.10, 3.2.7 and 3.3.2)
this can be disabled, if need be, via "!TLSv1.3". </p>
<p> Example: </p>
versions of Postfix ≥ 2.10 can disable support for "TLSv1.1" or
"TLSv1.2". </p>
-<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix ≥ 3.4,
+<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix
+≥ 3.4 (or patch releases ≥ 3.0.14, 3.1.10, 3.2.7 and 3.3.2)
this can be disabled, if need be, via "!TLSv1.3". </p>
<p> To include a protocol list its name, to exclude it, prefix the name
versions of Postfix >= 2.10 can explicitly disable support for
"TLSv1.1" or "TLSv1.2".
.PP
-OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix >= 3.4,
+OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix
+>= 3.4 (or patch releases >= 3.0.14, 3.1.10, 3.2.7 and 3.3.2)
this can be disabled, if need be, via "!TLSv1.3".
.PP
At the dane and
versions of Postfix >= 2.10 can explicitly disable support for
"TLSv1.1" or "TLSv1.2"
.PP
-OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix >= 3.4,
+OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix
+>= 3.4 (or patch releases >= 3.0.14, 3.1.10, 3.2.7 and 3.3.2)
this can be disabled, if need be, via "!TLSv1.3".
.PP
To include a protocol list its name, to exclude it, prefix the name
versions of Postfix >= 2.10 can disable support for "TLSv1.1" or
"TLSv1.2".
.PP
-OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix >= 3.4,
+OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix
+>= 3.4 (or patch releases >= 3.0.14, 3.1.10, 3.2.7 and 3.3.2)
this can be disabled, if need be, via "!TLSv1.3".
.PP
Example:
versions of Postfix >= 2.10 can disable support for "TLSv1.1" or
"TLSv1.2".
.PP
-OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix >= 3.4,
+OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix
+>= 3.4 (or patch releases >= 3.0.14, 3.1.10, 3.2.7 and 3.3.2)
this can be disabled, if need be, via "!TLSv1.3".
.PP
To include a protocol list its name, to exclude it, prefix the name
versions of Postfix ≥ 2.10 can explicitly disable support for
"TLSv1.1" or "TLSv1.2". </p>
-<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix ≥ 3.4,
+<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix
+≥ 3.4 (or patch releases ≥ 3.0.14, 3.1.10, 3.2.7 and 3.3.2)
this can be disabled, if need be, via "!TLSv1.3". </p>
<p> At the <a href="TLS_README.html#client_tls_dane">dane</a> and
versions of Postfix ≥ 2.10 can disable support for "TLSv1.1" or
"TLSv1.2". </p>
-<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix ≥ 3.4,
+<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix
+≥ 3.4 (or patch releases ≥ 3.0.14, 3.1.10, 3.2.7 and 3.3.2)
this can be disabled, if need be, via "!TLSv1.3". </p>
<p> Example: </p>
versions of Postfix ≥ 2.10 can explicitly disable support for
"TLSv1.1" or "TLSv1.2"</p>
-<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix ≥ 3.4,
+<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix
+≥ 3.4 (or patch releases ≥ 3.0.14, 3.1.10, 3.2.7 and 3.3.2)
this can be disabled, if need be, via "!TLSv1.3". </p>
<p> To include a protocol list its name, to exclude it, prefix the name
versions of Postfix ≥ 2.10 can disable support for "TLSv1.1" or
"TLSv1.2". </p>
-<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix ≥ 3.4,
+<p> OpenSSL 1.1.1 introduces support for "TLSv1.3". With Postfix
+≥ 3.4 (or patch releases ≥ 3.0.14, 3.1.10, 3.2.7 and 3.3.2)
this can be disabled, if need be, via "!TLSv1.3". </p>
<p> To include a protocol list its name, to exclude it, prefix the name
* Patches change both the patchlevel and the release date. Snapshots have no
* patchlevel; they change the release date only.
*/
-#define MAIL_RELEASE_DATE "20181104"
-#define MAIL_VERSION_NUMBER "3.2.7-RC1"
+#define MAIL_RELEASE_DATE "20181110"
+#define MAIL_VERSION_NUMBER "3.2.7-RC2"
#ifdef SNAPSHOT
#define MAIL_VERSION_DATE "-" MAIL_RELEASE_DATE
#endif
/*
- * OpenSSL 1.1.1 does not define a TXT macro for TLS 1.3, so we roll our own.
+ * OpenSSL 1.1.1 does not define a TXT macro for TLS 1.3, so we roll our
+ * own.
*/
#define TLS_PROTOCOL_TXT_TLSV1_3 "TLSv1.3"
return (FILTER_RR_DROP);
}
}
-
/*-
* Drop unsupported usages.
* Note: NO SUPPORT for usages 0/1 which do not apply to SMTP.
static int add_ext(X509 *issuer, X509 *subject, int ext_nid, char *ext_val)
{
- int ret = 0;
+ int ret = 0;
X509V3_CTX v3ctx;
X509_EXTENSION *ext;
X509_NAME *name = akid_issuer_name(akid);
/*
- * If subject's akid specifies an authority key identifier issuer name, we
- * must use that.
+ * If subject's akid specifies an authority key identifier issuer name,
+ * we must use that.
*/
if (name)
return (X509_set_issuer_name(cert, name));
static int verify_chain(SSL *ssl, x509_stack_t *chain, TLS_SESS_STATE *tctx)
{
- int ret;
- X509 *cert;
+ int ret;
+ X509 *cert;
X509_STORE_CTX *store_ctx;
SSL_CTX *ssl_ctx = SSL_get_SSL_CTX(ssl);
X509_STORE *store = SSL_CTX_get_cert_store(ssl_ctx);
- int store_ctx_idx = SSL_get_ex_data_X509_STORE_CTX_idx();
+ int store_ctx_idx = SSL_get_ex_data_X509_STORE_CTX_idx();
cert = sk_X509_value(chain, 0);
if ((store_ctx = X509_STORE_CTX_new()) == NULL) {
- SSLerr(SSL_F_SSL_VERIFY_CERT_CHAIN, ERR_R_MALLOC_FAILURE);
- return 0;
+ SSLerr(SSL_F_SSL_VERIFY_CERT_CHAIN, ERR_R_MALLOC_FAILURE);
+ return 0;
}
if (!X509_STORE_CTX_init(store_ctx, store, cert, chain)) {
- X509_STORE_CTX_free(store_ctx);
- return 0;
+ X509_STORE_CTX_free(store_ctx);
+ return 0;
}
X509_STORE_CTX_set_ex_data(store_ctx, store_ctx_idx, ssl);
X509_STORE_CTX_set_default(store_ctx, "ssl_server");
X509_VERIFY_PARAM_set1(X509_STORE_CTX_get0_param(store_ctx),
- SSL_get0_param(ssl));
+ SSL_get0_param(ssl));
if (SSL_get_verify_callback(ssl))
- X509_STORE_CTX_set_verify_cb(store_ctx, SSL_get_verify_callback(ssl));
+ X509_STORE_CTX_set_verify_cb(store_ctx, SSL_get_verify_callback(ssl));
ret = dane_cb(store_ctx, tctx);
NAMEBUG(TLSEXT_PADDING),
#if 0
- /*
- * XXX: New with OpenSSL 1.1.1, this is turned on implicitly in SSL_CTX_new()
- * and is not included in SSL_OP_ALL. Allowing users to disable this would
- * thus a code change that would clearing bug work-around bits in SSL_CTX,
- * after setting SSL_OP_ALL. Since this is presumably required for TLS 1.3 on
- * today's Internet, the code change will be done separately later. For now
- * this implicit bug work-around cannot be disabled via supported Postfix
- * mechanisms.
- */
+
+ /*
+ * XXX: New with OpenSSL 1.1.1, this is turned on implicitly in
+ * SSL_CTX_new() and is not included in SSL_OP_ALL. Allowing users to
+ * disable this would thus a code change that would clearing bug
+ * work-around bits in SSL_CTX, after setting SSL_OP_ALL. Since this is
+ * presumably required for TLS 1.3 on today's Internet, the code change
+ * will be done separately later. For now this implicit bug work-around
+ * cannot be disabled via supported Postfix mechanisms.
+ */
#ifndef SSL_OP_ENABLE_MIDDLEBOX_COMPAT
#define SSL_OP_ENABLE_MIDDLEBOX_COMPAT 0
#endif
}
if (ticketable) {
SSL_CTX_set_tlsext_ticket_key_cb(server_ctx, ticket_cb);
- /*
- * OpenSSL 1.1.1 introduces support for TLS 1.3, which can issue more
- * than one ticket per handshake. While this may be appropriate for
- * communication between browsers and webservers, it is not terribly
- * useful for MTAs, many of which other than Postfix don't do TLS
- * session caching at all, and Postfix has no mechanism for storing
- * multiple session tickets, if more than one sent, the second clobbers
- * the first. OpenSSL 1.1.1 servers default to issuing two tickets for
- * non-resumption handshakes, we reduce this to one. Our ticket
- * decryption callback already (since 2.11) asks OpenSSL to avoid
- * issuing new tickets when the presented ticket is re-usable.
- */
+
+ /*
+ * OpenSSL 1.1.1 introduces support for TLS 1.3, which can issue more
+ * than one ticket per handshake. While this may be appropriate for
+ * communication between browsers and webservers, it is not terribly
+ * useful for MTAs, many of which other than Postfix don't do TLS
+ * session caching at all, and Postfix has no mechanism for storing
+ * multiple session tickets, if more than one sent, the second
+ * clobbers the first. OpenSSL 1.1.1 servers default to issuing two
+ * tickets for non-resumption handshakes, we reduce this to one. Our
+ * ticket decryption callback already (since 2.11) asks OpenSSL to
+ * avoid issuing new tickets when the presented ticket is re-usable.
+ */
SSL_CTX_set_num_tickets(server_ctx, 1);
}
#endif