Test tool havedane.net and NCSC-NL factsheet on DANE
1. Check this new tool for testing if your mail server checks DANE when sending email: https://havedane.net 2. Recently the Dutch NCSC published a factsheet "Secure the connections of mail servers" with regard to DANE and STARTTLS. See: https://www.ncsc.nl/english/current-topics/factsheets/factsheet-secure-the-c... -- Best regards, Bart Knubben
On May 18, 2017, at 3:23 AM, Bart Knubben
wrote: 1. Check this new tool for testing if your mail server checks DANE when sending email: https://havedane.net
It is a step in the right direction, though testing should ultimately
be much more comprehensive.
* Test that "expired" certificates are accepted with DANE-EE(3)
* Test that matching hostnames are not required with DANE-EE(3)
* Test multiple DANE-EE(3) SPKI(1) SHA2-256(1) records with
just one matching the chain.
* Probe for digest agility support, test a working SHA2-512(2)
a non-working SHA2-256(1) and vice versa.
* Test DANE-TA(2) support with TA certificate in the server chain
* Test DANE-TA(2) with wildcard leaf certificate.
* Test DANE-TA(2) with expired leaf certificates, or non-matching
DNS-ID.
* Test optional DANE-TA(2) SPKI(1) Full(0) support with the trust
anchor public key in DNS and the full certificate NOT provided
in the chain (Postfix supports this, other MTAs might not. Per
RFC7671 support this corner case is optional, and servers MUST
include the trust anchor CA certificate in their chain.
* Test support for a combination of a DANE-TA(2) and a DANE-EE(3)
--
Viktor.
(both cases).
* Test TLSA record lookup failures (broken RRsig, broken denial of
existence, ...)
* Test DNSSEC-signed domains with MX hostnames in an unsigned zone.
Their TLSA records should not be looked up (delegate "_tcp" to
non-responding and perhaps query-logging servers, sender should
not be delayed by trying to look these up).
...
If you want to check that your Postfix is doing DANE minimally correctly
per this site, just try:
$ myemail=...
$ sendmail -bv -f $myemail probe-rcpt@wrong.havedane.net
$ sendmail -bv -f $myemail probe-rcpt@do.havedane.net
$ sendmail -bv -f $myemail probe-rcpt@dont.havedane.net
Then check your logs. You should see something along the lines of:
May 18 10:10:59 amnesiac postfix/pickup[60085]: B48AC3904F: uid=1001 from=<...>
May 18 10:10:59 amnesiac postfix/cleanup[60313]: B48AC3904F: message-id=<20170518141059.B48AC3904F@amnesiac.imrryr.org>
May 18 10:10:59 amnesiac postfix/qmgr[17091]: B48AC3904F: from=<...>, size=316, nrcpt=1 (queue active)
May 18 10:11:00 amnesiac postfix/smtp[60315]: certificate verification failed for wrong.havedane.net[5.79.70.105]:25: untrusted issuer /C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=MyOrganizationalUnit/CN=Fort-Funston CA/name=EasyRSA/emailAddress=me@myhost.mydomain
May 18 10:11:00 amnesiac postfix/smtp[60315]: Untrusted TLS connection established to wrong.havedane.net[5.79.70.105]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
May 18 10:11:00 amnesiac postfix/smtp[60315]: B48AC3904F: to=
On 2017-05-18 at 10:51 -0400, Viktor Dukhovni wrote:
If you want to check that your Postfix is doing DANE minimally correctly per this site, just try:
$ myemail=... $ sendmail -bv -f $myemail probe-rcpt@wrong.havedane.net $ sendmail -bv -f $myemail probe-rcpt@do.havedane.net $ sendmail -bv -f $myemail probe-rcpt@dont.havedane.net
Then check your logs. You should see something along the lines of:
I just sent one email to all three addresses using my MUA. Seems easier. ;) Exim passes; `exim -Mvl` on the message left on the queue because of `wrong.havedane.net` yields: 2017-05-18 22:08:49 Received from [censored] H=(tower.spodhuis.org) [censored]:29796 I=[censored]:587 P=esmtpa A=auth_gssapi:[censored] S=613 id=20170518220848.GA91791@tower.spodhuis.org 2017-05-18 22:08:49 dc6f134be71d9a96@do.havedane.net: remote_dksign transport succeeded 2017-05-18 22:08:49 dc6f134be71d9a96@dont.havedane.net: remote_dksign transport succeeded 2017-05-18 22:08:50 dc6f134be71d9a96@wrong.havedane.net R=outbound_signed T=remote_dksign defer (-37) H=wrong.havedane.net [5.79.70.105]:25: failure while setting up TLS session The per-message logs are not as helpful to why TLS verification failed, but the mainlog has more details (if configured appropriately with log_selector). The `DS` field flags DNSSEC secure results, the `CV=dane` is Certificate Verification. -----------------------------8< mainlog >8------------------------------ 2017-05-18 22:08:49 [91803] 1dBTbE-000Nsg-Vq => dc6f134be71d9a96@do.havedane.net F=<...> P=<...> R=outbound_signed T=remote_dksign H=do.havedane.net DS [2001:1af8:4700:a118:90::7c0]:25 I=[2a02:898:31:0:48:4558:736d:7470]:29798 X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=dane DN="/C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=MyOrganizationalUnit/CN=do.havedane.net/name=EasyRSA/emailAddress=me@myhost.mydomain" C="250 2.0.0 Ok: queued as CF3D2C0CF4" QT=1s DT=0s 2017-05-18 22:08:49 [91803] 1dBTbE-000Nsg-Vq => dc6f134be71d9a96@dont.havedane.net F=<...> P=<...> R=outbound_signed T=remote_dksign H=dont.havedane.net DS [2001:1af8:4700:a118:90::7c0]:25 I=[2a02:898:31:0:48:4558:736d:7470]:29797 X=TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256 CV=no DN="/C=US/ST=CA/L=SanFrancisco/O=Fort-Funston/OU=MyOrganizationalUnit/CN=do.havedane.net/name=EasyRSA/emailAddress=me@myhost.mydomain" C="250 2.0.0 Ok: queued as D82F2C0CF5" QT=1s DT=0s 2017-05-18 22:08:49 [91807] 1dBTbE-000Nsg-Vq H=wrong.havedane.net [2001:1af8:4700:a118:90::7c0] TLS error on connection (SSL_connect): error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed 2017-05-18 22:08:49 [91807] 1dBTbE-000Nsg-Vq DANE attempt failed; no TLS connection to wrong.havedane.net [2001:1af8:4700:a118:90::7c0] 2017-05-18 22:08:50 [91807] 1dBTbE-000Nsg-Vq H=wrong.havedane.net [5.79.70.105] TLS error on connection (SSL_connect): error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed 2017-05-18 22:08:50 [91807] 1dBTbE-000Nsg-Vq DANE attempt failed; no TLS connection to wrong.havedane.net [5.79.70.105] 2017-05-18 22:08:50 [91803] 1dBTbE-000Nsg-Vq == dc6f134be71d9a96@wrong.havedane.net R=outbound_signed T=remote_dksign defer (-37) H=wrong.havedane.net [5.79.70.105]:25: failure while setting up TLS session -----------------------------8< mainlog >8------------------------------ We might still have a corner case to handle, but the critical functionality is all there, securing connections. -Phil
participants (3)
-
Bart Knubben -
Phil Pennock -
Viktor Dukhovni