#3916: Mutt 1.8: TOFU approach bails out on first fail or reject, not offering
higher links of the cert' chain
--------------------------+----------------------
Reporter: kratem32 | Owner: mutt-dev
Type: enhancement | Status: new
Priority: minor | Milestone: 1.8
Component: crypto | Version:
Resolution: | Keywords: tofu
--------------------------+----------------------
Comment (by m-a):
Well, that needs to be differentiated a bit. In a chain 4 certificates
deep (including root as 1/4 and host as 4/4), when I save the intermediate
CA's certificate that has signed the server certificate (i. e. 3/4), even
with ask-yes, the connection is accepted right away the next time. Saving
the cert of the intermediate that is closer to the root (2/4), however,
mutt will ask for the root again next time. So we can't just fill in an
intermediate CA as trust anchor because OpenSSL will not use this to build
an "alternative chain", at least not on the OpenSSL build shipped by
Ubuntu.
The "=yes" setting on the other hand is useless IMO because it only
presents the host certificate. So ssl_verify_partial_chains=ask-* and
ssl_verify_partial_chains=yes fail to work as advertised, and the whole
rig is questionable from the user interface perspective.
I haven't worked out if it is something about how it's implemented in
mutt, or if the trust concept in OpenSSL just can't verify partial chains
if someone stores an intermediate CA as trustworthy, but not the root CA,
or if that has to do with X.509 extensions declaring what the certificate
is good for.
Given the current state of matters, I recommend to NOT commit ticket-3916
-verify-partial-quadoption.patch from comment:42 to the main branch. We
need to understand the concept of the trust store in OpenSSL better, and
may ditch the current approach altogether and deem it not workable.
Or we implement an even more complex concept that uses the earlier
callbacks to just build a global view of the chain, always pretending
success and caching the preverify results as well as the cache state,
until we get to the final callback (which is the one concerning the host
certificate), when we present the user with the necessary questions. This
would, however, amount to doing most of the verification in loops
ourselves again. But before we go into code, we need to understand how
OpenSSL itself deals with "alternative trust chains".
Let's have another look at:
{{{
changeset: 6890:b985c324932b
user: Michał Kępień <m...@kempniu.pl>
date: Tue Dec 13 11:16:10 2016 -0800
files: mutt_ssl.c
description:
Rework OpenSSL certificate verification to support alternative chains.
(closes #3903)
}}}
I maintain that this very commit follows the right concept and was a solid
basis (with a few minor nits that we have picked) and is the way to go
forward (so please do NOT revert it), but the commit log that has come
along with it is somewhat confusing - and, as written already above,
again, we need to figure out under what circumstances OpenSSL (if at all)
would be able to trust an intermediate CA without trusting its root. Does
Michał ("kempniu") know more about that? He at least figured, in #3903,
why the old verification code was unable to verify this alternate chain.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3916#comment:46>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
