from:"Ján Máté"

Re: SNI problem - the client side

2020-06-14 Thread Ján Máté

Hi all,

just for info: new Postfix MTA-STS resolver package was released - 
https://github.com/Snawoot/postfix-mta-sts-resolver/pull/64 
<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"), 
so SNI will now work also with MTA-STS enabled servers (as required by RFC) :-) 
... Viktor thanks for your help!

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 used: "smtpd_tls_eecdh_grade = ultra".

Check Google for "smtpd_tls_eecdh_grade = ultra" and you will find a ton of 
"tuning security" manuals that recommend this setting :-))) 

Cheers,

JM

> On 13 Jun 2020, at 20:29, Ján Máté  wrote:
> 
> 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/postfix_mta_sts_resolver# 
> diff -u responder.py-orig responder.py 
> --- responder.py-orig 2020-04-11 22:40:55.0 +0200
> +++ responder.py  2020-06-13 20:15:00.377112967 +0200
> @@ -219,7 +219,7 @@
>  else:
>  assert cached.pol_body['mx'], "Empty MX list for restrictive 
> policy!"
>  mxlist = [mx.lstrip('*') for mx in 
> set(cached.pol_body['mx'])]
> -resp = "OK secure match=" + ":".join(mxlist)
> +resp = "OK secure servername=hostname match=" + 
> ":".join(mxlist)
>  return netstring.encode(resp.encode('utf-8'))
>  else:
>  return netstring.encode(b'NOTFOUND ')
>

Re: SNI problem - the client side

2020-06-13 Thread Ján Máté

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 for the domain, then it is broken.  If however,
>>> DANE records are not present, then the MTA-STS service MUST instead
>>> return one of ...
> 
> In retrospect my comment doesn't quite apply to the way that MTA-STS is
> integrated into Postfix.  It is either a NOOP or mapped to "strict", so
> the only downgrade risk is DNSSEC -> WebPKI, and while in my view that's
> is a downgrade, obtaining unauthorised certs for the target MX is not
> going to be a common attack vector for most senders to worry about.

Re: SNI problem - the client side

2020-06-13 Thread Ján Máté

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/postfix_mta_sts_resolver# diff 
-u responder.py-orig responder.py 
--- responder.py-orig   2020-04-11 22:40:55.0 +0200
+++ responder.py2020-06-13 20:15:00.377112967 +0200
@@ -219,7 +219,7 @@
 else:
 assert cached.pol_body['mx'], "Empty MX list for restrictive 
policy!"
 mxlist = [mx.lstrip('*') for mx in set(cached.pol_body['mx'])]
-resp = "OK secure match=" + ":".join(mxlist)
+resp = "OK secure servername=hostname match=" + 
":".join(mxlist)
 return netstring.encode(resp.encode('utf-8'))
 else:
 return netstring.encode(b'NOTFOUND ')

And related to:

> If the MTA-STS policy table service overrides DANE policy in the
> presence of TLSA records for the domain, then it is broken.  If however,
> DANE records are not present, then the MTA-STS service MUST instead
> return one of ...


I don't know what is the correct answer if the destination server uses both 
DANE and MTA-STS ... which one should be used, DANE or MTA-STS? The current 
behaviour is that MTA-STS is used, because "smtp_tls_policy_maps" overwrites 
the default "smtp_tls_security_level = dane".


Cheers,


JM


> On 13 Jun 2020, at 20:09, Viktor Dukhovni  wrote:
> 
> 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.example
>match=mx2.example
>...
> 
> where the list of match values is per the MTA-STS policy.  With
> "match=hostname" you lose the MTA-STS out-of-band (i.e. HTTPS)
> validation of the list of allowed MX hosts.
> 
> The explict list names is not strictly the same as MTA-STS, since it
> will allow matching of "mx2" while trying to connect to (and logging
> delivery via) "mx1", but should not be a concern, an MiTM can always
> force connections to a given MX host by blocking access to the rest, and
> can redirect TCP traffic, ...  so the only effect is somewhat imprecise
> logging.
> 
> -- 
>Viktor.

