Re: [exim-dev] tls_in_peerdn/tls_in_peercert for unverified …

Top Page
Delete this message
Reply to this message
Author: Viktor Dukhovni
Date:  
To: exim-dev
Subject: Re: [exim-dev] tls_in_peerdn/tls_in_peercert for unverified certificate
On Sat, Dec 27, 2014 at 02:03:11PM +0000, Jeremy Harris wrote:

> > When the verify callback unconditionally
> > returns "1" (continue with handshake) even when "ok == 0", then
> > every element of the certificate chain will be passed to the verify
> > callback (at least once).
>
> Reference?


Due to poor OpenSSL documentation, sadly the best reference is the
code, however, the documentation, such as it is, says:

    https://www.openssl.org/docs/ssl/SSL_CTX_set_verify.html


    The certificate chain is checked starting with the deepest
    nesting level (the root CA certificate) and worked upward to
    the peer's certificate. At each level signatures and issuer
    attributes are checked. Whenever a verification error is found,
    the error number is stored in x509_ctx and verify_callback is
    called with preverify_ok=0. By applying X509_CTX_store_*
    functions verify_callback can locate the certificate in question
    and perform additional steps (see EXAMPLES). If no error is
    found for a certificate, verify_callback is called with
    preverify_ok=1 before advancing to the next level.


    The return value of verify_callback controls the strategy of
    the further verification process. If verify_callback returns
    0, the verification process is immediately stopped with
    "verification failed" state. If SSL_VERIFY_PEER is set, a
    verification failure alert is sent to the peer and the TLS/SSL
    handshake is terminated. If verify_callback returns 1, the
    verification process is continued. If verify_callback always
    returns 1, the TLS/SSL handshake will not be terminated with
    respect to verification failures and the connection will be
    established. The calling process can however retrieve the error
    code of the last verification error using SSL_get_verify_result
    or by maintaining its own error storage managed by verify_callback.


> > This should also be true for DANE.
>
> You're not looking at his code, which did not appear
> in the DANE verification path.


Indeed I've not been looking at the Exim code or proposed patches,
just commenting on what's possible or can be expected with OpenSSL.

With DANE verification, the verify callback is still invoked, if
set by the application (exim).

> > Get in touch off-list if you're seeing something else. Postfix
> > always completes the handshake, and gracefully disconnects (QUIT)
> > if the connection is less secure than desired.
>
> Postfix is not relevant here.


Indeed, but it illustrates what's possible.

-- 
    Viktor.