Re: SNI problem

[Viktor Dukhovni]

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 mattered, and then it was
just a matter of adding one setting at a time, until the SNI chain
failed to load.  After that a bunch of head- scratching as to why the
EECDH grade would matter, but no longer requiring a remote system to
find how to reproduce.

> I had the "smtpd_tls_eecdh_grade" set to "strong", after removing it from
> the main.cf file and letting it default I can verify that the starttls sni
> all works on my servers.

That's of course a good idea, with or without the bug, for which the
real fix is one of the upcoming releases, even with the EECDH grade
set to "auto", HRR might happen anyway, just far less likely.  So
upgrade when a patch release is available for your system.

-- 
Viktor.

Re: SNI problem - the client side

[Wietse Venema]

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 the
> > only person who used: "smtpd_tls_eecdh_grade = ultra".
> 
> It will be included only in the SUPPORTED releases.

That will be Postfix 3.4 and 3.5. There was no inbound SNI support
in Postfix 3.3 and 3.2.

Wietse 

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 the
> only person who used: "smtpd_tls_eecdh_grade = ultra".

It will be included only in the SUPPORTED releases.

Wietse

Re: SNI problem - the client side

[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 
 (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

[Viktor Dukhovni]

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 RRs.

Postfix would need a more expressive policy syntax for that.

-- 
Viktor.

Re: SNI problem - the client side

[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

[Viktor Dukhovni]

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 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 ')

Yes, that should do the trick.

> > 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.

-- 
Viktor.

Re: SNI problem - the client side

[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 - the client side

[Viktor Dukhovni]

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 - the client side

[Viktor Dukhovni]

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.html#client_tls_policy

may
Opportunistic TLS. The optional "ciphers", "exclude" and "protocols"
attributes (available for opportunistic TLS with Postfix ≥ 2.6) override
the "smtp_tls_ciphers", "smtp_tls_exclude_ciphers" and
"smtp_tls_protocols" configuration parameters. At this level and higher,
the optional "servername" attribute (available with Postfix ≥ 3.4)
overrides the global "smtp_tls_servername" parameter, enabling
per-destination configuration of the SNI extension sent to the remote
SMTP server. 

> postfix-mta-sts-resolver return value for "smtp_tls_policy_maps" is "secure 
> match=smtp.infcloud.com":

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:

verify servername=hostname
   or
secure servername=hostname match=hostname

The only difference (a mistake on my part in retrospect) between
"verify" and "secure" is that "secure" defaults to matching the
"nexthop" domain, while "verify" defaults to matching the MX "hostname".
These cases should probably not have been two separate levels.

> and postfix does not send SNI if smtp_tls_security_level is "secure".

By default, for backwards compatibility, but it does if either there's
a policy setting for "servername" or "smtp_tls_servername" is set in
main.cf.

http://www.postfix.org/postconf.5.html#smtp_tls_servername

> So the question is rather simple - how to force Postfix to use SNI for 
> "secure" smtp_tls_security_level only.

Fix the MTA-STS socketmap server to return the requisite (i.e.
"hostname") setting for the "servername" policy parameter.

> And the good solution is maybe to add another security level called
> "secure-sni", which will send SNI as required by MTA-STS.

Not needed.

-- 
Viktor.

Re: SNI problem

[Nikolai Lusan]

-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. if you had
more than one hostname in the TLS cert - as in the case of a letsencrypt
wildcard cert - only first name was being matched). Turns out I was wrong,
but I hadn't had the time to sit down and properly debug the issue.

I had the "smtpd_tls_eecdh_grade" set to "strong", after removing it from
the main.cf file and letting it default I can verify that the starttls sni
all works on my servers.


On Tue, 2020-06-09 at 19:22 -0400, 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
> 
- -- 
Nikolai Lusan 
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEVfd4GW6z4nsBxdLo4ZaDRV2VL6QFAl7jnRAACgkQ4ZaDRV2V
L6QovQ/9GhBj69ncJVApi6vKtGUvY5lxe/Epff5knj49LTh1c+s1gN3VWMowvYwz
hmXkZQeeA5s/5m1Lp3W+3ZAeyIjoGqP4MQNfrNjQB+HtK6sdq/eVD55saRBAn8Lx
mIRCmfvEK0HeojL2PEVpW3SI/39Hzs9DqyNkFBu4l1d8x1GFf2abSgewBBGye9Zo
J+nORi6Hf1jBHCj/euuFGrr5N1nSNKq/lpP4bGXJxTKH0nwEEazIAhp+C8xdbgry
UOZyLJvmuwMIQk/MUb7q4NU/XdjLW95GAugkg+8pFdcdkF08c+TO2ARwNuJPzQRm
XNgd+VyV8uhrP4+DoVc0aL+76tmSu3lchap8HYLSxq+H+WhgOdKTCrBsQl1rw9od
vUJ62BqI9a/7lskYu6yT1tjhgGjle4S8stDXln1efKQfTLuX/q17xqjLR0RRCHod
gaoDERDsYJAOriMlG3KzTO96kTDNtqJT41LPIG188XUb6zQ9r+0vpoyU65HKugNx
Lv0HApEsvEo25BIWSsMbTALX2mr62IJQ7K3AqyafZYDGdg+H06aOhBj5dQRlr6QF
0Pys7yp4KMJoy/kqwanQI9Rd1EtDW5+L97qyARmqtQ2TdOmxOL8ayte5spF/c9Ks
4SWCcMMFifSJ34xfZ48nwtZCampOAM/3aHlb3LweN+FB6bQaaIA=
=o4N+
-END PGP SIGNATURE-

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

[Wietse Venema]

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
> > of RSA certificate chains is rather a deep mystery I shall pursue
> > with the OpenSSL team.
> 
> Turns out the problem is that my SNI code in Postfix did not expect
> to be called twice for the same connection as happens with TLS 1.3
> HRR (hello retry requests) when the client's key share guess does
> not match the server's supported signature algorithms (e.g. only P384
> with "smtpd_tls_eecdh_grade = ultra").
> 
> Git commit at:
> 
>   
> https://github.com/vdukhovni/postfix/commit/851b525c5c09405c48b8cd697d14cb0d2edbb68b
> 
> Raw patch:
> 
>   
> https://github.com/vdukhovni/postfix/commit/851b525c5c09405c48b8cd697d14cb0d2edbb68b.patch
> 
> This applies to Postfix 3.4, 3.5 and 3.6 snapshots.

Released in postfix-3.6-20200610. Stable releases will be updated
after the code has been running for a few days.

Wietse

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
> of RSA certificate chains is rather a deep mystery I shall pursue
> with the OpenSSL team.

Turns out the problem is that my SNI code in Postfix did not expect
to be called twice for the same connection as happens with TLS 1.3
HRR (hello retry requests) when the client's key share guess does
not match the server's supported signature algorithms (e.g. only P384
with "smtpd_tls_eecdh_grade = ultra").

Git commit at:

  
https://github.com/vdukhovni/postfix/commit/851b525c5c09405c48b8cd697d14cb0d2edbb68b

Raw patch:

  
https://github.com/vdukhovni/postfix/commit/851b525c5c09405c48b8cd697d14cb0d2edbb68b.patch

This applies to Postfix 3.4, 3.5 and 3.6 snapshots.

-- 
Viktor.

Re: SNI problem

[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

[Viktor Dukhovni]

> 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

[Ján Máté]

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 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-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, 

Re: SNI problem

[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

[Viktor Dukhovni]

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 is any default certificate
> chain that might be preloaded into each new SSL_CTX.

Have you looked at that file?  Any mention of any default certificate
chain files there?

> 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).

Can you strace the SMTP server process?  Add a "-D" flag to the
smtpd(8) entry in master.cf after setting:

debugger_command =
PATH=/usr/bin:/bin:/usr/sbin:/sbin
strace -o /tmp/tr.$process_name.$process_id -p $process_id & sleep 1

Then 'grep open' in the trace file, looking for unexpected reads of
certificate chain files.

To get closer to your config, I just built Postfix 3.4.12, against
OpenSSL 1.1.1, which also works:

# postfix start
postfix/postfix-script: starting the Postfix mail system

# openssl s_client -CAfile rootcert.pem -servername mx1.example.com 
-starttls smtp -connect localhost:25 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx1.example.com
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK
Server Temp Key: X25519, 253 bits
250 CHUNKING
quit
221 2.0.0 Bye

# openssl s_client -CAfile rootcert.pem -servername mx2.example.com 
-starttls smtp -connect localhost:25 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx2.example.com
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK
Server Temp Key: X25519, 253 bits
250 CHUNKING
quit
221 2.0.0 Bye

# openssl s_client -CAfile rootcert.pem -servername mx1.example.com 
-starttls smtp -connect localhost:25 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx1.example.com
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK
Server Temp Key: X25519, 253 bits
250 CHUNKING
quit
221 2.0.0 Bye

# openssl s_client -CAfile rootcert.pem -servername mx2.example.com 
-starttls smtp -connect localhost:25 -brief
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN = mx2.example.com
Hash used: SHA256
Signature type: RSA-PSS
Verification: OK
Server Temp Key: X25519, 253 bits
250 CHUNKING
quit
221 2.0.0 Bye

# cat ../log/maillog
Jun 09 15:35:23 vpro postfix/postfix-script[2294]: starting the Postfix 
mail system
Jun 09 15:35:23 vpro postfix/master[2296]: daemon started -- version 
3.4.12, configuration /var/tmp/postfix/etc
Jun 09 15:35:28 vpro postfix/smtpd[2301]: connect from localhost[127.0.0.1]
Jun 09 15:35:28 vpro postfix/smtpd[2301]: Anonymous TLS connection 
established from localhost[127.0.0.1] to mx1.example.com: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
RSA-PSS (2048 bits) server-digest SHA256
Jun 09 15:35:30 vpro postfix/smtpd[2301]: disconnect from 
localhost[127.0.0.1] ehlo=1 starttls=1 quit=1 commands=3
Jun 09 15:35:31 vpro postfix/smtpd[2301]: connect from localhost[127.0.0.1]
Jun 09 15:35:31 vpro postfix/smtpd[2301]: Anonymous TLS connection 
established from localhost[127.0.0.1] to mx2.example.com: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
RSA-PSS (2048 bits) server-digest SHA256
Jun 09 15:35:33 vpro postfix/smtpd[2301]: disconnect from 
localhost[127.0.0.1] ehlo=1 starttls=1 quit=1 commands=3
Jun 09 15:35:34 vpro postfix/smtpd[2301]: connect from localhost[127.0.0.1]
Jun 09 15:35:34 vpro postfix/smtpd[2301]: Anonymous TLS connection 
established from localhost[127.0.0.1] to mx1.example.com: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature 
RSA-PSS (2048 bits) server-digest SHA256
Jun 09 15:35:35 vpro postfix/smtpd[2301]: disconnect from 
localhost[127.0.0.1] ehlo=1 starttls=1 quit=1 commands=3
Jun 09 15:35:37 vpro postfix/smtpd[2301]: connect from localhost[127.0.0.1]
Jun 09 15:35:37 vpro postfix/smtpd[2301]: Anonymous TLS connection 
established from localhost[127.0.0.1] to mx2.example.com: TLSv1.3 with cipher 
TLS_AES_256_GCM_SHA384 (256/256 bits) 

Re: SNI problem

[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  = 
>> 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 from 
> localhost[127.0.0.1] to mx1.example.com: 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: mx2.example.com
>postfix/smtpd[95756]: connect from 

Re: SNI problem

[Viktor Dukhovni]

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  = 
> 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 from 
localhost[127.0.0.1] to mx1.example.com: 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: mx2.example.com
postfix/smtpd[95756]: connect from localhost[127.0.0.1]
postfix/smtpd[95756]: Anonymous TLS connection established from 
localhost[127.0.0.1] to mx2.example.com: 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

> In short: if a connection from the client is performed without SNI (or
> SNI hostname not present in the tls_server_sni_maps) then everything
> works as expected (key+cert+chain from smtpd_tls_chain_files is used),
> but if I connect using a valid SNI hostname (the new
> tls_server_sni_maps is used) then the same key+cert+chain not works.

It seems that somehow, a certificate of the same type is already loaded
into the SSL handle under construction.  It is unclear how that
happened.

> postmap -Fq smtp.myserver.eu hash:/etc/postfix/table_hash-tls_server_sni_maps
> 
> returns the correct 

SNI problem

[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