available: multiple deliveries per TLS-encrypted connection

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
30 messages Options
12
Reply | Threaded
Open this post in threaded view
|

available: multiple deliveries per TLS-encrypted connection

Wietse Venema
Postfix snapshot 20180617, released a few minutes ago, introduces
Postfix SMTP client support for multiple deliveries per TLS-encrypted
connection. This is not to be confused with closing a connection
and reusing some TLS state in a new connection.

Below is a fragment from the RELEASE_NOTES file.

        Wietse

Major changes with snapshot 20180617
====================================

Preliminary Postfix SMTP client support for multiple deliveries per
TLS-encrypted connection. This is primarily to improve mail delivery
performance for destinations that throttle clients when they don't
combine deliveries.

This feature is enabled with "smtp_tls_connection_reuse=yes" in
main.cf, or with "tls_connection_reuse=yes" in smtp_tls_policy_maps.
It supports all Postfix TLS security levels including dane and
dane-only.

With connection reuse enabled as described above, the Postfix SMTP
client uses the tlsproxy(8) server to encrypt a connection (even under
low-traffic conditions). The tlsproxy(8) service was introduced in
Postfix 2.8, to support STARTTLS in postscreen(8).

Under high-traffic conditions, the Postfix SMTP client will use the
scache(8) connection cache to store and retrieve open connections.
This part already existed for plaintext SMTP, and it works in the
same way for TLS-encryped connections.

The following illustrates how TLS connections are reused:

    Initial plaintext SMTP handshake:
      smtp(8) -> remote SMTP server

    Reused SMTP/TLS connection, or new SMTP/TLS connection:
      smtp(8) -> tlsproxy(8) -> remote SMTP server

    Cached SMTP/TLS connection:
      scache(8) -> tlsproxy(8) -> remote SMTP server

There are a few refinements planned:

- Log the TLS properties every time a connection is reused.
  Currently, the properties are logged when a TLS session is created.

- Retire a tlsproxy(8) process after max_idle*max_use seconds, even
  if it is not idle. This limits the impact of memory leaks in
  libraries or in Postfix itself.

Reply | Threaded
Open this post in threaded view
|

Re: available: multiple deliveries per TLS-encrypted connection

Ralf Hildebrandt-2
* Wietse Venema <[hidden email]>:
> Postfix snapshot 20180617, released a few minutes ago, introduces
> Postfix SMTP client support for multiple deliveries per TLS-encrypted
> connection.

Testing here.

--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
                                           
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: available: multiple deliveries per TLS-encrypted connection

Wietse Venema
Ralf Hildebrandt:
> * Wietse Venema <[hidden email]>:
> > Postfix snapshot 20180617, released a few minutes ago, introduces
> > Postfix SMTP client support for multiple deliveries per TLS-encrypted
> > connection.
>
> Testing here.

Thanks! I have done tests with mumble_destination_concurrency_limit=1
to force connection reuse without having to queue up a lot of messages.

You can also test interoperability with "posttls-finger -X" (had to
pick a letter that was not already in use :-).
       
        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: available: multiple deliveries per TLS-encrypted connection

Wietse Venema
In reply to this post by Wietse Venema
Wietse Venema:
> Postfix snapshot 20180617, released a few minutes ago, introduces
> Postfix SMTP client support for multiple deliveries per TLS-encrypted
> connection. This is not to be confused with closing a connection
> and reusing some TLS state in a new connection.

BTW this is also called 'connection pooling'. There's a mailgun
blog that discusses how they cut their SMTP-over-TLS delivery times
in half by 'pooling' TLS connections.

        Wuetse
Reply | Threaded
Open this post in threaded view
|

Re: available: multiple deliveries per TLS-encrypted connection

@lbutlr
On 18 Jun 2018, at 12:08, Wietse Venema <[hidden email]> wrote:
> Wuetse

Ah, Mondays!


--
Is it my imagination, or do buffalo wings taste like chicken?

Reply | Threaded
Open this post in threaded view
|

PATCH: multiple deliveries per TLS-encrypted connection

Wietse Venema
In reply to this post by Wietse Venema
Wietse Venema:
> Postfix snapshot 20180617, released a few minutes ago, introduces
> Postfix SMTP client support for multiple deliveries per TLS-encrypted
> connection. This is not to be confused with closing a connection
> and reusing some TLS state in a new connection.

