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.
