DANE issue with postfix 3.4.0-RC2

classic Classic list List threaded Threaded
32 messages Options
12
Reply | Threaded
Open this post in threaded view
|

DANE issue with postfix 3.4.0-RC2

A. Schulze
Hello,

I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
Now I notice delivery problems to "gervers.com". DANE setup looks OK. https://dane.sys4.de/smtp/gervers.com

"posttls-finger gervers.com" also show
posttls-finger: Verified TLS connection established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

But a message to the domain is not delivered. Instead I found this logged by tlsproxy:

Feb 17 14:18:28 mail postfix/tlsproxy[14593]: sys1.mmini.de[5.9.100.168]:25: re-using session with untrusted certificate, look for details earlier in the log
Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

But I did not found anything special "earlier in the log" ...

Message was delivered immediately as I disabled smtp_tls_connection_reuse:
Feb 17 14:37:45 mail postfix/smtp[15157]: Verified TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

I could provide further information off-list.

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: DELIVERY issue with postfix 3.4.0-RC2

A. Schulze
Am 17.02.19 um 14:41 schrieb A. Schulze:
> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"

corrected the subject, as DANE is not necessary related here.
Reply | Threaded
Open this post in threaded view
|

Re: DANE issue with postfix 3.4.0-RC2

Wietse Venema
In reply to this post by A. Schulze
A. Schulze:

> Hello,
>
> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
> Now I notice delivery problems to "gervers.com". DANE setup looks OK. https://dane.sys4.de/smtp/gervers.com
>
> "posttls-finger gervers.com" also show
> posttls-finger: Verified TLS connection established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>
> But a message to the domain is not delivered. Instead I found this logged by tlsproxy:
>
> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: sys1.mmini.de[5.9.100.168]:25: re-using session with untrusted certificate, look for details earlier in the log
> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>
> But I did not found anything special "earlier in the log" ...

Surely the SMTP client logged SOMETHING?

Surely the tlsproxy daemon logged SOMETHING when it created the TLS connection?

> Message was delivered immediately as I disabled smtp_tls_connection_reuse:
> Feb 17 14:37:45 mail postfix/smtp[15157]: Verified TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>
> I could provide further information off-list.
>
> Andreas
>
Reply | Threaded
Open this post in threaded view
|

Re: DELIVERY issue with postfix 3.4.0-RC2

A. Schulze


Am 17.02.19 um 15:24 schrieb Wietse Venema:

> A. Schulze:
>> Hello,
>>
>> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
>> Now I notice delivery problems to "gervers.com". DANE setup looks OK. https://dane.sys4.de/smtp/gervers.com
>>
>> "posttls-finger gervers.com" also show
>> posttls-finger: Verified TLS connection established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>>
>> But a message to the domain is not delivered. Instead I found this logged by tlsproxy:
>>
>> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: sys1.mmini.de[5.9.100.168]:25: re-using session with untrusted certificate, look for details earlier in the log
>> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
>>
>> But I did not found anything special "earlier in the log" ...
>
> Surely the SMTP client logged SOMETHING?
>
> Surely the tlsproxy daemon logged SOMETHING when it created the TLS connection?

Hello Wietse,

thanks for asking :-) Yes, of corse, there are other loglines...
Here are the all message and connection related entries (I found):

Feb 17 10:27:54 mail postfix/smtpd[9445]: 442M9Q3L8Kzkn: client=localhost[127.0.0.1]
Feb 17 10:27:54 mail postfix/cleanup[9442]: 442M9Q3L8Kzkn: message-id=<....>
Feb 17 10:27:54 mail opendkim[19651]: 442M9Q3L8Kzkn: DKIM-Signature field added
Feb 17 10:27:54 mail postfix/qmgr[29788]: 442M9Q3L8Kzkn: from=<...>, size=1802, nrcpt=1 (queue active)
Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CONNECT to [5.9.100.168]:25
Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CA certificate verification failed for sys1.mmini.de[5.9.100.168]:25: num=28:certificate rejected
Feb 17 10:27:55 mail postfix/tlsproxy[9450]: Untrusted TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 17 10:27:55 mail postfix/smtp[9452]: Untrusted TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 17 10:27:55 mail postfix/smtp[9452]: 442M9Q3L8Kzkn: Server certificate not trusted
Feb 17 10:27:55 mail postfix/tlsproxy[9450]: DISCONNECT [5.9.100.168]:25
Feb 17 10:27:56 mail postfix/tlsproxy[9450]: CONNECT to [2a01:4f8:162:32ac::2]:25
Feb 17 10:27:56 mail postfix/tlsproxy[9450]: CA certificate verification failed for sys1.mmini.de[2a01:4f8:162:32ac::2]:25: num=28:certificate rejected
Feb 17 10:27:56 mail postfix/tlsproxy[9450]: Untrusted TLS connection established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 17 10:27:56 mail postfix/smtp[9452]: Untrusted TLS connection established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 17 10:27:56 mail postfix/smtp[9452]: 442M9Q3L8Kzkn: to=<***@gervers.com>, relay=sys1.mmini.de[2a01:4f8:162:32ac::2]:25, delay=1.6, delays=0.11/0.02/1.5/0, dsn=4.7.5, status=deferred (Server certificate not trusted)
Feb 17 10:27:56 mail postfix/tlsproxy[9450]: DISCONNECT [2a01:4f8:162:32ac::2]:25