Below is a tiny patch for tlsproxy. After the remote TLS peer shuts
down TLS, the patch allows unsent inbound plaintext to trickle out
before tlsproxy tears down the proxied connection.

This addresses a sporadic "lost connection after end-of-data" error
in the Postfix SMTP client, and addresses a sporadic "lost connection
after sending QUIT" error with "posttls-finger -X".

Also released as postfix-3.4-20180618.

        Wietse

diff -cr /var/tmp/postfix-3.4-20180617/src/tlsproxy/tlsproxy.c ./src/tlsproxy/tlsproxy.c
*** /var/tmp/postfix-3.4-20180617/src/tlsproxy/tlsproxy.c 2018-06-17 12:35:21.000000000 -0400
--- ./src/tlsproxy/tlsproxy.c 2018-06-18 19:36:32.000000000 -0400
***************
*** 474,479 ****
--- 474,485 ----
  tls_print_errors();
  /* FALLTHROUGH */
      default:
+
+ /*
+ * Allow buffered-up plaintext output to trickle out.
+ */
+ if (state->plaintext_buf && NBBIO_WRITE_PEND(state->plaintext_buf))
+    return (TLSP_STAT_OK);
  tlsp_state_free(state);
  return (TLSP_STAT_ERR);
      }
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Ralf Hildebrandt-2
> Also released as postfix-3.4-20180618.

postfix-3.4-20180618. Is crashing for me:

Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: private/smtp socket: malformed response
Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
Jun 19 09:39:11 mail postfix/master[6142]: warning: process /usr/lib/postfix/smtp pid 12341 killed by signal 11

No matter what the setting for smtp_tls_connection_reuse is.

smtpd -D yields:

Loaded symbols for /lib/x86_64-linux-gnu/libnss_files.so.2
0x00007f0ee8b8995c in __libc_waitpid (pid=25675, stat_loc=stat_loc@entry=0x7ffd22ba62a0, options=options@entry=0)
        at ../sysdeps/unix/sysv/linux/waitpid.c:31
(gdb) Continuing.
       
Program received signal SIGSEGV, Segmentation fault.
tls_dane_resolve (port=6400, proto=proto@entry=0x558114406c72
"tcp",
    hostrr=0x0, forcetlsa=0) at tls_dane.c:1146
    1146        int     iscname = strcasecmp(hostrr->rname,
hostrr->qname);
(gdb) #0  tls_dane_resolve (port=6400, proto=proto@entry=0x558114406c72 "tcp",
    hostrr=0x0, forcetlsa=0) at tls_dane.c:1146
    #1  0x0000558114402add in dane_init (iter=0x558114882378, tls=0x55811487e9a0)
    at smtp_tls_policy.c:828
    #2  policy_create (unused_key=<optimizedout>,context=0x558114882378) at smtp_tls_policy.c:558
    #3  0x00007f0ee95307ec in ctable_locate (cache=0x55811487ea80,
        key=0x55811487f900 "gmail.com::25:") at ctable.c:163
    #4  0x000055811440318a in smtp_tls_policy_cache_query (
            why=why@entry=0x558114899bd0, tls=tls@entry=0x5581148823c0,
                iter=iter@entry=0x558114882378) at smtp_tls_policy.c:675
    #5  0x00005581143fa1e2 in smtp_reuse_session (domain_best_pref=5,
    addr_list=0x7ffd22ba5cc0, state=0x558114882340) at smtp_connect.c:675
    #6  smtp_connect_inet (state=0x558114882340, nexthop=<optimized out>,
    def_service=0x55811484ee80 "smtp") at smtp_connect.c:920
    #7  0x00005581143fb280 in smtp_connect (state=0x558114882340)
        at smtp_connect.c:1172
    #8  0x00005581143f8f3d in deliver_message (request=0x55811487bcd0,
    service=0x7ffd22ba7f8e "smtp") at smtp.c:1040
    #9  smtp_service (client_stream=0x558114899890,
        service=0x7ffd22ba7f8e "smtp", argv=<optimized out>) at smtp.c:1072
    #10 0x00007f0ee9dc478a in single_server_wakeup (fd=fd@entry=17, attr=attr@entry=0x0) at single_server.c:304
    #11 0x00007f0ee9dc49cf in single_server_accept_local (
        unused_event=<optimized out>, context=<optimized out>)
            at single_server.c:350
    #12 0x00007f0ee9536b01 in event_loop (delay=<optimized out>) at events.c:1186
    #13 0x00007f0ee9dc5847 in single_server_main (argc=<optimized out>, argv=<optimized out>, service=0x5581143f8e65 <smtp_service>)
        at single_server.c:817
    #14 0x00005581143f9857 in main (argc=5, argv=0x7ffd22ba6688) at smtp.c:1385
