[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
On Mon, May 08, 2023 at 04:22:29PM -0500, E R via Postfix-users wrote: > Thank you so much for the suggestion to review the crypto setting as this > indeed a RedHat based distribution. I confirmed it is set to "default" > which means “The default system-wide cryptographic policy level offers > secure settings for current threat models. It allows the TLS 1.2 and 1.3 > protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and > Diffie-Hellman parameters are accepted if they are at least 2048 bits long.” Right, but the meaning of "DEFAULT" (e.g., whether SHA-1 signatures are accepted in certificates and TLS messages) may vary from release to release. In Fedora 36 default allows SHA-1 signatures, but I've seen documentation that suggests that in RHEL the default policy is more strict. You should be able to set your policy to allow SHA1: # update-crypto-policies --set DEFAULT:SHA1 (no need to reboot, Postfix processes that use OpenSSL are not long-lived). > The [I assume client] system in question was located and is an older > than dirt system running a LONG obsolete version of Gentoo. My best > guess is that the system was accidentally powered on during a > generator test due to a former employee not properly decommissioning > the system many years ago. The configuration change that I wrote > about (disabling the STARTTLS keyword for the IP address) did allow my > Postfix gateways to route email without any issue. I am going to > guess the age or configuration of the system is to blame. I have > started the official process to pull the plug on the server so it can > be wiped and recycled. The system was very likely using TLS 1.0, and had no support for TLS 1.2 or later, so yes, quite old by now. You may still consider whether disabling SHA1 signatures is really the right policy for an MTA. If you've never seen that error message in your logs apart from the client in questions, perhaps the default is good enough. Otherwise, enabling SHA1 will in practice be fine, and enable some legacy systems to establish TLS connections that would otherwise have to fall back to cleartext (or fail to deliver mail). -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: working around crypto policies turned up to 11
On Mon, May 08, 2023 at 06:13:25PM -0400, Wietse Venema via Postfix-users wrote: > We're thinking of adding a few new settings to the stable Postfix > releases that allow Postfix to regain some control over crypto > policies that do not necessarily improve matters for SMTP where > the main result would be more plaintext communication. > With stable releases, it would not be approprriate to introduce a > boatload of features, but plausible candidates are: > > tls_config_file = default | none(*) | /path/to/file > (*)only OpenSSL 1.1.b and later Minor correction, the base OpenSSL release that supports configuration file overrides is "1.1.1b", rather than "1.1.b". - The minimum OpenSSL version supported by Postfix 3.6 and later is 1.1.1. - The OpenSSL version in which RedHat started introducing strict crypto policies is OpenSSL 3.0. This means that: - If you're still using OpenSSL 1.0.2 (with Postfix <= 3.5) you probably don't need to override the system-wide openssl.cnf file. Though it may be possible to use: import_environment = ... default value from "postconf -d"... OPENSSL_CONF=/some/file An empty file would be equivalent to "none". - If you're using OpenSSL 1.1.1 or 1.1.1a, you also probably don't need to override the system-wide openssl.cnf file. Same work-around as before, or set the application name, and add appropriate application settings in the system-wide file. - If you're using OpenSSL 1.1.1b or later, and in particular 3.0 or, especially on a RedHat or Fedora system, you may choose to override the system-wide configuration file or the application name. Then, overly strict cryptographic policy will not result in unnecessary downgrades to cleartext in opportunistic TLS. We'll probably later have to extend support for tweaking additional TLS-related settings through the "SSL_CONF" API, though that will have the downside that non-expert users may end up cargo culting settings that do more harm than good. I'll try to discourage this as much as possible, but the target audience will be those who know what they are doing, or are following sound advice. One goal may be to make some of the crypto hardening conditional on the TLS security level, which means different settings for different levels. Hopefully more on this as 3.9 snapshots evolve. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] working around crypto policies turned up to 11
We're thinking of adding a few new settings to the stable Postfix releases that allow Postfix to regain some control over crypto policies that do not necessarily improve matters for SMTP where the main result would be more plaintext communication. With stable releases, it would not be approprriate to introduce a boatload of features, but plausible candidates are: tls_config_file = default | none(*) | /path/to/file (*)only OpenSSL 1.1.b and later tls_config_appname = (some string, maybe 'postfix') These settings control where, if at all, the OpenSSL library gets is 'ini' settings from. 'Default' means surrender to the system configuration, /path/to/file gives more control but may leave Postfix marooned on its own island, and a Postfix-specific appname would allow Postfix to have settings of its own in a shared configuration. In the development release we can then figure out if Postfix programs should be able to poke configuration settings from main.cf into the OpenSSL library. Wietse ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
The /usr/share/crypto-policies/DEFAULT/opensslcnf.txt on RHEL 9 looks identical to what you posted for Fedora. I am not a RHEL expert but I have not see any references to opt out of the crypto policy on a per application basis. You can customize an existing crypto policy or create your own. I think as long as people are follow best practices of running Postfix on a dedicated system they should be able to tweak the system-wide policy should they really need to do so, absent any options for granular application configuration. Comparing the DEFAULT policy with the LEGACY policy seems to reduce the security of the system by allowing "..SHA-1 in the TLS hash, signature and algorithm. CBC-mode ciphers are allowed to be used with SSH. Applications using GNUTLS allow certificates with SHA-1" Other than this the TLS, IKEv2, SSH2 protocols are the same as DEFAULT. The RSA keys and Diffie-Hellman parameters are also the same. On Fri, May 5, 2023 at 8:30 PM Viktor Dukhovni via Postfix-users < postfix-users@postfix.org> wrote: > On Fri, May 05, 2023 at 08:28:48PM -0400, Viktor Dukhovni via > Postfix-users wrote: > > > You should of course also share ( > https://www.postfix.org/DEBUG_README.html#mail) > > > > $ postconf -nf > > $ postconf -Mf > > > > without any changes in whitespace, including line breaks. Attaching > > these as text files may be simplest if your mail client won't coöperate. > > And, if applicable, post the content of: > > /usr/share/crypto-policies/DEFAULT/opensslcnf.txt > > Which on a sample Fedora36 system holds: > > CipherString = > @SECLEVEL=2:kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:kRSAPSK:-aDSS:-3DES:!DES:!RC4:!RC2:!IDEA:-SEED:!eNULL:!aNULL:!MD5:-SHA384:-CAMELLIA:-ARIA:-AESCCM8 > Ciphersuites = > TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256 > TLS.MinProtocol = TLSv1.2 > TLS.MaxProtocol = TLSv1.3 > DTLS.MinProtocol = DTLSv1.2 > DTLS.MaxProtocol = DTLSv1.2 > SignatureAlgorithms = > ECDSA+SHA256:ECDSA+SHA384:ECDSA+SHA512:ed25519:ed448:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:RSA+SHA256:RSA+SHA384:RSA+SHA512:ECDSA+SHA224:RSA+SHA224 > > [openssl_init] > alg_section = evp_properties > > [evp_properties] > rh-allow-sha1-signatures = yes > > Postfix (at least in a default configuration) is not affected by: > > CipherString > TLS.MinProtocol > TLS.MaxProtocol > DTLS.MinProtocol > DTLS.MaxProtocol > > But currently has no controls to override: > > # TLS 1.3 ciphersuites (not a priority to fine-tune) > Ciphersuites = ... > > # TLS 1.2 signature algorithm negotiation (the RH list is fine) > SignatureAlgorithms = ... > > # If this is set to "no", TLS 1.0 key exchange is likely to break. > # In some cases certificate verification may break. > rh-allow-sha1-signatures = yes > > I don't even know whether RedHat exposes any mechanisms for applications > to opt-out of crypto policy and use only application-driven OpenSSL > configuration. This is should perhaps be looked into in the Postfix 3.9 > timeframe. > > -- > 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
[pfx] Re: TLS Library Problem? (SSL_accept error from ...)
Thank you so much for the suggestion to review the crypto setting as this indeed a RedHat based distribution. I confirmed it is set to "default" which means “The default system-wide cryptographic policy level offers secure settings for current threat models. It allows the TLS 1.2 and 1.3 protocols, as well as the IKEv2 and SSH2 protocols. The RSA keys and Diffie-Hellman parameters are accepted if they are at least 2048 bits long.” Source: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening The system in question was located and is an older than dirt system running a LONG obsolete version of Gentoo. My best guess is that the system was accidentally powered on during a generator test due to a former employee not properly decommissioning the system many years ago. The configuration change that I wrote about (disabling the STARTTLS keyword for the IP address) did allow my Postfix gateways to route email without any issue. I am going to guess the age or configuration of the system is to blame. I have started the official process to pull the plug on the server so it can be wiped and recycled. On Fri, May 5, 2023 at 7:29 PM Viktor Dukhovni via Postfix-users < postfix-users@postfix.org> wrote: > On Fri, May 05, 2023 at 06:55:23PM -0500, E R via Postfix-users wrote: > > > postfix/smtpd[1234567]: SSL_accept error from > xxx.xxx.xxx[yyy.yyy.yyy.yyy]: -1 > > postfix/smtpd[1234567]: warning: TLS library problem: > > error:0398:digital envelope routines::invalid > digest:crypto/evp/m_sigver.c:343: > > postfix/smtpd[1234567]: warning: TLS library problem: > > error:0A0C0103:SSL routines::internal > error:ssl/statem/statem_srvr.c:2684: > > This problem may be worth further analysis. It appears that OpenSSL has > chosen a signature algorithm (public key algorithm + digest method, e.g. > RSA with SHA256, ...) at the TLS layer, but failed to initialise a > signature context at the crypto API layer. This is odd, because the > known TLS layer combinations should map to known crypto layer > primitives. > > Are you on a RedHat system perhaps? RedHat's latest releases have > turned up crypto policy to "11", and may refuse to, for example, support > RSA with SHA1. The remote client may have one of the really dated TLS > stacks that doesn't know how to do anything better. > > If your system is a RHEL or recent Fedora or similar system, or perhaps > by now other distributions have joined the club, then you'll to find the > relevant crypto policy file and dial it down a bit (on an MTA doing > opportunistic TLS, RSA with SHA1 is better than cleartext). > > Similar considerations may apply not only to MTAs but also to validating > DNS resolvers, and perhaps other applications. > > The various distributions may publish instructions on recommnded ways to > tune the crypto policy. > > If all the above is false lead, then the problem is more mysterious, and > perhaps a PCAP file capturing a failed handshake would be a good next > step. > > You should of course also share ( > https://www.postfix.org/DEBUG_README.html#mail) > > $ postconf -nf > $ postconf -Mf > > without any changes in whitespace, including line breaks. Attaching > these as text files may be simplest if your mail client won't coöperate. > > -- > 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
[pfx] Class-less Postfix challenges
Wietse Venema via Postfix-users:
> Sean Gallagher via Postfix-users:
> > ADDRESS_CLASS_README:
> >
> > The most misleading place for me was the ADDRESS_CLASS_README
> >
> > For "The virtual alias domain class" it says:
> > "Valid recipient addresses are listed with the virtual_alias_maps
> > parameter"
> > which is of course true, but there is nothing special about the virtual
> > alias domain class in that respect. After reading that readme, one could
> > be forgiven for thinking that the virtual_alias_maps would not be
> > applied to the other domain classes.
> >
> > The virtual_alias_maps parameter should at least be mentioned in the
> > recipient address text of the other domain class explanations.
> >
> > Perhaps another less confusing way to document it would be to describe a
> > "class-less" mode of operation that uses just the virtual_alias_maps and
> > transport_maps, and go on to say that class-full and class-less routing
> > can co-exist.
Sorry, I did not read that as empty mydestination, {virtual_alias,
virtual_mailbox, relay}_domains tables.
Such a class-less model would have a 'relay permission' problem,
unless arrangements are made to prevent that (in terms of current
Postfix features, with an access(5) table or with a list of certain
domains in relay_domains).
But then we no longer have a class-less system. Instead we have:
Class 1: Domains that any client can send to, and that have
recipient validation (to prevent backscatter).
Class 2: Domains that only authorized clients can send to, and that
don't have recipient valdation (no table exists for all
Internet users).
The above describes Postfix < 2.0 and qmail variants.
If someone thinks that the two-class model can be turned into a
maintainable configuration for general use, then they should do the
research and analysis. I should not do that, because I don't use
such a configureation.
Twenty years ago this two-class model was not a direction that I
chose to continue. Primary motivations were isolation: to isolate
the configuration of inbound relay deliveries from outbound smtp
deliveries, and to isolate the configuration of deliveries to local
and virtual_mailbox domains. This made Postfix configurations easier
to reason about than would have been possible with less isolation.
Wietse
___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
On Mon, May 08, 2023 at 12:33:31PM +1000, Sean Gallagher via Postfix-users wrote: > > [ Yes, one could also craft "classless" access(5) tables, ... and rely > >only on explicit transport(5) table entries, opting out of all the > >taxonomy that makes it easier to reason about Postfix mail routing, > >but this is not a good idea, and users advanced enough to do that > >aren't the audience for the README tutorials. ] > > With all due respect, there is no "advanced user" documentation, the > advanced users are reading the READMEs just like everyone else - or the > source code. The "advanced users" are doing OK between the README tutorials, the postconf(5) parameter docs and the source code. There's also the book by Patrick and Ralf as well as the O'Reilly book. One thing that's under-documented from an advanced user perspective is: - String, hostname and address match lists. - Which parameters are match lists and of which type. The description of match lists could be in DATABASE_README, with references from the various parameters as appropriate. Care to contribute some text? -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postfix and ssl provlem
Hi Exactly as you're saying - problem solved - CA cant load via aplications. W dniu 8.05.2023 o 15:31, Viktor Dukhovni via Postfix-users pisze: On Mon, May 08, 2023 at 01:29:55PM +0200, natan via Postfix-users wrote: I have some problem with cert - user who connect via 465 postfix/smtps/smtpd[6901]: warning: TLS library problem: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca: ../ssl/record/rec_layer_s3.c:1544:SSL alert number 48: Cert is new (renew) and openssl x509 -in ... and key is ok server and client not connect via ssl3 The client cannot validate your server's certificate chain. Perhaps you've deployed just the leaf certificate, rather than a "chain" with the leaf certificate plus intermediate issuing CA? https://datatracker.ietf.org/doc/html/rfc8446#page-89 unknown_ca: A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or could not be matched with a known trust anchor. -- ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postfix and ssl provlem
On Mon, May 08, 2023 at 01:29:55PM +0200, natan via Postfix-users wrote: > I have some problem with cert - user who connect via 465 > > postfix/smtps/smtpd[6901]: warning: TLS library problem: > error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca: > ../ssl/record/rec_layer_s3.c:1544:SSL alert number 48: > > Cert is new (renew) and openssl x509 -in ... and key is ok > server and client not connect via ssl3 The client cannot validate your server's certificate chain. Perhaps you've deployed just the leaf certificate, rather than a "chain" with the leaf certificate plus intermediate issuing CA? https://datatracker.ietf.org/doc/html/rfc8446#page-89 unknown_ca: A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or could not be matched with a known trust anchor. -- Viktor. ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: postfix and ssl provlem
Hi Problem is only via web aplications (php) W dniu 8.05.2023 o 13:29, natan via Postfix-users pisze: Hi I have some problem with cert - user who connect via 465 postfix/smtps/smtpd[6901]: warning: TLS library problem: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:../ssl/record/rec_layer_s3.c:1544:SSL alert number 48: Debian10 Cert is new (renew) and openssl x509 -in ... and key is ok server and client not connect via ssl3 Any idea ? -- ___ 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
[pfx] postfix and ssl provlem
Hi I have some problem with cert - user who connect via 465 postfix/smtps/smtpd[6901]: warning: TLS library problem: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca:../ssl/record/rec_layer_s3.c:1544:SSL alert number 48: Debian10 Cert is new (renew) and openssl x509 -in ... and key is ok server and client not connect via ssl3 Any idea ? -- ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
[pfx] Re: Postfix documentation pitfalls. virtual_alias_maps and main.cf macros
Viktor Dukhovni via Postfix-users writes: > (...) > [ Yes, one could also craft "classless" access(5) tables, ... and rely > only on explicit transport(5) table entries, opting out of all the > taxonomy that makes it easier to reason about Postfix mail routing, > but this is not a good idea, and users advanced enough to do that > aren't the audience for the README tutorials. ] Hellow Viktor, I strongly agree with you, thanks! Sincerely, Byung-Hee from South Korea -- ^고맙습니다 _布德天下_ 감사합니다_^))// ___ Postfix-users mailing list -- postfix-users@postfix.org To unsubscribe send an email to postfix-users-le...@postfix.org