Re: SNI problem

2020-06-09 Thread Ján Máté

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 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:1426D121:SSL routines:ssl_set_cert_and_key:not replacing 
>>> certificate:../ssl/ssl_rsa.c:1107:
>> 
>> The second message is the real problem, OpenSSL believes it already has
>> a certificate loaded for that algorithm, which should not be the case.
>> The new key then does not match the already installed certificate.  But
>> there shouldn't be one already loaded.
> 
> Amazingly enough the issue seems to be caused by an obsolete, and
> seemingly unrelated setting in the OP's main.cf file:
> 
>   smtpd_tls_eecdh_grade = ultra
> 
> 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 rather a deep mystery I shall pursue
> with the OpenSSL team.
> 
> The OP also has other excessive fine-tuning of the TLS stack that
> is somewhat counter-productive.
> 
>  * 4096 bit RSA cert
>  * TLS 1.0 disabled
>  * Overly specific cipherlist
>  * ...
> 
> For SMTP, try to have modest, but broadly interoperable expectations
> of security that raise the ceiling rather than the floor.
> 
>   https://tools.ietf.org/rfc7435
> 
> -- 
>   Viktor.
>

Re: SNI problem

2020-06-09 Thread Ján Máté

Ups,

the correct

openssl s_client -servername smtp.example.com -starttls smtp -connect 
smtp.example.com:25 <http://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 alert number 80
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 326 bytes and written 726 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---


JM