(gdb)

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Ralf Hildebrandt-2
* Ralf Hildebrandt <[hidden email]>:

> > Also released as postfix-3.4-20180618.
>
> postfix-3.4-20180618. Is crashing for me:
>
> Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: private/smtp socket: malformed response
> Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
> Jun 19 09:39:11 mail postfix/master[6142]: warning: process /usr/lib/postfix/smtp pid 12341 killed by signal 11
>
> No matter what the setting for smtp_tls_connection_reuse is.
>
> smtpd -D yields:

Typo, of course I debugged smtp, not smtpd!!!

--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
                                           
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Ralf Hildebrandt-2
In reply to this post by Ralf Hildebrandt-2
* Ralf Hildebrandt <[hidden email]>:

> > Also released as postfix-3.4-20180618.
>
> postfix-3.4-20180618. Is crashing for me:
>
> Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: private/smtp socket: malformed response
> Jun 19 09:39:10 mail postfix/qmgr[12033]: warning: transport smtp failure -- see a previous warning/fatal/panic logfile record for the problem description
> Jun 19 09:39:11 mail postfix/master[6142]: warning: process /usr/lib/postfix/smtp pid 12341 killed by signal 11
>
> No matter what the setting for smtp_tls_connection_reuse is.
>
> smtpd -D yields:
>
> Loaded symbols for /lib/x86_64-linux-gnu/libnss_files.so.2
> 0x00007f0ee8b8995c in __libc_waitpid (pid=25675, stat_loc=stat_loc@entry=0x7ffd22ba62a0, options=options@entry=0)
>         at ../sysdeps/unix/sysv/linux/waitpid.c:31
> (gdb) Continuing.
>
> Program received signal SIGSEGV, Segmentation fault.
> tls_dane_resolve (port=6400, proto=proto@entry=0x558114406c72
> "tcp",
>     hostrr=0x0, forcetlsa=0) at tls_dane.c:1146
>     1146        int     iscname = strcasecmp(hostrr->rname,
> hostrr->qname);

Error inducing change was introduced between postfix-3.4-20180603 and
postfix-3.4-20180605-nonprod
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Ralf Hildebrandt-2
* Ralf Hildebrandt <[hidden email]>:

> Error inducing change was introduced between postfix-3.4-20180603 and
> postfix-3.4-20180605-nonprod

I also tried postfix-3.4-20180603-nonprod which seems to be working
ok! So I guess it must have been between postfix-3.4-20180603-nonprod
and postfix-3.4-20180605-nonprod

--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
                                           
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Wietse Venema
Ralf Hildebrandt:
> * Ralf Hildebrandt <[hidden email]>:
>
> > Error inducing change was introduced between postfix-3.4-20180603 and
> > postfix-3.4-20180605-nonprod
>
> I also tried postfix-3.4-20180603-nonprod which seems to be working
> ok! So I guess it must have been between postfix-3.4-20180603-nonprod
> and postfix-3.4-20180605-nonprod

Does this reproduce with "posttls-finger -X <domain or host>"?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Ralf Hildebrandt-2
* Wietse Venema <[hidden email]>:

> Ralf Hildebrandt:
> > * Ralf Hildebrandt <[hidden email]>:
> >
> > > Error inducing change was introduced between postfix-3.4-20180603 and
> > > postfix-3.4-20180605-nonprod
> >
> > I also tried postfix-3.4-20180603-nonprod which seems to be working
> > ok! So I guess it must have been between postfix-3.4-20180603-nonprod
> > and postfix-3.4-20180605-nonprod
>
> Does this reproduce with "posttls-finger -X <domain or host>"?

posttls-finger from the source directory run from /var/spool/postfix gives me:

root@mail:/var/spool/postfix# /usr/src/postfix-3.4-20180605-nonprod/bin/posttls-finger -X gmail.com
posttls-finger: Connected to gmail-smtp-in.l.google.com[2a00:1450:4013:c03::1a]:25
posttls-finger: < 220 mx.google.com ESMTP j7-v6si170503eda.357 - gsmtp
posttls-finger: > EHLO mail.python.org
posttls-finger: < 250-mx.google.com at your service, [2a03:b0c0:2:d0::71:1]
posttls-finger: < 250-SIZE 157286400
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-STARTTLS
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-CHUNKING
posttls-finger: < 250 SMTPUTF8
posttls-finger: > STARTTLS
posttls-finger: < 220 2.0.0 Ready to start TLS
posttls-finger: gmail-smtp-in.l.google.com[2a00:1450:4013:c03::1a]:25: subject_CN=gmail-smtp-in.l.google.com, issuer_CN=Google Internet Authority G3,fingerprint=0C:EE:E6:2E:90:68:56:5A:88:BF:C7:81:B7:D1:A1:3C:EB:2C:B0:30,pkey_fingerprint=64:95:0D:F5:04:A2:FF:66:00:4E:06:AE:F6:37:B5:CF:7F:AE:20:99
posttls-finger: Untrusted TLS connection established to gmail-smtp-in.l.google.com[2a00:1450:4013:c03::1a]:25: TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)
posttls-finger: > EHLO mail.python.org
posttls-finger: < 250-mx.google.com at your service, [2a03:b0c0:2:d0::71:1]
posttls-finger: < 250-SIZE 157286400
posttls-finger: < 250-8BITMIME
posttls-finger: < 250-ENHANCEDSTATUSCODES
posttls-finger: < 250-PIPELINING
posttls-finger: < 250-CHUNKING
posttls-finger: < 250 SMTPUTF8
posttls-finger: > QUIT
posttls-finger: warning: lost connection while sending QUIT command

--
[*] sys4 AG

https://sys4.de, +49 (89) 30 90 46 64
Schleißheimer Straße 26/MG, 80333 München
                                           
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Wietse Venema
Ralf Hildebrandt:

> * Wietse Venema <[hidden email]>:
> > Ralf Hildebrandt:
> > > * Ralf Hildebrandt <[hidden email]>:
> > >
> > > > Error inducing change was introduced between postfix-3.4-20180603 and
> > > > postfix-3.4-20180605-nonprod
> > >
> > > I also tried postfix-3.4-20180603-nonprod which seems to be working
> > > ok! So I guess it must have been between postfix-3.4-20180603-nonprod
> > > and postfix-3.4-20180605-nonprod
> >
> > Does this reproduce with "posttls-finger -X <domain or host>"?
>
> posttls-finger from the source directory run from /var/spool/postfix gives me:

No error (btw, posttls-finger -X will chdir() to the queue directory,
it just needs root privs).

So what was the domain that was failing with the Postfix SMTP client?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Viktor Dukhovni


> On Jun 19, 2018, at 11:58 AM, Wietse Venema <[hidden email]> wrote:
>
> No error (btw, posttls-finger -X will chdir() to the queue directory,
> it just needs root privs).
>
> So what was the domain that was failing with the Postfix SMTP client?

The crash (from Ralf's stack trace) was in a code path that is not
exercised by posttls-finger, it is in the TLS policy setup (for gmail.com):

Program received signal SIGSEGV, Segmentation fault.
tls_dane_resolve (port=6400, proto=proto@entry=0x558114406c72
"tcp",
   hostrr=0x0, forcetlsa=0) at tls_dane.c:1146
   1146        int     iscname = strcasecmp(hostrr->rname,
hostrr->qname);
(gdb) #0  tls_dane_resolve (port=6400, proto=proto@entry=0x558114406c72 "tcp",
   hostrr=0x0, forcetlsa=0) at tls_dane.c:1146
   #1  0x0000558114402add in dane_init (iter=0x558114882378, tls=0x55811487e9a0)
   at smtp_tls_policy.c:828
   #2  policy_create (unused_key=<optimizedout>,context=0x558114882378) at smtp_tls_policy.c:558
   #3  0x00007f0ee95307ec in ctable_locate (cache=0x55811487ea80,
       key=0x55811487f900 "gmail.com::25:") at ctable.c:163
   #4  0x000055811440318a in smtp_tls_policy_cache_query (
            why=why@entry=0x558114899bd0, tls=tls@entry=0x5581148823c0,
                iter=iter@entry=0x558114882378) at smtp_tls_policy.c:675

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Wietse Venema
Viktor Dukhovni:

>
>
> > On Jun 19, 2018, at 11:58 AM, Wietse Venema <[hidden email]> wrote:
> >
> > No error (btw, posttls-finger -X will chdir() to the queue directory,
> > it just needs root privs).
> >
> > So what was the domain that was failing with the Postfix SMTP client?
>
> The crash (from Ralf's stack trace) was in a code path that is not
> exercised by posttls-finger, it is in the TLS policy setup (for gmail.com):
>
> Program received signal SIGSEGV, Segmentation fault.
> tls_dane_resolve (port=6400, proto=proto@entry=0x558114406c72
> "tcp",
>    hostrr=0x0, forcetlsa=0) at tls_dane.c:1146
>    1146        int     iscname = strcasecmp(hostrr->rname,
> hostrr->qname);
> (gdb) #0  tls_dane_resolve (port=6400, proto=proto@entry=0x558114406c72 "tcp",
>    hostrr=0x0, forcetlsa=0) at tls_dane.c:1146
>    #1  0x0000558114402add in dane_init (iter=0x558114882378, tls=0x55811487e9a0)
>    at smtp_tls_policy.c:828
>    #2  policy_create (unused_key=<optimizedout>,context=0x558114882378) at smtp_tls_policy.c:558
>    #3  0x00007f0ee95307ec in ctable_locate (cache=0x55811487ea80,
>        key=0x55811487f900 "gmail.com::25:") at ctable.c:163
>    #4  0x000055811440318a in smtp_tls_policy_cache_query (
>    why=why@entry=0x558114899bd0, tls=tls@entry=0x5581148823c0,
>        iter=iter@entry=0x558114882378) at smtp_tls_policy.c:675

How would I reproduce this? I can send mail to gmail.com just fine,
with postfix-3.4-20180618 and with "smtp_tls_connection_reuse = yes",
Linux and FreeBSD.

Or can you provide a stack trace?

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Wietse Venema
Wietse Venema:

> Viktor Dukhovni:
> >
> >
> > > On Jun 19, 2018, at 11:58 AM, Wietse Venema <[hidden email]> wrote:
> > >
> > > No error (btw, posttls-finger -X will chdir() to the queue directory,
> > > it just needs root privs).
> > >
> > > So what was the domain that was failing with the Postfix SMTP client?
> >
> > The crash (from Ralf's stack trace) was in a code path that is not
> > exercised by posttls-finger, it is in the TLS policy setup (for gmail.com):
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > tls_dane_resolve (port=6400, proto=proto@entry=0x558114406c72
> > "tcp",
> >    hostrr=0x0, forcetlsa=0) at tls_dane.c:1146
> >    1146        int     iscname = strcasecmp(hostrr->rname,
> > hostrr->qname);
> > (gdb) #0  tls_dane_resolve (port=6400, proto=proto@entry=0x558114406c72 "tcp",
> >    hostrr=0x0, forcetlsa=0) at tls_dane.c:1146
> >    #1  0x0000558114402add in dane_init (iter=0x558114882378, tls=0x55811487e9a0)
> >    at smtp_tls_policy.c:828
> >    #2  policy_create (unused_key=<optimizedout>,context=0x558114882378) at smtp_tls_policy.c:558
> >    #3  0x00007f0ee95307ec in ctable_locate (cache=0x55811487ea80,
> >        key=0x55811487f900 "gmail.com::25:") at ctable.c:163
> >    #4  0x000055811440318a in smtp_tls_policy_cache_query (
> >    why=why@entry=0x558114899bd0, tls=tls@entry=0x5581148823c0,
> >        iter=iter@entry=0x558114882378) at smtp_tls_policy.c:675
>
> How would I reproduce this? I can send mail to gmail.com just fine,
> with postfix-3.4-20180618 and with "smtp_tls_connection_reuse = yes",
> Linux and FreeBSD.
>
> Or can you provide a stack trace?

Argh, the trace ends in the smtp_tls_policy_cache_query which is called from
more than one place. Investigating...

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Viktor Dukhovni


> On Jun 19, 2018, at 12:21 PM, Wietse Venema <[hidden email]> wrote:
>
> Argh, the trace ends in the smtp_tls_policy_cache_query which is called from
> more than one place. Investigating...

