On Mon, Feb 18, 2019 at 02:48:32PM -0500, Wietse Venema wrote:
> > > 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.
Well, presently it is only the tlsproxy that looks at the TLS
parameters before calling tls_client_init(). But it does call the
pre-jail init first, and it does make sense to load all the parameters
there. The likelihood of needing similar early access elsewhere
seems low, but for the record I actually had the mandatory pre-jail
init change done, before backing it out... So it is not a wild idea.
> > 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.
Modulo code upgrades without a restart, indeed the proxy and client
should have equally capable libraries. So DANE could be "ready to
go" (when available) in the proxy from the outset, by always enabling
library support. With OpenSSL 1.0.0 and 1.0.1, we would often find
incomplete support, and would not be able to report the reasons why
DANE is not supported, if initialization is unconditional even for
sites that don't enable outbound DANE>
With OpenSSL 1.0.2, all the pre-requisites are there, so with a bit
of refactoring, we could initialize the DANE TLS support unconditionally
in tls_client_init(), so it is ready to run. We'd probably move
the call to tls_dane_avail() into tls_client_start(), and fail there
if the security level is DANE-based, but there's no DANE support.
The tls_dane_avail() call would no longer be responsible for
DANE initialization, it would just examine the memoized result.
Do you want to do that now in a 3.4.0-RC3? Or save the cleanup
for 3.5?
--
Viktor.
