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...
On May 18, 2017, at 3:23 AM, Bart Knubben bart@knubben.org wrote:
- 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)
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