> On 9 Jun 2020, at 22:36, Ján Máté  wrote:
> 
> 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, "/etc/aliases.db", O_RDONLY) = 12
> openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 13
> openat(AT_FDCWD, "/etc/DB_CONFIG", O_RDONLY) = -1 ENOENT (No such file or 
> directory)
> openat(AT_FDCWD, "/etc/aliases.db", O_RDONLY) = 13
> openat(AT_FDCWD, "/etc/aliases.db", O_RDONLY) = 14
> openat(AT_FDCWD, "/usr/lib/postfix/postfix-ldap.so", O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/usr/lib/postfix/libldap_r-2.4.so.2", O_RDONLY|O_CLOEXEC) = 
> -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libldap_r-2.4.so.2", 
> O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/usr/lib/postfix/liblber-2.4.so.2", O_RDONLY|O_CLOEXEC) = 
> -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/liblber-2.4.so.2", 
> O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgnutls.so.30", O_RDONLY|O_CLOEXEC) 
> = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libp11-kit.so.0", O_RDONLY|O_CLOEXEC) 
> = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 
> 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libunistring.so.2", 
> O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libtasn1.so.6", O_RDONLY|O_CLOEXEC) = 
> 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnettle.so.6", O_RDONLY|O_CLOEXEC) 
> = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libhogweed.so.4", O_RDONLY|O_CLOEXEC) 
> = 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgmp.so.10", O_RDONLY|O_CLOEXEC) = 
> 12
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libffi.so.6", O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/etc/host.conf", O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 12
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2", 
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 12
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgssapi_krb5.so.2", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libkrb5.so.3", O_RDONLY|O_CLOEXEC) = 
> 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libk5crypto.so.3", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libcom_err.so.2", O_RDONLY|O_CLOEXEC) 
> = 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libkrb5support.so.0", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libkeyutils.so.1", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libntlm.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libscram.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libsasldb.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libgs2.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/etc/gss/mech.d", 
> O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so", 
> O_RDONLY|O_CLOEXEC) = 15
> openat(AT_FDCWD, "/usr/lib/x86_64-linux-g

Re: SNI problem

2020-06-09 Thread Ján Máté

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, "/etc/aliases.db", O_RDONLY) = 12
openat(AT_FDCWD, "/sys/devices/system/cpu/online", O_RDONLY|O_CLOEXEC) = 13
openat(AT_FDCWD, "/etc/DB_CONFIG", O_RDONLY) = -1 ENOENT (No such file or 
directory)
openat(AT_FDCWD, "/etc/aliases.db", O_RDONLY) = 13
openat(AT_FDCWD, "/etc/aliases.db", O_RDONLY) = 14
openat(AT_FDCWD, "/usr/lib/postfix/postfix-ldap.so", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/usr/lib/postfix/libldap_r-2.4.so.2", O_RDONLY|O_CLOEXEC) = 
-1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libldap_r-2.4.so.2", 
O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/usr/lib/postfix/liblber-2.4.so.2", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/liblber-2.4.so.2", O_RDONLY|O_CLOEXEC) 
= 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgnutls.so.30", O_RDONLY|O_CLOEXEC) = 
12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libp11-kit.so.0", O_RDONLY|O_CLOEXEC) = 
12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libidn2.so.0", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libunistring.so.2", O_RDONLY|O_CLOEXEC) 
= 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libtasn1.so.6", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnettle.so.6", O_RDONLY|O_CLOEXEC) = 
12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libhogweed.so.4", O_RDONLY|O_CLOEXEC) = 
12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgmp.so.10", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libffi.so.6", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/etc/host.conf", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/etc/resolv.conf", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 12
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libcrammd5.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libgssapiv2.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libgssapi_krb5.so.2", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libkrb5.so.3", O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libk5crypto.so.3", O_RDONLY|O_CLOEXEC) 
= 15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libcom_err.so.2", O_RDONLY|O_CLOEXEC) = 
15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libkrb5support.so.0", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libkeyutils.so.1", O_RDONLY|O_CLOEXEC) 
= 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libntlm.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libscram.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libsasldb.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libgs2.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/etc/gss/mech.d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) 
= 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libdigestmd5.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libanonymous.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/liblogin.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libcrypt.so.1", O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2/libplain.so", 
O_RDONLY|O_CLOEXEC) = 15
openat(AT_FDCWD, "/etc/ldap/ldap.conf", O_RDONLY) = 12
openat(AT_FDCWD, "ldaprc", O_RDONLY)= -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/postfix/tables/ldap-virtual_alias_maps", O_RDONLY) = 12
openat(AT_FDCWD, "/etc/postfix/tables/ldap-virtual_alias_maps-alternate", 
O_RDONLY) = 12
openat(AT_FDCWD, "/etc/postfix/tables/ldap-virtual_mailbox_maps", O_RDONLY) = 12
openat(AT_FDCWD, "/usr/lib/postfix/postfix-pcre.so", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/usr/lib/postfix/libpcre.so.3", O_RDONLY|O_CLOEXEC) = -1 
ENOENT (No such file or directory)
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libpcre.so.3", O_RDONLY|O_CLOEXEC) = 12
openat(AT_FDCWD, "/etc/postfix/tables/pcre-check_helo_access", O_RDONLY) = 12
openat(AT_FDCWD, "/etc/postfix/sasl/smtpd.conf", O_RDONLY) = 12
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/sasl2", 
O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 12
openat(AT_FDCWD, "/dev/urandom", O_RDONLY) = 15
openat(AT_FDCWD, "/etc/postfix/tables/hash-tls_server_sni_maps.db", O_RDONLY) = 
12
openat(AT_FDCWD,

Re: SNI problem

2020-06-09 Thread Ján Máté

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 preloaded into each new SSL_CTX.

It looks like SNI works for you, but I cannot get it working - and tried really 
hard for more than a week (I read everything I found on Google and it looks 
like there are few people with working setup, and the remaining say that it 
does not work) :-/

Any idea how to debug it myself? ... or even better - I can allow you root 
access to the test server to check it yourself (just send me a private e-mail 
with your ssh public key).


Many thanks!


JM


> On 9 Jun 2020, at 19:07, Viktor Dukhovni  wrote:
> 
> 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 there it works).
> 
> This is the symptom, the cause is indicated by the message one logged
> next to it.
> 
>> /etc/postfix/main.cf:
>> tls_server_sni_maps = hash:/etc/postfix/table_hash-tls_server_sni_maps
>> smtpd_tls_chain_files =
>>/etc/letsencrypt/live/eu.server.smtp/privkey.pem
>>/etc/letsencrypt/live/eu.server.smtp/fullchain.pem
>> 
>> /etc/postfix/table_hash-tls_server_sni_maps
>> smtp.myserver.eu /etc/letsencrypt/live/eu.myserver.smtp/privkey.pem 
>> /etc/letsencrypt/live/eu.myserver.smtp/fullchain.pem
>> smtp.myserver2.eu /etc/letsencrypt/live/eu.myserver2.smtp/privkey.pem 
>> /etc/letsencrypt/live/eu.myserver2.smtp/fullchain.pem
> 
> I just tested with:
> 
>main.cf:
>smtpd_tls_loglevel = 1
>smtpd_tls_security_level = may
>smtpd_tls_chain_files =
>${config_directory}/ee1pkey.pem
>${config_directory}/ee1cert.pem
>${config_directory}/cacert.pem
>tls_server_sni_maps = hash:${config_directory}/sni
> 
>sni
>mx1.example.com
>.../ee1pkey.pem
>.../ee1cert.pem
>.../cacert.pem
>mx2.example.com
>.../ee2pkey.pem
>.../ee2cert.pem
>.../cacert.pem
> 
> My logs below...
> 
>> May 26 22:38:58 myserver postfix/smtpd[72379]: maps_file_find: 
>> tls_server_sni_maps: 
>> hash:/etc/postfix/table_hash-tls_server_sni_maps(0,lock|fold_fix|src_rhs_is_file):
>>  smtp.myserver.eu <http://smtp.myserver.eu/> = 
>> LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUpRd0lCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQ1Mwd2dna3BBZ0VBQW9J...
> 
> You generally don't want to log this data (your log level is too high),
> and should not publish it, it is liable to reveal part of your private
> key, though luckily, in this case, only some of the fixed header bits
> and none of the key material.
> 
>> 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:1426D121:SSL routines:ssl_set_cert_and_key:not replacing 
>> certificate:../ssl/ssl_rsa.c:1107:
> 
> The second message is the real problem, OpenSSL believes it already has
> a certificate loaded for that algorithm, which should not be the case.
> The new key then does not match the already installed certificate.  But
> there shouldn't be one already loaded.
> 
>> May 26 22:38:58 myserver postfix/smtpd[72379]: warning: error loading 
>> private keys and certificates from: SNI data for smtp.myserver.eu: aborting 
>> TLS handshake
> 
> And so things go wrong.  On the other hand, my logs show:
> 
>postfix/postfix-script[95733]: starting the Postfix mail system
>postfix/master[95735]: daemon started -- version 3.6-20200511, 
> configuration /var/tmp/postfix/etc
> 
>-- No SNI servername used
>postfix/smtpd[95756]: connect from localhost[127.0.0.1]
>postfix/smtpd[95756]: Anonymous TLS connection established from 
> localhost[127.0.0.1]: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 
> bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest 
> SHA256
>postfix/smtpd[95756]: disconnect from localhost[127.0.0.1] ehlo=1 
> starttls=1 quit=1 commands=3
> 
>-- SNI servername: mx1.example.com
>postfix/smtpd[95756]: connect from localhost[127.0.0.1]
>postfix/smtpd[95756]: Anonymous TLS connection established fro

SNI problem

2020-05-26 Thread Ján Máté

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 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 there it works).

