Thanks Viktor for the reply. I think you were correct that mail was blocked only on port IPv4, and it had nothing to do with DANE.
I've removed the TLSv1.3 ciphers from the list and TLSv1.3 keeps working. Unfortunately, the >=TLSv1.2 syntax is not supported for my version of Postfix (v3.5.8) and removing the cipher list entirely leaves me vulnerable to SWEET32, LUCKY13, and RC4. > No, just unwise crypto-maximalism from RedHat. Much of the security community is overly focused on raising the floor, rather than the ceiling. My efforts in RFC7435 were in vain. It indeed has to do with the crypto policy of RHEL and not with Postfix. I've disabled the FIPS policy now as it's not a deal breaker and both Postfix and Dovecot work fine now. > NO. Neither is appropriate for outbound mail which always uses port 25, with STARTTLS when available. Regarding MTA-MTA connections, it seems I didn't fully understand it. I was surprised that port 25 (unencrypted) was used for all mail traffic, but surely (and hopefully) most connections upgrade with STARTTLS. This happens on port 25 though, unlike MUA-MTA connections which happen (regularly) on port 587 (and perhaps on port 25 as well?). I was under the impression that implicit TLS is (slightly) more secure since the TLS negotiation happens right at the start and not somewhere down along the connection. Kind regards, Taco de Wolff On Mon, Jan 22, 2024 at 2:42 PM Viktor Dukhovni via Postfix-users < postfix-users@postfix.org> wrote: > On Mon, Jan 22, 2024 at 11:44:40AM -0300, Taco de Wolff via Postfix-users > wrote: > > > Two questions really, one is that I can't enable TLS1.3 whatever I try. > > Running CentOS8 with OpenSSL v1.1.1k-FIPS and Postfix v3.5.8, I confirm > > that TLS1.3 ciphers are available: > > Protocol version negotiation is up to OpenSSL. The only non-trivial > fact about the Postfix SMTP server, is that is permissive and sets the > SSL security level to 0 unless you set "smtpd_tls_req_ccert = yes", in > which case security level 1 is used. I would not expect a permissive > security level to cause TLS 1.3 negotiation to be disabled. Perhaps > your certificate is somehow not compatible with TLS 1.3. > > > # postconf > > smtpd_tls_cert_file = /path/to/crt > > Can you share the public certificate? > > > smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 > > smtpd_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1 > > The more up-to-date syntax for that is: > > # Note: no whitespace between ">=" and the TLS version! > smtpd_tls_mandatory_protocols = >=TLSv1.2 > smtpd_tls_protocols = >=TLSv1.2 > > > tls_medium_cipherlist = > > > TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-CHACHA20-POLY1305 > > Drop the first three elements, TLS 1.3 bulk encryption ciphers are not > the TLS 1.0–2 ciphersuites and have no effect in any of the "cipherlist" > parameters. Better yet, don't override the list at all... > > > smtpd_tls_security_level = encrypt > > smtpd_tls_wrappermode = yes > > These should only be set in master.cf, not main.cf > > > $ openssl s_client -connect server.hostname:465 -tls1_3 > > Connecting to [IPADDRESS] > > CONNECTED(00000003) > > 40879BE5F97F0000:error:0A00042E:SSL routines:ssl3_read_bytes:tlsv1 alert > > protocol version:ssl/record/rec_layer_s3.c:861:SSL alert number 70 > > This is not possible with OpenSSL 1.1.1 from the upstream openssl.org > source. It must be part of the crypto-policy patches from RedHat. > Upstream there are no protocol version alerts in rec_layer_s3.c, the > only such alerts in OpenSSL_1_1_1-stable are in: > > ssl/record/ssl3_record.c: SSLfatal(s, > SSL_AD_PROTOCOL_VERSION, SSL_F_SSL3_GET_RECORD, > ssl/record/ssl3_record.c: SSLfatal(s, > SSL_AD_PROTOCOL_VERSION, > ssl/statem/statem_clnt.c: SSLfatal(s, SSL_AD_PROTOCOL_VERSION, > SSL_F_TLS_PROCESS_SERVER_HELLO, > ssl/statem/statem_lib.c: SSLfatal(s, SSL_AD_PROTOCOL_VERSION, > SSL_F_SSL_CHOOSE_CLIENT_VERSION, > ssl/statem/statem_lib.c: SSLfatal(s, > SSL_AD_PROTOCOL_VERSION, > ssl/statem/statem_lib.c: SSLfatal(s, SSL_AD_PROTOCOL_VERSION, > ssl/statem/statem_lib.c: SSLfatal(s, SSL_AD_PROTOCOL_VERSION, > ssl/statem/statem_lib.c: SSLfatal(s, SSL_AD_PROTOCOL_VERSION, > ssl/statem/statem_lib.c: SSLfatal(s, SSL_AD_PROTOCOL_VERSION, > SSL_F_SSL_CHOOSE_CLIENT_VERSION, > ssl/statem/statem_srvr.c: SSLfatal(s, > SSL_AD_PROTOCOL_VERSION, > ssl/statem/statem_srvr.c: SSLfatal(s, SSL_AD_PROTOCOL_VERSION, > ssl/statem/statem_srvr.c: SSLfatal(s, > SSL_AD_PROTOCOL_VERSION, > > > Has this something to do with FIPS mode? I don't think so because the > > ciphers show up in OpenSSL. Why is TLS1.3 not getting enabled? > > Ask RedHat. > > > Second question came up while fixing a blocked outbound port 25 with my > > ISP. I've noticed that mail gets sent to DANE enabled servers, I suppose > > because it uses port 587 using STARTTLS. > > You're probably misreading the evidence. Perhaps the outbound block is > IPv4-specific, and you're getting through on port 25 over IPv6 to > servers that are IPv6-enabled, run by tech-savvy operators, which could > somewhat correlate with DANE support. > > > I wonder if postfix allows sending mail over the recommended implicit > > TLS port 465 between mail servers? > > Nothing of the sort is either remote correct or implemented. > > > ... setting smtp_tls_wrappermode=yes would force using implicit TLS > > (right?), > > It would, but then none of the outbound mail would be delivered, since > there are no SMTP servers that do implicit TLS on port 25. > > On Mon, Jan 22, 2024 at 12:34:18PM -0300, Taco de Wolff via Postfix-users > wrote: > > > Sorry, this was a problem with the system-wide cryptographic policies. I > > set it to DEFAULT and it works. This is unexpected though, since at least > > two TLS1.3 ciphersuites are enabled with FIPS:OSPP and TLS1.3 works with > > Nginx (Dovecot is similar to Postfix though and both are fixed with this > > crypto setting). > > There may be a specific policy for Nginx. I build my own Postfix and > OpenSSL from source, so haven't had to fight the crypto-policy excesses. > > > Surely, somewhere in how Postfix/Dovecot use OpenSSL is > > getting blocked when using FIPS mode. Is that a bad configuration or a > bug > > perhaps? > > No, just unwise crypto-maximalism from RedHat. Much of the security > community is overly focused on raising the floor, rather than the > ceiling. My efforts in RFC7435 were in vain. > > > Still wondering whether I can enable server-to-server connections > > opportunistically over port 465 though, not just 587. > > NO. Neither is appropriate for outbound mail which always uses port 25, > with STARTTLS when available. > > -- > Viktor. > _______________________________________________ > Postfix-users mailing list -- postfix-users@postfix.org > To unsubscribe send an email to postfix-users-le...@postfix.org >
_______________________________________________ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
