#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 kempniu):
Replying to [comment:34 m-a]:
> To make a reasonable comment, I'd need to know if OpenSSL allows short-
circuiting the chain, and write some experimental code. In doubt we might
have to run the callback on the entire chain, pretending success, logging
OpenSSL's and mutt's view of "verified" and "trusted" separately, storing
intermediate data, and defer the whole approval and decision making to the
point when we get called back for the host certificate, and then use the
entire data set. Quite a bit of an effort, for a quite unique feature...
Sounds workable, but before you start coding, let me suggest another idea
which is a generalization of Kevin's idea. What if we add a configuration
variable like `ssl_verify_depth` which would determine how deep from the
leaf we are willing to perform any checks. By default the whole chain
would be checked, but if the user desires so, verification could be
narrowed down to the leaf certificate itself (value = 1) or somewhere
between the root and the leaf (value > 1). This could be implemented by
simply returning 1 somewhere early inside `ssl_verify_callback()` for
every certificate which is deeper in the chain than the requested
verification depth so that no prompts for such certificates are displayed.
Kind of like what `SSL_set_verify_depth()` does, but without returning an
error when the chain is longer than the requested verification depth.
Note that I have not given this idea a lot of thought yet, so I might be
missing something obvious. The only scenario I can think of right now
that would be tricky to handle using this solution is if the length of the
certificate chain presented by the user's e-mail provider varies
frequently and the user would still like to trust some intermediate CA,
but this starts getting a bit too far-fetched IMHO.
--
Ticket URL: <https://dev.mutt.org/trac/ticket/3916#comment:37>
Mutt <http://www.mutt.org/>
The Mutt mail user agent