Related config files:

/etc/postfix/main.cf:
tls_server_sni_maps = hash:/etc/postfix/table_hash-tls_server_sni_maps
smtpd_tls_chain_files =
/etc/letsencrypt/live/eu.server.smtp/privkey.pem
/etc/letsencrypt/live/eu.server.smtp/fullchain.pem

/etc/postfix/table_hash-tls_server_sni_maps (indexed using: postmap 
-F hash:/etc/postfix/table_hash-tls_server_sni_maps):
smtp.myserver.eu  
/etc/letsencrypt/live/eu.myserver.smtp/privkey.pem 
/etc/letsencrypt/live/eu.myserver.smtp/fullchain.pem
smtp.myserver2.eu  
/etc/letsencrypt/live/eu.myserver2.smtp/privkey.pem 
/etc/letsencrypt/live/eu.myserver2.smtp/fullchain.pem


Key+cert+chain hash info (the fullchain.pem file contains the cert.pem + 
chain.pem):
=== privkey.pem
ee key hash
(stdin)= b6dae1eecaa9a2b366b2acddf2ea2cfcec4fe8132ad2e8147be487b0ef241fc3
ee cert pubkey hash
(stdin)= -NONE-
ee chain names

=== cert.pem
ee key hash
(stdin)= -NONE-
ee cert pubkey hash
(stdin)= b6dae1eecaa9a2b366b2acddf2ea2cfcec4fe8132ad2e8147be487b0ef241fc3
ee chain names
subject=CN = smtp.myserver.eu 
issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