the same tlsproxy process handled 5 other connections before this one. All logged as 'Untrusted TLS connection established to'

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: DELIVERY issue with postfix 3.4.0-RC2

Wietse Venema
A. Schulze:

>
>
> Am 17.02.19 um 15:24 schrieb Wietse Venema:
> > A. Schulze:
> >> Hello,
> >>
> >> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse"
> >> Now I notice delivery problems to "gervers.com". DANE setup looks OK. https://dane.sys4.de/smtp/gervers.com
> >>
> >> "posttls-finger gervers.com" also show
> >> posttls-finger: Verified TLS connection established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> >>
> >> But a message to the domain is not delivered. Instead I found this logged by tlsproxy:
> >>
> >> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: sys1.mmini.de[5.9.100.168]:25: re-using session with untrusted certificate, look for details earlier in the log
> >> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> >>
> >> But I did not found anything special "earlier in the log" ...
> >
> > Surely the SMTP client logged SOMETHING?
> >
> > Surely the tlsproxy daemon logged SOMETHING when it created the TLS connection?
>
> Hello Wietse,
>
> thanks for asking :-) Yes, of corse, there are other loglines...
> Here are the all message and connection related entries (I found):
>
> Feb 17 10:27:54 mail postfix/smtpd[9445]: 442M9Q3L8Kzkn: client=localhost[127.0.0.1]
> Feb 17 10:27:54 mail postfix/cleanup[9442]: 442M9Q3L8Kzkn: message-id=<....>
> Feb 17 10:27:54 mail opendkim[19651]: 442M9Q3L8Kzkn: DKIM-Signature field added
> Feb 17 10:27:54 mail postfix/qmgr[29788]: 442M9Q3L8Kzkn: from=<...>, size=1802, nrcpt=1 (queue active)
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CONNECT to [5.9.100.168]:25
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CA certificate verification failed for sys1.mmini.de[5.9.100.168]:25: num=28:certificate rejected
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: Untrusted TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Feb 17 10:27:55 mail postfix/smtp[9452]: Untrusted TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Feb 17 10:27:55 mail postfix/smtp[9452]: 442M9Q3L8Kzkn: Server certificate not trusted
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: DISCONNECT [5.9.100.168]:25
> Feb 17 10:27:56 mail postfix/tlsproxy[9450]: CONNECT to [2a01:4f8:162:32ac::2]:25
> Feb 17 10:27:56 mail postfix/tlsproxy[9450]: CA certificate verification failed for sys1.mmini.de[2a01:4f8:162:32ac::2]:25: num=28:certificate rejected
> Feb 17 10:27:56 mail postfix/tlsproxy[9450]: Untrusted TLS connection established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Feb 17 10:27:56 mail postfix/smtp[9452]: Untrusted TLS connection established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
> Feb 17 10:27:56 mail postfix/smtp[9452]: 442M9Q3L8Kzkn: to=<***@gervers.com>, relay=sys1.mmini.de[2a01:4f8:162:32ac::2]:25, delay=1.6, delays=0.11/0.02/1.5/0, dsn=4.7.5, status=deferred (Server certificate not trusted)
> Feb 17 10:27:56 mail postfix/tlsproxy[9450]: DISCONNECT [2a01:4f8:162:32ac::2]:25
>
> the same tlsproxy process handled 5 other connections before this one. All logged as 'Untrusted TLS connection established to'

How do those 'other' connections differ from what is shown above?

What I see is an SMTP client deferring delivery with a NEW TLS
connection. That is different from your earlier report about a
REUSED connection.

Can you confirm that the SMTP client will not deliver to this
destination with NEW and REUSED tlsproxy connections?

The error message suggests a problem in the certificate trust chain,
like an unknown root certificate. What is the output from:

postconf -F smtp/unix/chroot tlsproxy/unix/chroot

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: DELIVERY issue with postfix 3.4.0-RC2

A. Schulze


Am 17.02.19 um 16:10 schrieb Wietse Venema:

> How do those 'other' connections differ from what is shown above?
I don't see differences. This tlsproxy process handled a connection to gmail, outlook.com and some other destinations. All unverified because I did not configure the matching root certificates.
Interesting: it also handled later an other connection to an other destination that *could* be verified using DANE (verified connection established to ...)
 
> What I see is an SMTP client deferring delivery with a NEW TLS
> connection. That is different from your earlier report about a
> REUSED connection.
>
> Can you confirm that the SMTP client will not deliver to this
> destination with NEW and REUSED tlsproxy connections?
cannot check that without bothering the receiver with annoying test messages.
Will ask for permission...

> The error message suggests a problem in the certificate trust chain,
> like an unknown root certificate.

that's the point I started with subject "DANE issue..."
The destination don't need any certificate chains. The destination can be validated using DANE.

> What is the output from:
>
> postconf -F smtp/unix/chroot tlsproxy/unix/chroot
smtp/unix/chroot = y
tlsproxy/unix/chroot = y

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: DELIVERY issue with postfix 3.4.0-RC2

Wietse Venema
Wietse Venema:
> How do those 'other' connections differ from what is shown above?

A. Schulze:
> I don't see differences. This tlsproxy process handled a connection
> to gmail, outlook.com and some other destinations. All unverified
> because I did not configure the matching root certificates.

Conclusion: Postfix works as expected? I see no unexplained failures.

> Interesting: it also handled later an other connection to an other
> destination that *could* be verified using DANE (verified connection
> established to ...)

That is expected. DANE aims to lessen the dependency on PKI.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: DELIVERY issue with postfix 3.4.0-RC2

A. Schulze


Am 17.02.19 um 18:23 schrieb Wietse Venema:
> Conclusion: Postfix works as expected?

hard to say...

delivery deferred if smtp_tls_connection_reuse = yes
delivery works if smtp_tls_connection_reuse = no

http://www.postfix.org/TLS_README.html#client_tls_reuse say "As of Postfix 3.4, TLS connection reuse is disabled by default."
As usual, you select good defaults :-)

I'll make some further test next week and report my findings...

Andreas

Reply | Threaded
Open this post in threaded view
|

Re: DELIVERY issue with postfix 3.4.0-RC2

Wietse Venema
A. Schulze:
>
>
> Am 17.02.19 um 18:23 schrieb Wietse Venema:
> > Conclusion: Postfix works as expected?
>
> hard to say...
>
> delivery deferred if smtp_tls_connection_reuse = yes
> delivery works if smtp_tls_connection_reuse = no

Is the problem that certificate verification failure handling is
different depending on the smtp_tls_connection_reuse setting?

Are there other problems?

With smtp_tls_connection_reuse=yes, does certificate verification
failure handling differ for connection that is logged as "new" or
as "reused"?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: DANE issue with postfix 3.4.0-RC2

Viktor Dukhovni
In reply to this post by A. Schulze
On Sun, Feb 17, 2019 at 02:41:27PM +0100, A. Schulze wrote:

> I updated to postfix 3.4.0-RC2 and enabled "smtp_tls_connection_reuse" Now
> I notice delivery problems to "gervers.com".

The DNS configuration for this domain is:

    gervers.com. IN MX 10 sys1.mmini.de. ; NoError AD=1
    sys1.mmini.de. IN A 5.9.100.168 ; NoError AD=1
    sys1.mmini.de. IN AAAA 2a01:4f8:162:32ac::2 ; NoError AD=1
    _25._tcp.sys1.mmini.de. IN TLSA 3 1 1 69f3288e4797be2044e3cb6d0251e0fa28d986abcb4e2837863094d85d516161 ; NoError AD=1
    _25._tcp.sys1.mmini.de. IN TLSA 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18 ; NoError AD=1

But the live Let's Encrypt certificate chain does not match the
(presumably stale) "3 1 1" TLSA record, so it remains for the "2 1
1" record to match the issuing CA, and that's why Postfix is doing
"CA verification":

  sys1.mmini.de[5.9.100.168]: pass: TLSA match: depth = 1, name = sys1.mmini.de
    TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384,P256
    name = raketenstaffel.de
    name = sys1.mmini.de
    name = thegreendorf.de
    name = www.raketenstaffel.de
    name = www.thegreendorf.de
    depth = 0
      Issuer CommonName = Let's Encrypt Authority X3
      Issuer Organization = Let's Encrypt
      notBefore = 2019-01-20T00:30:26Z
      notAfter = 2019-04-20T00:30:26Z
      Subject CommonName = raketenstaffel.de
      pkey sha256 [nomatch] <- 3 1 1 d090d27c5a4b92dfd3b6b6b548e88aee92c8ce739eba6b529780fa923d3ffbcc
    depth = 1
      Issuer CommonName = DST Root CA X3
      Issuer Organization = Digital Signature Trust Co.
      notBefore = 2016-03-17T16:40:46Z
      notAfter = 2021-03-17T16:40:46Z
      Subject CommonName = Let's Encrypt Authority X3
      Subject Organization = Let's Encrypt
      pkey sha256 [matched] <- 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

which, as you noted, generally works.  However:

> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: sys1.mmini.de[5.9.100.168]:25:
>   re-using session with untrusted certificate, look for details earlier in
>   the log
> Feb 17 14:18:28 mail postfix/tlsproxy[14593]: Untrusted TLS connection
>   established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher
>   ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

Here, we see re-use of a cached TLS session to the destination that
failed to verify during the initial handshake.  This is a combination
of both connection re-use (via tlsproxy(8)) and TLS session resumption
in tlsproxy itself.

> But I did not found anything special "earlier in the log" ...
>
> Message was delivered immediately as I disabled smtp_tls_connection_reuse:
> Feb 17 14:37:45 mail postfix/smtp[15157]: Verified TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

