Re: X509_verify_cert() + DANE: without calling SSL_dane_tlsa_add() returns verify ok

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 29, 2024 at 09:59:23PM +0000, 'Graham Leggett' via openssl-users wrote:

> I have some code that wants to verify a X509 certificate against DANE,
> and on the happy path it's working great.
> 
> What's weird is a particular failure case that returns verify ok
> instead of DANE mismatch.
> 
> If I start by calling SSL_dane_enable() passing the basename, but then
> the DNS lookup returns zero records which results in me calling
> SSL_dane_tlsa_add() zero times, I expect a call to X509_verify_cert()
> would return a verification mismatch given there is nothing to match.
> 
> Instead I get a verify ok, which is unexpected.

It means that the chain is valid relative to WebPKI, the call to
SSL_dane_enable() configured the same name as both the hostname and the
SNI name, and absent any DANE TLSA records WebPKI is still in effect.

> If I get at least one invalid DNS response (on purpose) and supply it
> to SSL_dane_tlsa_add(), I get a X509_V_ERR_DANE_NO_MATCH as expected.

Not sure what you mean by "invalid" here, but this only happens when
at least one reasonably well-formed TLSA record is successfully added.

> Is this expected behaviour? This would imply that I need to keep track
> of the number of times I call SSL_dane_tlsa_add(), and prior to
> X509_verify_cert() fail the verify in advance. This seems a little
> unclean, ideally X509_verify_cert() should be doing all the work.
> 
> Am I doing something wrong?

You've not specified any TLSA records, so WebPKI authentication is still
in effect, if that succeeds, then the certificate is still verified.

If you intend to use DANE or else fail, yes, you need to fail early when
no TLSA records are added by counting to make sure that the number of
success results from SSL_dane_tlsa_add() is positive.

For example, in Postfix:

    https://github.com/vdukhovni/postfix/blob/33701748e11d4b8a25a34aaafce2aa2f02d1ffb2/postfix/src/tls/tls_dane.c#L807-L808

    int     tls_dane_enable(TLS_SESS_STATE *TLScontext)
    {

    https://github.com/vdukhovni/postfix/blob/33701748e11d4b8a25a34aaafce2aa2f02d1ffb2/postfix/src/tls/tls_dane.c#L816-L820

        for (tp = dane->tlsa; tp != 0; tp = tp->next) {
            ret = SSL_dane_tlsa_add(ssl, tp->usage, tp->selector,
                                    tp->mtype, tp->data, tp->length);
            if (ret > 0) {
                ++usable;

    https://github.com/vdukhovni/postfix/blob/33701748e11d4b8a25a34aaafce2aa2f02d1ffb2/postfix/src/tls/tls_dane.c#L843-L848

        }
        if (rpk_compat)
            tls_enable_server_rpk(NULL, ssl);

        return (usable);
    }

This is then checked in the TLS client code:

    https://github.com/vdukhovni/postfix/blob/33701748e11d4b8a25a34aaafce2aa2f02d1ffb2/postfix/src/tls/tls_client.c#L1114-L1169

-- 
    Viktor.

-- 
You received this message because you are subscribed to the Google Groups "openssl-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openssl-users+unsubscribe@xxxxxxxxxxx.
To view this discussion visit https://groups.google.com/a/openssl.org/d/msgid/openssl-users/ZyGd4aBB7YENi7tz%40chardros.imrryr.org.



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux