Hello Everyone, I'm setting up a new postfix 3.5.4 server on a Centos 8 box and, no matter what config i make, i can't get TLSv1 (yes, sorry, need to support some old clients until the end of the year) support to work. I have already tweaked smtpd_tls_mandatory_protocols and smtpd_tls_protocols to "!SSLv2, !SSLv3" but TLSv1 simply doesn't work. The very same config, on other CentOS 7 boxes, are working fine to allow TLSv1 connections. While googling for the error warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:ssl/statem/statem_srvr.c:1661: found a proposed patch on https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873334 to "overrides default TLSv1.2" ... and after applying and recompiled postfix 3.5.4, TLSv1 worked immediately with the config i was running (no config problem after all). So it seems we really have a TLSv1.2 minimum hardcoded anywhere. Is it on the postfix sources? Is it CentOS 8? Is it possible to change that, via config or compile options, without patching the sources? Thanks all! -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email [hidden email] My SPAMTRAP, do not email it |
On Mon, Jul 20, 2020 at 09:51:38PM -0300, Leonardo Rodrigues wrote:
> I have already tweaked smtpd_tls_mandatory_protocols and > smtpd_tls_protocols to "!SSLv2, !SSLv3" but TLSv1 simply doesn't work. Postfix does not set a minimum TLS protocol version, it just disables the versions specified with '!' prefixes in smtpd_tls_protocols. However, your system-wide OpenSSL configuration file: http://postfix.1071664.n5.nabble.com/problem-connecting-with-android-device-tp106848p106863.html or a vendor change to the OpenSSL library may result a minimum protocol version "behind Postfix's back". > While googling for the error > > found a proposed patch on > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=873334 to "overrides > default TLSv1.2" ... and after applying and recompiled postfix 3.5.4, > TLSv1 worked immediately with the config i was running (no config > problem after all). That's for recent Debian versions, where the system-wide openssl.cnf file indeed configures a floor of TLSv1.2, but then Debian have also patched their Postfix package to clear the minimum version. If CentOS 8 requires a default floor of TLS 1.2, and have not patched Postfix to relax that system-default constraint, then you're stuck with TLS >= 1.2 until a suitable work-around is made available in their Postfix package. > So it seems we really have a TLSv1.2 minimum hardcoded anywhere. Is > it on the postfix sources? Is it CentOS 8? Is it possible to change > that, via config or compile options, without patching the sources? Postfix has no such hard-coded default. It is in the system libraries and/or configuration files. -- VIktor. |
In reply to this post by Leonardo Rodrigues Magalhães
Hi,
> I'm setting up a new postfix 3.5.4 server on a Centos 8 box and, > no matter what config i make, i can't get TLSv1 (yes, sorry, need to > support some old clients until the end of the year) support to work. I have been working with Red Hat Enterprise Linux 8 and very likely CentOS is using the same new "Systeme-wide crypo policies" mechanism that may interfere with your configuration. Details here: [ https://access.redhat.com/articles/3666211 ] [ https://access.redhat.com/articles/3642912 ] There is a way to change a different system policy; or you can keep it and only tweak what you need (I did something like that for OpenSSH). Hope this help. Sincerely, -- Xavier Belanger |
In reply to this post by Viktor Dukhovni
Em 20/07/2020 22:44, Viktor Dukhovni escreveu:
> If CentOS 8 requires a default floor of TLS 1.2, and have not patched > Postfix to relax that system-default constraint, then you're stuck > with TLS >= 1.2 until a suitable work-around is made available in > their Postfix package. > You nailed it, Viktor and Xavier, it was the default system-wide setup on the CentOS 8 OS from file /usr/share/crypto-policies/DEFAULT/opensslcnf.txt setting MinProtocol to TLSv1 there did the trick. Thank you guys! -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email [hidden email] My SPAMTRAP, do not email it |
Hi,
Leonardo Rodrigues <[hidden email]> wrote: > You nailed it, Viktor and Xavier, it was the default system-wide > setup on the CentOS 8 OS from file > > /usr/share/crypto-policies/DEFAULT/opensslcnf.txt > > setting MinProtocol to TLSv1 there did the trick. > > Thank you guys! You're welcome. One piece of advice: that file may be considered as a "system file" and could be overwritten in the future by some CentOS update. Make sure to document that change and to keep an eye of that file; or to define your own policy (custom policies are not overwritten). Sincerely, -- Xavier Belanger |
>Xavier Belanger:
> One piece of advice: [opensslcnf.txt] may be considered as a "system > file" and could be overwritten in the future by some CentOS update. > Make sure to document that change and to keep an eye of that file; > or to define your own policy (custom policies are not overwritten). Our plan is to restore compatibility with OpenSSL before 1.1.1, i.e. ignore the OpenSSL MinProtocol setting. It's like extinguishing fires with breaking changes in dependencies, first with glibc DNSSEC support, now with OpenSSL and allowed protocols. Wietse |
In reply to this post by Xavier Belanger
On 22/07/20 9:02 am, Xavier Belanger wrote:
> Hi, > > > Leonardo Rodrigues <[hidden email]> wrote: > >> You nailed it, Viktor and Xavier, it was the default system-wide >> setup on the CentOS 8 OS from file >> >> /usr/share/crypto-policies/DEFAULT/opensslcnf.txt >> >> setting MinProtocol to TLSv1 there did the trick. >> >> Thank you guys! > > You're welcome. > > One piece of advice: that file may be considered as a "system > file" and could be overwritten in the future by some CentOS > update. Make sure to document that change and to keep an eye > of that file; or to define your own policy (custom policies > are not overwritten). Indeed this is correct, in fact I just checked and verified that file is not marked as a config file so it will be overwritten on update. I would suggest modifying /etc/crypto-policies/config and changing it to LEGACY instead. This change won't be overwritten by updates. Peter |
In reply to this post by Xavier Belanger
Xavier Belanger wrote:
> Hi, > > > Leonardo Rodrigues <[hidden email]> wrote: > >> You nailed it, Viktor and Xavier, it was the default system-wide >> setup on the CentOS 8 OS from file >> >> /usr/share/crypto-policies/DEFAULT/opensslcnf.txt >> >> setting MinProtocol to TLSv1 there did the trick. >> >> Thank you guys! > > You're welcome. > > One piece of advice: that file may be considered as a "system > file" and could be overwritten in the future by some CentOS > update. Make sure to document that change and to keep an eye > of that file; or to define your own policy (custom policies > are not overwritten). It should be possible to set options like this in /etc somewhere, which shouldn't be overwritten on package upgrades. I'm not sure where CentOS/RHEL/Fedora have put the relevant OpenSSL configuration recently, but on Debian and derivatives this can be set in /etc/ssl/openssl.cnf. -kgd |
Hi,
Kris Deugau <[hidden email]> wrote: > It should be possible to set options like this in /etc somewhere, which > shouldn't be overwritten on package upgrades. I'm not sure where > CentOS/RHEL/Fedora have put the relevant OpenSSL configuration recently, > but on Debian and derivatives this can be set in /etc/ssl/openssl.cnf. It is, the idea is to define exception in the system crypto policy used by the system. There is multiple ways to do this: [ https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening ] See sections: - 3.5. Excluding an application from following system-wide crypto policies - 3.6. Customizing system-wide cryptographic policies with policy modifiers - 3.7. Creating and setting a custom system-wide cryptographic policy It's not as quick and simple as editing one configuration file, but this should not be too difficult to implement. The issue here is that this mechanism is new in Red Hat/CentOS 8 and some people may not be aware of it. Sincerely, -- Xavier Belanger |
On Wed, Jul 22, 2020 at 11:11:27AM -0400, Xavier Belanger wrote:
> It is, the idea is to define exception in the system crypto policy > used by the system. There is multiple ways to do this: > > [ https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening ] > > See sections: > > - 3.5. Excluding an application from following system-wide crypto policies > - 3.6. Customizing system-wide cryptographic policies with policy modifiers > - 3.7. Creating and setting a custom system-wide cryptographic policy > > It's not as quick and simple as editing one configuration file, > but this should not be too difficult to implement. The issue here > is that this mechanism is new in Red Hat/CentOS 8 and some people may > not be aware of it. The plan is to soon not require Postfix users to go down that particular rabbit hole. Instead Postfix will disable any TLS protocol lower/upper bounds inherited from system policy, and apply its own, based on whichever of: lmtp_tls_protocols, lmtp_tls_mandatory_protocols, smtp_tls_protocols, smtp_tls_mandatory_protocols, smtpd_tls_protocols, smtpd_tls_mandatory_protocols, tlsproxy_tls_protocols, tlsproxy_tls_mandatory_protocols happens to be applicable. This should be possible with the next patch level of the supported stable releases. In Postfix 3.6, the built-in Postfix controls will be extended to support setting upper/lower bounds, as a preferred alternative to enumerating individual protocol versions to exclude. -- Viktor. |
Em 22/07/2020 12:45, Viktor Dukhovni escreveu:
> The plan is to soon not require Postfix users to go down that particular > rabbit hole. Instead Postfix will disable any TLS protocol lower/upper > bounds inherited from system policy, and apply its own, based on > whichever of: > > lmtp_tls_protocols, lmtp_tls_mandatory_protocols, > smtp_tls_protocols, smtp_tls_mandatory_protocols, > smtpd_tls_protocols, smtpd_tls_mandatory_protocols, > tlsproxy_tls_protocols, tlsproxy_tls_mandatory_protocols > > happens to be applicable. This should be possible with the > next patch level of the supported stable releases. > > In Postfix 3.6, the built-in Postfix controls will be extended to > support setting upper/lower bounds, as a preferred alternative > to enumerating individual protocol versions to exclude. > Just as an observation, while trying to enable TLSv1 on postfix and getting into this rabbit hole, i found that dovecot (intentionally or not) already do not respect those system-wide restrictions. I could get latest dovecot (built from sources, just like postfix i'm using) to accept TLSv1 with no system changes at all. Even on DEFAULT system policy, which do not accept TLSv1, dovecot does accept it with no problems, if configured that way. -- Atenciosamente / Sincerily, Leonardo Rodrigues Solutti Tecnologia http://www.solutti.com.br Minha armadilha de SPAM, NÃO mandem email [hidden email] My SPAMTRAP, do not email it |
In reply to this post by Leonardo Rodrigues Magalhães
Leonardo Rodrigues <[hidden email]> schrieb am 21.07.20 um 08:44:21 Uhr:
> Em 20/07/2020 22:44, Viktor Dukhovni escreveu: > > If CentOS 8 requires a default floor of TLS 1.2, and have not patched > > Postfix to relax that system-default constraint, then you're stuck > > with TLS >= 1.2 until a suitable work-around is made available in > > their Postfix package. > > > > You nailed it, Viktor and Xavier, it was the default system-wide > setup on the CentOS 8 OS from fileppreciate > > /usr/share/crypto-policies/DEFAULT/opensslcnf.txt > > setting MinProtocol to TLSv1 there did the trick. This is good to know and makes the old android connecting again. Jul 23 13:26:07 dualbit1 postfix/smtpd[1623800]: Anonymous TLS connection established from p57b242ae.dip0.t-ipconnect.de[87.178.66.174]: TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits) > > Thank you guys! Yes, very much appreciated! Andreas |
Free forum by Nabble | Edit this page |