Re: SNI problem

On Sat, Jun 13, 2020 at 01:19:44AM +1000, Nikolai Lusan wrote: > Thank you very much for finding that. The OP provided a system on which I could compare: - Vendor Postfix vs. Postfix built from source - stock configs vs. OP's actual config. It turned out that the configuration was what

Re: SNI problem - the client side

Wietse Venema: > J?n M?t?: > > My last question is whether is it possible to include the Postfix > > TLSv1.3 patch in older versions of Postfix (minor bug fix release). > > The problem is that with enabled SNI in MTA-STS package, there > > will be lot of bug reports - because it looks like I am not

Re: SNI problem - the client side

J?n M?t?: > My last question is whether is it possible to include the Postfix > TLSv1.3 patch in older versions of Postfix (minor bug fix release). > The problem is that with enabled SNI in MTA-STS package, there > will be lot of bug reports - because it looks like I am not the > only person who us

Re: SNI problem - the client side

Hi all, just for info: new Postfix MTA-STS resolver package was released - https://github.com/Snawoot/postfix-mta-sts-resolver/pull/64 (cite the author: "I guess Debian packages will be available within a week in backports repo"), s

Re: SNI problem - the client side

On Sat, Jun 13, 2020 at 09:16:56PM +0200, Ján Máté wrote: > Now I understand ... is there any trick to ignore the > smtp_tls_policy_maps if valid TLSA entries from DNSSEC are returned? No. The policy lookup happens first, and when it returns a policy other than DANE, we don't even look for TLSA

Re: SNI problem - the client side

Hi Viktor, now I understand ... is there any trick to ignore the smtp_tls_policy_maps if valid TLSA entries from DNSSEC are returned? :-) JM > On 13 Jun 2020, at 21:05, Viktor Dukhovni wrote: > >>> If the MTA-STS policy table service overrides DANE policy in the >>> presence of TLSA records

Re: SNI problem - the client side

On Sat, Jun 13, 2020 at 08:29:20PM +0200, Ján Máté wrote: > I will report the bug to postfix-mta-sts-resolver developer - the > patch is rather simple: > > root@collegemate:/usr/lib/python3/dist-packages/postfix_mta_sts_resolver# > diff -u responder.py-orig responder.py > --- responder.py-orig

Re: SNI problem - the client side

Hi Viktor, thank you very much! Tested and confirmed ... it looks like there is a lot of untested software today, or I use all the special edge cases :-) I will report the bug to postfix-mta-sts-resolver developer - the patch is rather simple: root@collegemate:/usr/lib/python3/dist-packages/p

Re: SNI problem - the client side

On Sat, Jun 13, 2020 at 01:44:18PM -0400, Viktor Dukhovni wrote: > ... the MTA-STS service MUST instead return one of: > > verify servername=hostname >or > secure servername=hostname match=hostname I should have written: secure servername=hostname match=mx1.examp

Re: SNI problem - the client side

On Sat, Jun 13, 2020 at 06:24:02PM +0200, Ján Máté wrote: > but I found the problem and it will be hard to fix. Postfix TLS code sends > SNI only for DANE Actually, SNI is also sent when the policy table has a non-empty setting for the "servername" keyword: http://www.postfix.org/TLS_README

Re: SNI problem

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thank you very much for finding that. I have been having the same issue for months now, and was beginning to think I might have to resort to writing a patch to the SNI code which was seemingly not inspecting deep enough into the certificates (i.e.

Re: PATCH: Handle TLS 1.3 Hello retry requests (was: SNI problem)

Viktor Dukhovni: > > On Jun 9, 2020, at 7:22 PM, Viktor Dukhovni > > wrote: > > > > This predates support for automatic negotiated EC curve selection > > in OpenSSL, and is now just a bad idea. The default "auto" setting > > is the only correct one to use. That said, how this breaks loading >

PATCH: Handle TLS 1.3 Hello retry requests (was: SNI problem)

> On Jun 9, 2020, at 7:22 PM, Viktor Dukhovni > wrote: > > This predates support for automatic negotiated EC curve selection > in OpenSSL, and is now just a bad idea. The default "auto" setting > is the only correct one to use. That said, how this breaks loading > of RSA certificate chains is

Re: SNI problem

Hi Victor, many thanks for finding out the cause of the problem - I hope the information about smtpd_tls_eecdh_grade will be useful for other Postfix users! JM > On 10 Jun 2020, at 01:22, Viktor Dukhovni wrote: > > > >> On Jun 9, 2020, at 1:07 PM, Viktor Dukhovni >> wrote: >> >>> May 2

Re: SNI problem

> On Jun 9, 2020, at 1:07 PM, Viktor Dukhovni > wrote: > >> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: key at index 1 in >> SNI data for smtp.myserver.eu does not match next certificate >> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: TLS library problem: >> error:142

Re: SNI problem

Ups, the correct openssl s_client -servername smtp.example.com -starttls smtp -connect smtp.example.com:25 output: CONNECTED(0003) 140192932344960:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:../ssl/record/rec_layer_s3.c:1544:SSL al

Re: SNI problem

Hi Victor, yes, I looked at /etc/ssl/openssl.cnf and found nothing related to default or preloaded chain. See the result of the debug from strace - only 3 cert related files are opened = the private key, full chain and DH param: openat(AT_FDCWD, "pid/inet.smtp", O_RDWR) = 9 openat(AT_FDCWD, "/

Re: SNI problem

On Tue, Jun 09, 2020 at 08:31:27PM +0200, Ján Máté wrote: > Thanks for the explanation what's happening in the internals of > Postfix, but the problem is still a mystery for me ... > > I use the default Debian (Buster) /etc/ssl/openssl.cnf without any > modifications, so I don't think that there

Re: SNI problem

Hi Victor, thanks for the explanation what's happening in the internals of Postfix, but the problem is still a mystery for me ... I use the default Debian (Buster) /etc/ssl/openssl.cnf without any modifications, so I don't think that there is any default certificate chain that might be preload

Re: SNI problem

On Wed, May 27, 2020 at 12:40:25AM +0200, Ján Máté wrote: > The error is "SNI data for smtp.myserver.eu does not match next > certificate" even if I am 100% sure that the key+cert+chain is OK, > because I use the same key+cert+chain (loaded from same files) for the > smtpd_tls_chain_files (and the

SNI problem

Hi Postfix users, I have a problem with the new tls_server_sni_maps configuration option - it seems that Postfix (3.4.10 debian-buster) is unable to load the key+cert+chain combination using this option. The error is "SNI data for smtp.myserver.eu does not match next