Connection reuse and tlsproxy

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

Connection reuse and tlsproxy

Emmanuel Fusté-2
Hello,

I started to deploy TLS connection reuse on some non trivial outboud
gateway setups.

First I was hit by an non obvious configuration behavior:
On my gateway I have:
smtpd_tls_security_level=none
smtp_tls_security_level=dane

If I switch to TLS session reuse with
smtp_tls_connection_reuse=yes

I get:
tlsproxy: warning: TLS service is requested, but disabled with
tlsproxy_tls_security_level or tlsproxy_use_tls
smtp: warning: private/tlsproxy service role "client" is not available.

By default tlsproxy_tls_security_level=$smtpd_tls_security_level
I overwrite it with tlsproxy_tls_security_level=may and it worked.

But as tlsproxy_client_level = $smtp_tls_security_level (=dane) why I
need to enable tlsproxy "server" part to get the "client" part working ?
Overlook/Bug ?

Next, more a feature request:
I have some custom transports defined for different/custom client side
TLS certs and conf.
But we presently have no way to specify a different tlsproxy instance
for smtp as for cleanup for smtpd. So for now I must disable TLS
connection reuse on these transports.
Is adding such a possibility something doable ? My customs transports
would greatly benefit from connection reuse as there is a permanent
sustained mail flow on them.

Emmanuel.
Reply | Threaded
Open this post in threaded view
|

Re: Connection reuse and tlsproxy

Wietse Venema
Emmanuel Fust?:
> I have some custom transports defined for different/custom client side
> TLS certs and conf.
> But we presently have no way to specify a different tlsproxy instance
> for smtp as for cleanup for smtpd. So for now I must disable TLS
> connection reuse on these transports.

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

tlsproxy_service_name (default: tlsproxy)
    The name of the tlsproxy(8) service entry in master.cf. This
    service performs plaintext <=> TLS ciphertext conversion.

    This feature is available in Postfix 2.8 and later.

        Wietse
Reply | Threaded
Open this post in threaded view
|

Re: Connection reuse and tlsproxy

Emmanuel Fusté-2
Le 27/09/2019 à 17:39, Wietse Venema a écrit :

> Emmanuel Fust?:
>> I have some custom transports defined for different/custom client side
>> TLS certs and conf.
>> But we presently have no way to specify a different tlsproxy instance
>> for smtp as for cleanup for smtpd. So for now I must disable TLS
>> connection reuse on these transports.
> http://www.postfix.org/postconf.5.html#tlsproxy_service_name
>
> tlsproxy_service_name (default: tlsproxy)
> The name of the tlsproxy(8) service entry in master.cf. This
> service performs plaintext <=> TLS ciphertext conversion.
>
> This feature is available in Postfix 2.8 and later.
>
> Wietse
Perfect ! it work as intended.
I always have difficulties to find theses in the doc as for the cleanup
service....
Perhaps a reference in smtp/smtpd/postscreen manpage would help as many
are asking regularly for cleanup on the mailing list.

Thank you.
Emmanuel.
Reply | Threaded
Open this post in threaded view
|

Re: Connection reuse and tlsproxy

Viktor Dukhovni
In reply to this post by Emmanuel Fusté-2
On Fri, Sep 27, 2019 at 05:01:03PM +0200, Emmanuel Fusté wrote:

> Next, more a feature request: I have some custom transports defined for
> different/custom client side TLS certs and conf.

Client-side TLS certs typically have private keys that only root
can read, but tlsproxy(8) (optionally) chroots and then drops privs
at startup, after loading any default client-side keys/certs.

For this, we'd need a variant of the server-side SNI code, with the
keys and certs for various destinations are stored in a table that
is opened in "pre-jail" initialization while the process is still
running as root.  The client code would then load appropriate
destination-specific keys from the table.

Just to be on the safe side with chroot, the CAfile and CApath are
also required to be the same for all tlsproxy clients, perhaps
this can be relaxed, as these files don't contain secrets, and
should be readable by unprivileged processes.  With chroot jails,
it would be the administrator's responsibility to ensure that
suitable CAfile/CApath exist in the jail ($queue_directory).

> But we presently have no way to specify a different tlsproxy instance
> for smtp as for cleanup for smtpd. So for now I must disable TLS
> connection reuse on these transports.

Wietse answered this part.

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

Re: Connection reuse and tlsproxy

Emmanuel Fusté-2
Le 27/09/2019 à 18:07, Viktor Dukhovni a écrit :

> On Fri, Sep 27, 2019 at 05:01:03PM +0200, Emmanuel Fusté wrote:
>
>> Next, more a feature request: I have some custom transports defined for
>> different/custom client side TLS certs and conf.
> Client-side TLS certs typically have private keys that only root
> can read, but tlsproxy(8) (optionally) chroots and then drops privs
> at startup, after loading any default client-side keys/certs.
>
> For this, we'd need a variant of the server-side SNI code, with the
> keys and certs for various destinations are stored in a table that
> is opened in "pre-jail" initialization while the process is still
> running as root.  The client code would then load appropriate
> destination-specific keys from the table.
>
> Just to be on the safe side with chroot, the CAfile and CApath are
> also required to be the same for all tlsproxy clients, perhaps
> this can be relaxed, as these files don't contain secrets, and
> should be readable by unprivileged processes.  With chroot jails,
> it would be the administrator's responsibility to ensure that
> suitable CAfile/CApath exist in the jail ($queue_directory).
Yes, that would be great.
Actually, custom transports (with it customs tlsproxy) fit my needs
without to much burden, so it is ok for now.

As usual, thank you for your detailed answer.

Emmanuel.
Reply | Threaded
Open this post in threaded view
|

Re: Connection reuse and tlsproxy

Wietse Venema
In reply to this post by Viktor Dukhovni
Viktor Dukhovni:

> On Fri, Sep 27, 2019 at 05:01:03PM +0200, Emmanuel Fust? wrote:
>
> > Next, more a feature request: I have some custom transports defined for
> > different/custom client side TLS certs and conf.
>
> Client-side TLS certs typically have private keys that only root
> can read, but tlsproxy(8) (optionally) chroots and then drops privs
> at startup, after loading any default client-side keys/certs.
>
> For this, we'd need a variant of the server-side SNI code, with the
> keys and certs for various destinations are stored in a table that
> is opened in "pre-jail" initialization while the process is still
> running as root.  The client code would then load appropriate
> destination-specific keys from the table.
>
> Just to be on the safe side with chroot, the CAfile and CApath are
> also required to be the same for all tlsproxy clients, perhaps
> this can be relaxed, as these files don't contain secrets, and
> should be readable by unprivileged processes.  With chroot jails,
> it would be the administrator's responsibility to ensure that
> suitable CAfile/CApath exist in the jail ($queue_directory).

Before implementing multiple TLS profiles in the tlsproxy(8) daemon,
we would have to get rid global libtls settings, and pass their
values through tls_{client,server}_init() calls.

Those global settings may differ between Postfix SMTP clients, and
they cannot be redefined by a tlsproxy client request because that
would affect connections from SMTP clients with different global
settings.

        Wietse