#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 kevin8t8):
Matthias,
I feel as if some confusion is occurring about how the option/patch is
intended to be used. Or it may be that I am too ignorant and am missing
an important point.
> Saving the cert of the intermediate that is closer to the root (2/4),
however, mutt
> will ask for the root again next time.
No. The **next** time you connect. ssl_verify_partial_chains should be
set to "=yes". The patch will ignore (1/4), find (2/4) in the certificate
file and return true, and so (3/4) and (4/4) should then be marked
preverify_ok=1.
The ssl_verify_partial_chains=ask-yes setting is **only** for the
**first** time you connect to a host. The (s)kip option is only to help
you save one of the certificates in the chain to your certificate file.
Once you do this, you set it back to "=yes".
> The "=yes" setting on the other hand is useless IMO because it only
presents
> the host certificate.
No. Again, "=yes" is for when you have already saved the desired
certificate to your file. Once this is done, "=yes" should not prompt at
all.
> the whole rig is questionable from the user interface perspective
Yes. I admit this is not a great UI. However, kratem32 and pete3215 in
https://github.com/neomutt/neomutt/issues/429 both seem to understand the
idea behind the patch.
The patch is for those with specific needs who want to directly control
who they trust. The UI is a bit lousy, but it at least gives them that
control.
> 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
This is certainly the *best* way to go about it. But I am trying to avoid
this option
if at all possible. I feel the quadoption patch allows the tinkerers to
tinker
without too much effort from mutt development side, while the "=no" option
preserves the safe/correct behavior for 99% of the users.
With the above explanation, does the patch make more sense? Michał does
it
make sense to you?
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3916#comment:48>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