If you performed a "reload" to get that to take effect, that would
also have flushed the TLS session cache.  And perhaps disabling
connection re-use is a distraction.  It may well have been sufficient
to just "postfix reload".

On Sun, Feb 17, 2019 at 03:38:19PM +0100, A. Schulze wrote:

> Feb 17 10:27:54 mail postfix/smtpd[9445]: 442M9Q3L8Kzkn: client=localhost[127.0.0.1]
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CONNECT to [5.9.100.168]:25
> Feb 17 10:27:55 mail postfix/tlsproxy[9450]: CA certificate verification
> failed for sys1.mmini.de[5.9.100.168]:25: num=28:certificate rejected

This is more interesting.  What OpenSSL version is your Postfix
linked with?  The issuer certificate was *explicitly* rejected.  At
first glance, that should only happen when not using DANE, and your
trust store has an issuer certificate for the chain, that is augmented
with trust settings (purpose OIDs) that don't include fitness for
use by TLS servers.  That's rather uncommon.

Please post the outputs of "postconf -nf" and "postconf -Mf", and
information about the OpenSSL version, checking "ldd" to make sure
you're reporting the version of the correct library.

> the same tlsproxy process handled 5 other connections before this one. All
> logged as 'Untrusted TLS connection established to'

If you re-enable use of the proxy, does the problem come back?

On Sun, Feb 17, 2019 at 04:45:11PM +0100, A. Schulze wrote:

> > Can you confirm that the SMTP client will not deliver to this
> > destination with NEW and REUSED tlsproxy connections?
> cannot check that without bothering the receiver with annoying test messages.

> Will ask for permission...

You don't need to send messages that reach the recipient.  You can
send "delivery probes" via:

    sendmail -f your-address -bv recipient-address

These drop the connection after "RCPT TO", without delivering a message.

> that's the point I started with subject "DANE issue..."
> The destination don't need any certificate chains. The destination can be validated using DANE.

We might temporarily need to raise the TLS loglevel to 2 in the
proxy just before sending a delivery probe.  It should then be
possible to see more of the TLS handshake details.


> > What is the output from:
> >
> > postconf -F smtp/unix/chroot tlsproxy/unix/chroot
> smtp/unix/chroot = y
> tlsproxy/unix/chroot = y

You should make sure your DNS is correctly configured in the chroot
jail.  Are any of the upstream resolvers perhaps not configured to
do DNSSEC?

On Sun, Feb 17, 2019 at 06:44:02PM +0100, A. Schulze wrote:

> hard to say...
>
> delivery deferred if smtp_tls_connection_reuse = yes
> delivery works if smtp_tls_connection_reuse = no

That's not yet a valid analysis, the "re-use" could be unrelated.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: DANE issue with postfix 3.4.0-RC2

A. Schulze


Am 17.02.19 um 21:24 schrieb Viktor Dukhovni:

Hello Viktor,