=== chain.pem
ee key hash
(stdin)= -NONE-
ee cert pubkey hash
(stdin)= 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18
ee chain names
subject=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
issuer=O = Digital Signature Trust Co., CN = DST Root CA X3



Info related to my testing:

Connection to Postfix from a remote server (client) using the correct 
"servername" in the SNI:

root@otherserver:~# openssl s_client -servername smtp.myserver.eu 
 -starttls smtp -connect smtp.myserver.eu:25 

CONNECTED(0003)
140179153458304:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert 
internal error:../ssl/record/rec_layer_s3.c:1544:SSL alert number 80
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 335 bytes and written 726 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---

Postfix server logs (server):

May 26 22:38:58 myserver postfix/smtpd[72379]: maps_file_find: 
tls_server_sni_maps: 
hash:/etc/postfix/table_hash-tls_server_sni_maps(0,lock|fold_fix|src_rhs_is_file):
 smtp.myserver.eu  = 
LS0tLS1CRUdJTiBQUklWQVRFIEtFWS0tLS0tCk1JSUpRd0lCQURBTkJna3Foa2lHOXcwQkFRRUZBQVNDQ1Mwd2dna3BBZ0VBQW9J...
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:1426D121:SSL routines:ssl_set_cert_and_key:not replacing 
certificate:../ssl/ssl_rsa.c:1107:
May 26 22:38:58 myserver postfix/smtpd[72379]: warning: error loading private 
keys and certificates from: SNI data for smtp.myserver.eu 
: aborting TLS handshake



Connection to Postfix from a remote server (client) without SNI servername (or 
SNI name not present in the tls_server_sni_maps):

root@otherserver:~# openssl s_client -noservername -starttls smtp -connect 
smtp.myserver.eu:25 
CONNECTED(0003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify return:1
depth=0 CN = smtp.myserver.eu 
verify return:1
---
Certificate chain
 0 s:CN = smtp.myserver.eu 
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-BEGIN CERTIFICATE-
...
...
...
-END CERTIFICATE-
subject=CN = smtp.myserver.eu 

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: ECDH, P-384, 384 bits
---
SSL handshake has read 4013 bytes and written 744 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 4096 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No

Re: SNI problem - the client side

Re: SNI problem - the client side

Re: SNI problem - the client side

Re: SNI problem

Re: SNI problem

Re: SNI problem

Re: SNI problem

SNI problem

8 matches

Site Navigation

Mail list logo

Footer information