> On Apr 25, 2017, at 8:27 AM, Nicola Tiling <nti@???> wrote:
>
> Thanks for your answer. There is no possibility to know whether DANE
> is working correctly for incoming mails unless I have access to
> the server logfiles from the sending server?
Correct, but, if I recall correctly, you said earlier that you tested
your domain at dane.sys4.de, which is a pretty good indication that
your configuration is correct.
The "s_client" program in OpenSSL 1.1.0 can verify the DANE TLSA
records of SMTP servers. The OpenSSL s_client example is at:
https://www.openssl.org/docs/man1.1.0/apps/s_client.html
See the text under `-dane_tlsa_rrdata rrdata (tweaked below to
return a machine-readable exit code for verification success/failure):
$ (sleep 5; printf "QUIT\r\n") |
openssl s_client -verify 9 -verify_return_error -brief -starttls smtp \
-connect smtp.example.com:25 \
-dane_tlsa_domain smtp.example.com \
-dane_tlsa_rrdata "2 1 1
B111DD8A1C2091A89BD4FD60C57F0716CCE50FEEFF8137CDBEE0326E 02CF362B" \
-dane_tlsa_rrdata "2 1 1
60B87575447DCBA2A36B7D11AC09FB24A9DB406FEE12D2CC90180517 616E8A18"
...
Verification: OK
Verified peername: smtp.example.com
DANE TLSA 2 1 1 ...ee12d2cc90180517616e8a18 matched TA certificate at depth 1
...
You need to do the verified TLSA lookups (AD bit check) with 'dig'
or some other tool, extract the records with usage 2 or 3, and run
a command such as the above with the returned data, one "-dane_tlsa_rrdata"
option per TLSA record.
You can test either all the TLSA records together in one command, and learn
wether at least one works (which is sufficient), or one at a time in a loop,
and learn which records match and which don't. Having some records that don't
match is expected during key/cert rollover, but should not be a long-term state.
The other tool that can verify TLSA records is "posttls-finger",
from the Postfix 2.11 or later source distribution. Some O/S
version (e.g. Debian IIRC) bundle posttls-finger with their
Postfix releases.
Phil Pennock has a DANE SMTP verifier written in Go.
I might also mention that Exim's DANE support is not yet feature-complete.
It is still vulnerable to active downgrade attacks by tampering with the
TLSA RRset in DNS responses. When TLSA lookups fail, Exim continues without
DANE, while RFC7672 explains that DANE clients need to skip the associated
MX host in that case in order to avoid downgrade attacks.
--
Viktor.
