[exim] Re: Follow-Up: Debug TLS/DANE problems / GnuTLS?

Pàgina inicial
Delete this message
Reply to this message
Autor: Viktor Dukhovni via Exim-users
Data:  
A: exim-users
Assumpte: [exim] Re: Follow-Up: Debug TLS/DANE problems / GnuTLS?
On Fri, Jul 05, 2024 at 02:01:38PM +0200, Wolfgang via Exim-users wrote:


> I am much more familar with openssl, but debian-exim is linked against
> gnu-tls, so I started digging in gnttls binary tools also.
> Unfortunately gnutls-cli is far less capable, that the openssl cli
> tools. I started the following openssl-test:
>
> >echo "quit" | openssl s_client -starttls smtp -connect mx06.et.lindenberg.one:25 -4 -verify 9 \
> >    -dane_tlsa_domain mx06.et.lindenberg.one \
> >    -dane_tlsa_rrdata "2 1 1 BD936E72B212EF6F773102C6B77D38F94297322EFC25396BC3279422E0C89270"\
> >    -dane_tlsa_rrdata "2 1 1 E5545E211347241891C554A03934CDE9B749664A59D26D615FE58F77990F2D03"\
> >    -dane_tlsa_rrdata "2 1 1 F1647A5EE3EFAC54C892E930584FE47979B7ACD1C76C1271BCA1C5076D869888"\
> >    -dane_tlsa_rrdata "2 1 1 025490860B498AB73C6A12F27A49AD5FE230FAFE3AC8F6112C9B7D0AAD46941D"\
> >    -dane_tlsa_rrdata "2 1 1 276FE8A8C4EC7611565BF9FCE6DCACE9BE320C1B5BEA27596B2204071ED04F10"\
> >    -dane_tlsa_rrdata "2 1 1 2BBAD93AB5C79279EC121507F272CBE0C6647A3AAE52E22F388AFAB426B4ADBA"\
> >    -dane_tlsa_rrdata "2 1 1 6DDAC18698F7F1F7E1C69B9BCE420D974AC6F94CA8B2C761701623F99C767DC7"\
> >    -dane_tlsa_rrdata "2 1 1 8D02536C887482BC34FF54E41D2BA659BF85B341A0A20AFADB5813DCFBCF286D"\
> >    -dane_tlsa_rrdata "2 1 1 919C0DF7A787B597ED056ACE654B1DE9C0387ACF349F73734A4FD7B58CF612A4"\
> >    -sigalgs rsa_pkcs1_sha256:rsa_pkcs1_sha384:rsa_pkcs1_sha512:rsa_pss_rsae_sha256:rsa_pss_rsae_sha384:rsa_pss_rsae_sha512:rsa_pss_pss_sha256:rsa_pss_pss_sha384:rsa_pss_pss_sha5

>
> the dane_tls_rrdata are the dns RR, i got before from a dns-lookup (as I found here now way, to tell
> openssl to do that by its own).


That's deliberate, OpenSSL does not want to depend on api particular DNS
API, some of which in turn depend on OpenSSL, nor is the OpenSSL DANE
support limited to TLSA records obtained from DNS, in various important
use-cases the TLSA records are locally synthesised. It is easy to write
a shell function that does the DNS lookups for you, and the invokes
"s_client" with the right arguments:

    danesmtp () {
        local OPTIND=1 opt
        local -a rrs sslopts
        local rr i=0 host addr


        while getopts a: opt; do
            case $opt in
            a) addr=$OPTARG
               case $addr in
               *:*) addr="[$addr]" ;;
               esac;;
            *) printf 'usage: danesmtp [-a addr] host [ssloption ...]\n'
               return 1 ;;
            esac
        done
        shift $((OPTIND - 1))
        host=$1; shift
        if [[ -z "$addr" ]]; then addr="$host"; fi


        sslopts=(
            -starttls smtp 
            -connect "$addr:25" 
            -brief
            -verify 9 
            -verify_return_error 
            -dane_ee_no_namechecks 
            -dane_tlsa_domain "$host"
            )


        rrs=($(dig +short +nosplit -t tlsa "_25._tcp.$host" |
               grep -Ei '^[23] [01] [012] [0-9a-f]+$'))
        while (( i < ${#rrs[@]} - 3 )); do
            rr=${rrs[@]:$i:4}
            i=$((i+4))
            sslopts=("${sslopts[@]}" "-dane_tlsa_rrdata" "$rr")
        done


        ( sleep 1; printf "QUIT\r\n" ) |
            openssl s_client "${sslopts[@]}" "$@"
    }


> The result matches my own findings:
>
> >Verification: OK
> >Verified peername: mx06.et.lindenberg.one
> >DANE TLSA 2 1 1 ...a0a20afadb5813dcfbcf286d matched TA certificate at depth 1
> >Verify return code: 0 (ok)


Yes, the host in question has a certificate chain that matches one of
its "2 1 1" (R3) TLSA records. The EE cert keyUsage and
extendedKeyUsage look normal:

            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication


and unsurprisingly "R3" is fine as well.

> Now I used the gnutls danetool, which is capable to pull the tlsa-RRs from DNS.
>
> > danetool --check mx06.et.lindenberg.one --proto tcp --port 25
>
> The resulting reports raises some questions:
>
> >Resolving 'mx06.et.lindenberg.one:smtp'...
> >Obtaining certificate from '85.215.77.84:25'...
> >Querying DNS for mx06.et.lindenberg.one (tcp:25)...
> >
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 025490860b498ab73c6a12f27a49ad5fe230fafe3ac8f6112c9b7d0aad46941d )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 276fe8a8c4ec7611565bf9fce6dcace9be320c1b5bea27596b2204071ed04f10 )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 2bbad93ab5c79279ec121507f272cbe0c6647a3aae52e22f388afab426b4adba )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 6ddac18698f7f1f7e1c69b9bce420d974ac6f94ca8b2c761701623f99c767dc7 )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 8d02536c887482bc34ff54e41d2ba659bf85b341a0a20afadb5813dcfbcf286d )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 919c0df7a787b597ed056ace654b1de9c0387acf349f73734a4fd7b58cf612a4 )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 bd936e72b212ef6f773102c6b77d38f94297322efc25396bc3279422e0c89270 )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 e5545e211347241891c554a03934cde9b749664a59d26d615fe58f77990f2d03 )
> >Verification: Certificate matches.
> >_25._tcp.mx06.et.lindenberg.one. IN TLSA ( 02 01 01 f1647a5ee3efac54c892e930584fe47979b7acd1c76c1271bca1c5076d869888 )
> >Verification: Certificate matches.
>
> What is gnutls comparing? Why it tells me, that all 9 tlsa-RRs are
> matching?


The most charitable interpretation of the above is that the status
reported is global, rather than per TLSA record, and so for each
RR it reports the same fact, that some TLSA record matched?

Otherwise, it does seem non-sensical. If you want working DANE support
in Exim, use the OpenSSL-based build.

> I would have expected some other results, explaining why gnutls inside
> exim tells me: "Key usage violation in certificate has been detected"


This is rather odd. The key is not being used for anything expected as
far as I can tell. FWIW, the EE certificate does specify an OSCP URI:

        Authority Information Access:
            OCSP - URI:http://r3.o.lencr.org
            CA Issuers - URI:http://r3.i.lencr.org/


but I don't expect that the key usage issue lies there, so it is
a mystery to me.

-- 
    Viktor.


--
## subscription configuration (requires account):
## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/
## unsubscribe (doesn't require an account):
## exim-users-unsubscribe@???
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/