> If you performed a "reload" to get that to take effect, that would
> also have flushed the TLS session cache.  And perhaps disabling
> connection re-use is a distraction.  It may well have been sufficient
> to just "postfix reload".
no, also "postfix stop; postfix start; postfix flush" (it's a low volume system with only this message in the deferred queue) did not deliver the message.
but "smtp_tls_connection_reuse = no" did.

> This is more interesting.  What OpenSSL version is your Postfix
> linked with?
a self-compiled openssl-1.1.1a (using a shlib_variant like you show me some years ago)

> Please post the outputs of "postconf -nf" and "postconf -Mf", and
> information about the OpenSSL version, checking "ldd" to make sure
> you're reporting the version of the correct library.
https://andreasschulze.de/tmp/postconf_nf.txt
https://andreasschulze.de/tmp/postconf_Mf.txt

https://andreasschulze.de/tmp/ldd_smtp.txt

> If you re-enable use of the proxy, does the problem come back?
yes

> You don't need to send messages that reach the recipient.  You can
> send "delivery probes" via:
>
>     sendmail -f your-address -bv recipient-address
>
> These drop the connection after "RCPT TO", without delivering a message.
ok, so I start silent testing ...

https://andreasschulze.de/tmp/reuse_on.txt
https://andreasschulze.de/tmp/reuse_off.txt

> We might temporarily need to raise the TLS loglevel to 2 in the
> proxy just before sending a delivery probe.  It should then be
> possible to see more of the TLS handshake details.
tests above run with "smtp_tls_loglevel = 2"

>>> postconf -F smtp/unix/chroot tlsproxy/unix/chroot
>> smtp/unix/chroot = y
>> tlsproxy/unix/chroot = y
>
> You should make sure your DNS is correctly configured in the chroot
> jail.  Are any of the upstream resolvers perhaps not configured to
> do DNSSEC?
only one DNS resolver (@::1) is also configured inside the chroot jail.

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: DANE issue with postfix 3.4.0-RC2

Wietse Venema
A. Schulze:
> https://andreasschulze.de/tmp/reuse_on.txt
> https://andreasschulze.de/tmp/reuse_off.txt

These deliver to different server IP addresses, therefore the
results may differ.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: DANE issue with postfix 3.4.0-RC2

A. Schulze


Am 17.02.19 um 22:40 schrieb Wietse Venema:
> A. Schulze:
>> https://andreasschulze.de/tmp/reuse_on.txt
>> https://andreasschulze.de/tmp/reuse_off.txt
>
> These deliver to different server IP addresses, therefore the
> results may differ.

the destination MX has IPv4 and IPv6 working. Depends on what postfix selected first.

Andreas
Reply | Threaded
Open this post in threaded view
|

Re: DANE issue with postfix 3.4.0-RC2

Wietse Venema
In reply to this post by Wietse Venema
Wietse Venema:
> A. Schulze:
> > https://andreasschulze.de/tmp/reuse_on.txt
> > https://andreasschulze.de/tmp/reuse_off.txt
>
> These deliver to different server IP addresses, therefore the
> results may differ.

One is:

Feb 17 22:11:53 mail postfix/smtp[23428]: sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=0 chain is trust-anchor signed
Feb 17 22:11:53 mail postfix/smtp[23428]: sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=0 verify=1 subject=/CN=raketenstaffel.de

The other is:

Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25: depth=1 matched trust anchor public-key sha256 digest=60:B8:75:75:44:7D:CB:A2:A3:6B:7D:11:AC:09:FB:24:A9:DB:40:6F:EE:12:D2:CC:90:18:05:17:61:6E:8A:18
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25: depth=0 chain is trust-anchor signed
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25: depth=1 verify=0 subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25: depth=1 verify=0 subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25: depth=1 verify=0 subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25: depth=0 verify=1 subject=/CN=raketenstaffel.de

I would call that different.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: DANE issue with postfix 3.4.0-RC2

Viktor Dukhovni
In reply to this post by A. Schulze
On Sun, Feb 17, 2019 at 10:31:05PM +0100, A. Schulze wrote:

> ok, so I start silent testing ...
>
> https://andreasschulze.de/tmp/reuse_on.txt
> https://andreasschulze.de/tmp/reuse_off.txt

Thanks, these get us much closer to the source of the problem.
Something about the way the way that chain verification is happening
in the proxy appears to cause the chain to be verified differently.
I'll try to investigate from here.  There's nothing at first blush
with the "postconf -nf" or "postconf -Mf" that would suggest any
relevant issues.

No proxy:

  DANE-use evidenced by use of normally disabled SNI, and
  "trust-anchor signed" status, verification succeeds with a TA
  public key match at depth 1:

    Feb 17 22:11:53 mail postfix/smtp[23428]:
        setting up TLS connection to sys1.mmini.de[2a01:4f8:162:32ac::2]:25
    ...
    Feb 17 22:11:53 mail postfix/smtp[23428]:
        sys1.mmini.de[2a01:4f8:162:32ac::2]:25: SNI hostname: sys1.mmini.de
    ...
    Feb 17 22:11:53 mail postfix/smtp[23428]: sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=1 matched trust anchor public-key sha256 digest=60:B8:75:75:44:7D:CB:A2:A3:6B:7D:11:AC:09:FB:24:A9:DB:40:6F:EE:12:D2:CC:90:18:05:17:61:6E:8A:18
    Feb 17 22:11:53 mail postfix/smtp[23428]: sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=0 chain is trust-anchor signed
    Feb 17 22:11:53 mail postfix/smtp[23428]: sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=0 verify=1 subject=/CN=raketenstaffel.de
    Feb 17 22:11:53 mail postfix/smtp[23428]: SSL_connect:SSLv3/TLS read server certificate
    ...
    Feb 17 22:11:53 mail postfix/tlsmgr[23429]: write smtp TLS cache entry
        smtp&gervers.com&sys1.mmini.de&2a01:4f8:162:32ac::2&&636409472BD3C450C50707A4F46B749E669552335D3415B49FB59B1A82A2D7B1:
        time=1550437913 [data 1774 bytes]
    Feb 17 22:11:53 mail postfix/smtp[23428]: sys1.mmini.de[2a01:4f8:162:32ac::2]:25:
        subject_CN=sys1.mmini.de, issuer_CN=Let's Encrypt Authority X3,
        fingerprint=20:F4:59:CA:8C:7C:D7:21:21:43:16:54:F0:F1:24:35:85:75:00:D7,
        pkey_fingerprint=86:53:E8:0E:7A:48:A1:C6:DC:1C:F6:81:16:A9:04:4B:80:EE:F4:2C
    Feb 17 22:11:53 mail postfix/smtp[23428]: Verified TLS connection established to
        sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2
        with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

With proxy:

    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: CONNECT to [2a01:4f8:162:32ac::2]:25
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: setting up TLS connection to sys1.mmini.de[2a01:4f8:162:32ac::2]:25
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: looking for session
        smtp&gervers.com&sys1.mmini.de&2a01:4f8:162:32ac::2&&636409472BD3C450C50707A4F46B749E669552335D3415B49FB59B1A82A2D7B1 in smtp cache

  Same session lookup key which hashes the TLS policy settings
  evidences the same TLS settings in both cases.

    Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
        sys1.mmini.de[2a01:4f8:162:32ac::2]:25: SNI hostname: sys1.mmini.de

  Same IPv6 address and SNI name as without the proxy.

    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=1 matched trust anchor public-key sha256 digest=60:B8:75:75:44:7D:CB:A2:A3:6B:7D:11:AC:09:FB:24:A9:DB:40:6F:EE:12:D2:CC:90:18:05:17:61:6E:8A:18
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=0 chain is trust-anchor signed

  So far, so good, the chain should now be verified.

    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=1 verify=0 subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=1 verify=0 subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=1 verify=0 subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[2a01:4f8:162:32ac::2]:25: depth=0 verify=1 subject=/CN=raketenstaffel.de

  But suddenly, we're doing some sort of additional non-DANE
  certificate checks at depth 1.  Not yet clear why.  These fail.

    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: SSL_connect:SSLv3/TLS read server certificate
    ...
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: save session
        smtp&gervers.com&sys1.mmini.de&2a01:4f8:162:32ac::2&&636409472BD3C450C50707A4F46B749E669552335D3415B49FB59B1A82A2D7B1
        to smtp cache
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: CA certificate verification failed for sys1.mmini.de[2a01:4f8:162:32ac::2]:25: num=28:certificate rejected
    ...
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: Untrusted TLS connection established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)

  Peer verification failed in the proxy.

    Feb 17 22:08:45 mail postfix/smtp[23259]: Untrusted TLS connection established to sys1.mmini.de[2a01:4f8:162:32ac::2]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
    Feb 17 22:08:45 mail postfix/smtp[23259]: 442fk50Pg3z1CY: Server certificate not trusted
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: DISCONNECT [2a01:4f8:162:32ac::2]:25

  The smtp(8) client learns the bad news, and we try again, now with IPv4:

    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: looking for session
        smtp&gervers.com&sys1.mmini.de&5.9.100.168&&636409472BD3C450C50707A4F46B749E669552335D3415B49FB59B1A82A2D7B1
        in smtp cache
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
        sys1.mmini.de[5.9.100.168]:25: SNI hostname: sys1.mmini.de
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: sys1.mmini.de[5.9.100.168]:25:
        depth=1 matched trust anchor public-key sha256
        digest=60:B8:75:75:44:7D:CB:A2:A3:6B:7D:11:AC:09:FB:24:A9:DB:40:6F:EE:12:D2:CC:90:18:05:17:61:6E:8A:18
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
        sys1.mmini.de[5.9.100.168]:25: depth=0 chain is trust-anchor signed

  As expected with DANE.

    Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
        sys1.mmini.de[5.9.100.168]:25: depth=1 verify=0
        subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
        sys1.mmini.de[5.9.100.168]:25: depth=1 verify=0
        subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
        sys1.mmini.de[5.9.100.168]:25: depth=1 verify=0
        subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
        sys1.mmini.de[5.9.100.168]:25:
        depth=0 verify=1 subject=/CN=raketenstaffel.de

  These callbacks are NOT expected.

    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: SSL_connect:SSLv3/TLS read server certificate
    ...
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]: CA certificate verification failed for sys1.mmini.de[5.9.100.168]:25: num=28:certificate rejected
    Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
        sys1.mmini.de[5.9.100.168]:25: subject_CN=raketenstaffel.de,
        issuer_CN=Let's Encrypt Authority X3,
        fingerprint=20:F4:59:CA:8C:7C:D7:21:21:43:16:54:F0:F1:24:35:85:75:00:D7,
        pkey_fingerprint=86:53:E8:0E:7A:48:A1:C6:DC:1C:F6:81:16:A9:04:4B:80:EE:F4:2C

  Same certificate fingerprint as without the proxy.

    Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
        Untrusted TLS connection established to sys1.mmini.de[5.9.100.168]:25:
        TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
    Feb 17 22:08:45 mail postfix/smtp[23259]: Untrusted TLS connection established to
    sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
    Feb 17 22:08:45 mail postfix/smtp[23259]: 442fk50Pg3z1CY: to=<[hidden email]>,
        relay=sys1.mmini.de[5.9.100.168]:25, delay=0.56, delays=0.1/0.03/0.43/0, dsn=4.7.5,
        status=undeliverable (Server certificate not trusted)

  Bad news.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)

