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