DANE context initialization needs to know whether the MX hostname
is an alias, and was previously only done per-MX.  Now there's
a new call with "iter->rr" still NULL.  The code in dane_init()
is not prepared for that.  Without the MX hostname and its DNS_RRs
it can't decide whether the security level is DANE (MX host has
TLSA records, ...) or opportunistic TLS.

diff --git a/postfix/src/smtp/smtp_connect.c b/postfix/src/smtp/smtp_connect.c
index 2bf209d9..abccb57c 100644
--- a/postfix/src/smtp/smtp_connect.c
+++ b/postfix/src/smtp/smtp_connect.c
@@ -669,9 +669,12 @@ static int smtp_reuse_session(SMTP_STATE *state, DNS_RR **addr_list,
      *
-     * We request a dummy "TLS disabled" policy for connection-cache lookup by
-     * request nexthop only. If we find a saved connection, then we know that
-     * plaintext was permitted, because we never save a connection after
-     * turning on TLS.
+     * If TLS is proxied, lookup the TLS policy now so that we reuse only
+     * matching sessions. Otherwise, request a dummy "TLS disabled" policy
+     * for connection-cache lookup by request nexthop only.
      */
 #ifdef USE_TLS
-    smtp_tls_policy_dummy(state->tls);
+    if (!smtp_tls_policy_cache_query(why, state->tls, iter)) {
+       msg_warn("TLS policy lookup error for %s/%s: %s",
+                STR(iter->dest), STR(iter->host), STR(why->reason));
+       return (0);                             /* XXX */
+    }
 #endif


--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Viktor Dukhovni


> On Jun 19, 2018, at 12:32 PM, Viktor Dukhovni <[hidden email]> wrote:
>
> DANE context initialization needs to know whether the MX hostname
> is an alias, and was previously only done per-MX.  Now there's
> a new call with "iter->rr" still NULL.  The code in dane_init()
> is not prepared for that.  Without the MX hostname and its DNS_RRs
> it can't decide whether the security level is DANE (MX host has
> TLSA records, ...) or opportunistic TLS.

Connection re-use is primarily per-destination, and only
secondarily per-address, while DANE policy is per MX host,
based on presence or absence of TLSA records for *that* MX host.

At the global level, all we know is whether the nexthop
domain is a *candidate* for DANE, but not whether DANE
will or won't happen.

If we have a cached connection for the same nexthop
domain (and port), presumably it has a recent policy
for one of the MX hosts, and we can use that.  And
only do fine-graing policy matching when doing per-host
resumption.  Which means that dane_init() could be
optimized out when (iter->rr == NULL)?

That would however imply that a change in policy might
not kick in quite as fast as one might like.  A reload
might be needed to make sure that cached connections
for a nexthop with a prior policy are not re-used (will
a reload cause scache to restart?).

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Wietse Venema
In reply to this post by Viktor Dukhovni
Ralf, does this helpl?

        Wietse

*** ./smtp_connect.c- 2018-06-04 19:21:21.000000000 -0400
--- ./smtp_connect.c 2018-06-19 13:11:30.000000000 -0400
***************
*** 671,676 ****
--- 671,677 ----
       * matching sessions. Otherwise, request a dummy "TLS disabled" policy
       * for connection-cache lookup by request nexthop only.
       */
+ return (0);
  #ifdef USE_TLS
      if (!smtp_tls_policy_cache_query(why, state->tls, iter)) {
  msg_warn("TLS policy lookup error for %s/%s: %s",
Reply | Threaded
Open this post in threaded view
|

Re: PATCH: multiple deliveries per TLS-encrypted connection

Wietse Venema
Wietse Venema:
> Ralf, does this helpl?

Unfortunately, this would be suboptimal when a site has muliple MX hosts
(It may end up making connections to each of them).

Viktor's suggestion to skip the dane cache makes more sense.

Viktor, cache wshould terminate after "postfix reload".

> Wietse
>
> *** ./smtp_connect.c- 2018-06-04 19:21:21.000000000 -0400
> --- ./smtp_connect.c 2018-06-19 13:11:30.000000000 -0400
> ***************
> *** 671,676 ****
> --- 671,677 ----
>        * matching sessions. Otherwise, request a dummy "TLS disabled" policy
>        * for connection-cache lookup by request nexthop only.
>        */
> + return (0);
>   #ifdef USE_TLS
>       if (!smtp_tls_policy_cache_query(why, state->tls, iter)) {
>   msg_warn("TLS policy lookup error for %s/%s: %s",
>
12