Viktor Dukhovni
On Mon, Feb 18, 2019 at 02:07:29AM -0500, Viktor Dukhovni wrote:

>     Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
> sys1.mmini.de[5.9.100.168]:25: depth=1 verify=0
> subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
>
>   These callbacks are NOT expected.

diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
index 01dda8a97..a4a88a392 100644
--- a/src/tls/tls_misc.c
+++ b/src/tls/tls_misc.c
@@ -772,6 +772,8 @@ void    tls_pre_jail_init(TLS_ROLE role)
     };
     int     flags;
 
+    tls_param_init();
+
     /* Nothing for clients at this time */
     if (role != TLS_ROLE_SERVER)
  return;
diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c
index 2c8714cb4..91eb4a9bc 100644
--- a/src/tlsproxy/tlsproxy.c
+++ b/src/tlsproxy/tlsproxy.c
@@ -947,7 +947,12 @@ static int tlsp_client_start_pre_handshake(TLSP_STATE *state)
 {
     state->client_start_props->ctx = state->appl_state;
     state->client_start_props->fd = state->ciphertext_fd;
-    state->tls_context = tls_client_start(state->client_start_props);
+    if (!TLS_DANE_BASED(state->client_start_props->tls_level)
+ || tls_dane_avail())
+ state->tls_context = tls_client_start(state->client_start_props);
+    else
+ msg_warn("%s: DANE requested, but not available",
+ state->client_start_props->namaddr);
     if (state->tls_context != 0)
  return (TLSP_STAT_OK);
 

These address missing DANE and TLS library initialization in the
TLS proxy.  Another issue remains, in that tlsproxy(8) wants
unconditional server-side support before it is willing to be a
client proxy, and therefore also wants server certificates.

We should probably split its pre_jail initialization into separate
client-side and server-side functions, so that the server side can
return with nothing to do, and yet allow the client side to be
activated.  And presumably the converse, and then turn away unsupported
requests from servers or clients at run-time, if the corresponding
feature is not enabled.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)

Wietse Venema
Viktor Dukhovni:

> On Mon, Feb 18, 2019 at 02:07:29AM -0500, Viktor Dukhovni wrote:
>
> >     Feb 17 22:08:45 mail postfix/tlsproxy[23261]:
> > sys1.mmini.de[5.9.100.168]:25: depth=1 verify=0
> > subject=/C=US/O=Let's Encrypt/CN=Let's Encrypt Authority X3
> >
> >   These callbacks are NOT expected.
>
> diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
> index 01dda8a97..a4a88a392 100644
> --- a/src/tls/tls_misc.c
> +++ b/src/tls/tls_misc.c
> @@ -772,6 +772,8 @@ void    tls_pre_jail_init(TLS_ROLE role)
>      };
>      int     flags;
>  
> +    tls_param_init();

tls_param_init() is already called by tls_client_init() and
tls_server_init().

Should we remove the those calls and make tls_pre_jail_init() a
mandatory call?

> diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c
> index 2c8714cb4..91eb4a9bc 100644
> --- a/src/tlsproxy/tlsproxy.c
> +++ b/src/tlsproxy/tlsproxy.c
> @@ -947,7 +947,12 @@ static int tlsp_client_start_pre_handshake(TLSP_STATE *state)
>  {
>      state->client_start_props->ctx = state->appl_state;
>      state->client_start_props->fd = state->ciphertext_fd;
> -    state->tls_context = tls_client_start(state->client_start_props);
> +    if (!TLS_DANE_BASED(state->client_start_props->tls_level)
> + || tls_dane_avail())
> + state->tls_context = tls_client_start(state->client_start_props);

How come that we need this here, when there is already code in the
Postfix SMTP client policy lookup that dedices whether a connection
will use DANE?

Should we make the SMTP client responsible for policy decisions,
and make tlsproxy responsible for encryption, or should we randomly
distribute responsibilities across process boundaries?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)

A. Schulze
In reply to this post by Viktor Dukhovni


Am 18.02.19 um 12:04 schrieb Viktor Dukhovni:

> diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
> diff --git a/src/tlsproxy/tlsproxy.c b/src/tlsproxy/tlsproxy.c

Hello Viktor,

I confirm these modifications fix the delivery failure.

... $ sendmail -f [hidden email] -bv [hidden email]

Feb 18 19:09:26 mail postfix/tlsproxy[10971]: CONNECT to [5.9.100.168]:25
Feb 18 19:09:26 mail postfix/tlsproxy[10971]: Verified TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 18 19:09:26 mail postfix/smtp[10969]: Verified TLS connection established to sys1.mmini.de[5.9.100.168]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Feb 18 19:09:26 mail postfix/tlsproxy[10971]: DISCONNECT [5.9.100.168]:25
Feb 18 19:09:29 mail postfix/smtp[10969]: 443Bhj6rYCzyC: to=<[hidden email]>, relay=sys1.mmini.de[5.9.100.168]:25, delay=4, delays=0.1/0.04/0.47/3.4, dsn=2.1.5, status=deliverable (250 2.1.5 Ok)
Feb 18 19:09:29 mail postfix/cleanup[10975]: 443Bhn6tnBzyS: message-id=<[hidden email]>
Feb 18 19:09:30 mail postfix/bounce[10972]: 443Bhj6rYCzyC: sender delivery status notification: 443Bhn6tnBzyS
...


> These address missing DANE and TLS library initialization in the
> TLS proxy.  Another issue remains, in that tlsproxy(8) wants
> unconditional server-side support before it is willing to be a
> client proxy, and therefore also wants server certificates.

that's limitation I currently could tolerate :-)

Thanks!
Andreas
Reply | Threaded
Open this post in threaded view
|

Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)

Viktor Dukhovni
In reply to this post by Wietse Venema
On Mon, Feb 18, 2019 at 12:05:40PM -0500, Wietse Venema wrote:

> > diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
> > index 01dda8a97..a4a88a392 100644
> > --- a/src/tls/tls_misc.c
> > +++ b/src/tls/tls_misc.c
> > @@ -772,6 +772,8 @@ void    tls_pre_jail_init(TLS_ROLE role)
> >      };
> >      int     flags;
> >  
> > +    tls_param_init();
>
> tls_param_init() is already called by tls_client_init() and
> tls_server_init().

It turns out that it is possible to bypass the server one, and crash
in the client init, by enabling server-side proxy TLS, but not
configuring any certs.  Then the tlsproxy client creates the params
structure with as-yet unitialized parameters before calling the
client init wrapper.

> Should we remove the those calls and make tls_pre_jail_init() a
> mandatory call?

I considered making the pre-jail init mandatory, but decided not
to mess with posttls-finger, and left them in place.

> > --- a/src/tlsproxy/tlsproxy.c
> > +++ b/src/tlsproxy/tlsproxy.c
> > @@ -947,7 +947,12 @@ static int tlsp_client_start_pre_handshake(TLSP_STATE *state)
> >  {
> >      state->client_start_props->ctx = state->appl_state;
> >      state->client_start_props->fd = state->ciphertext_fd;
> > -    state->tls_context = tls_client_start(state->client_start_props);
> > +    if (!TLS_DANE_BASED(state->client_start_props->tls_level)
> > + || tls_dane_avail())
> > + state->tls_context = tls_client_start(state->client_start_props);
>
> How come that we need this here, when there is already code in the
> Postfix SMTP client policy lookup that dedices whether a connection
> will use DANE?
>
> Should we make the SMTP client responsible for policy decisions,
> and make tlsproxy responsible for encryption, or should we randomly
> distribute responsibilities across process boundaries?

The tls_dane_avail() function tests for and initializes optional
library features, that are pre-requisites for DANE, but not necessarily
for doing TLS generally.  It is not a policy decision, but it is
deferred until DANE is actually used for the first time.

We could do it unconditionally, and perhaps tone down any warnings,
just saving the availability status.  Then complain if DANE use
is attempted later.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: Patch: 3.4.0-RC2 and 3.5 snapshots (was: DANE issue with postfix 3.4.0-RC2)

Wietse Venema
Viktor Dukhovni:

> On Mon, Feb 18, 2019 at 12:05:40PM -0500, Wietse Venema wrote:
>
> > > diff --git a/src/tls/tls_misc.c b/src/tls/tls_misc.c
> > > index 01dda8a97..a4a88a392 100644
> > > --- a/src/tls/tls_misc.c
> > > +++ b/src/tls/tls_misc.c
> > > @@ -772,6 +772,8 @@ void    tls_pre_jail_init(TLS_ROLE role)
> > >      };
> > >      int     flags;
> > >  
> > > +    tls_param_init();
> >
> > tls_param_init() is already called by tls_client_init() and
> > tls_server_init().
>
> It turns out that it is possible to bypass the server one, and crash
> in the client init, by enabling server-side proxy TLS, but not
> configuring any certs.  Then the tlsproxy client creates the params
> structure with as-yet unitialized parameters before calling the
> client init wrapper.
>
> > Should we remove the those calls and make tls_pre_jail_init() a
> > mandatory call?
>
> I considered making the pre-jail init mandatory, but decided not
> to mess with posttls-finger, and left them in place.

We should make tls_pre_jail_init() mandatory if that is the only
way to guarantee that shit won't blow up.

> > > --- a/src/tlsproxy/tlsproxy.c
> > > +++ b/src/tlsproxy/tlsproxy.c
> > > @@ -947,7 +947,12 @@ static int tlsp_client_start_pre_handshake(TLSP_STATE *state)
> > >  {
> > >      state->client_start_props->ctx = state->appl_state;
> > >      state->client_start_props->fd = state->ciphertext_fd;
> > > -    state->tls_context = tls_client_start(state->client_start_props);
> > > +    if (!TLS_DANE_BASED(state->client_start_props->tls_level)
> > > + || tls_dane_avail())
> > > + state->tls_context = tls_client_start(state->client_start_props);
> >
> > How come that we need this here, when there is already code in the
> > Postfix SMTP client policy lookup that dedices whether a connection
> > will use DANE?
> >
> > Should we make the SMTP client responsible for policy decisions,
> > and make tlsproxy responsible for encryption, or should we randomly
> > distribute responsibilities across process boundaries?
>
> The tls_dane_avail() function tests for and initializes optional
> library features, that are pre-requisites for DANE, but not necessarily
> for doing TLS generally.  It is not a policy decision, but it is
> deferred until DANE is actually used for the first time.

The Postfix SMTP client already decides if DANE is available. Why
is this needed again in tlsproxy? I see this as a problem in the
architecture if the tlsproxy client cannot simply delegate some TLS
library calls to the tlsproxy server.
       
        Wietse

> We could do it unconditionally, and perhaps tone down any warnings,
> just saving the availability status.  Then complain if DANE use
> is attempted later.
>
> --
> Viktor.
>
12