Dane testing and posttls-finger ???
When I try "posttls-finger dane.sys4.de" I get the following. I have emphasized a couple of areas in the following text that cause me some concern.
posttls-finger: Connected to dane.sys4.de[194.126.158.134]:25 posttls-finger: < 220 dane.sys4.de ESMTP Postfix posttls-finger: > EHLO smtp.klam.ca posttls-finger: < 250-dane.sys4.de posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 10240000 posttls-finger: < 250-ETRN posttls-finger: < 250-STARTTLS posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250 DSN posttls-finger: > STARTTLS posttls-finger: < 220 2.0.0 Ready to start TLS posttls-finger: dane.sys4.de[194.126.158.134]:25: Matched subjectAltName: dane.sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25: subjectAltName: sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25 CommonName dane.sys4.de posttls-finger:*certificate verification failed* for dane.sys4.de[194.126.158.134]:25: untrusted issuer /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Certification Authority posttls-finger: dane.sys4.de[194.126.158.134]:25: subject_CN=dane.sys4.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=41:B5:70:D5:35:68:72:B2:64:4C:5E:DE:74:52:23:E1:3B:3A:03:07, pkey_fingerprint=E5:CD:96:DD:35:8C:91:30:75:5B:D0:66:47:1D:CD:83:39:9A:D5:CC posttls-finger:*Untrusted TLS connection *established to dane.sys4.de[194.126.158.134]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits) posttls-finger: > EHLO smtp.klam.ca posttls-finger: < 250-dane.sys4.de posttls-finger: < 250-PIPELINING posttls-finger: < 250-SIZE 10240000 posttls-finger: < 250-ETRN posttls-finger: < 250-ENHANCEDSTATUSCODES posttls-finger: < 250-8BITMIME posttls-finger: < 250 DSN posttls-finger: > QUIT posttls-finger: < 221 2.0.0 Bye
Certificate verification fails and I wind up with an untrusted connection. Is this something I did or is there a real problem?
John A
On Thu, Apr 09, 2015 at 08:40:27AM -0400, John Allen wrote:
When I try "posttls-finger dane.sys4.de" I get the following. I have emphasized a couple of areas in the following text that cause me some concern.
posttls-finger: Connected to dane.sys4.de[194.126.158.134]:25
No TLSA records were found. Your DNS resolver is not returning the "AD" bit for this domain. Check /etc/resolv.conf.
I get:
$ posttls-finger -c dane.sys4.de posttls-finger: using DANE RR: _25._tcp.dane.sys4.de IN TLSA 3 0 1 C8:B7:60:93:10:0F:05:3B:95:B5:12:DA:D8:B5:9B:B3:43:02:F7:6B:A8:C0:7E:D8:7F:BF:56:65:BF:05:F1:D1 posttls-finger: dane.sys4.de[194.126.158.134]:25: depth=0 matched end entity certificate sha256 digest C8:B7:60:93:10:0F:05:3B:95:B5:12:DA:D8:B5:9B:B3:43:02:F7:6B:A8:C0:7E:D8:7F:BF:56:65:BF:05:F1:D1 posttls-finger: dane.sys4.de[194.126.158.134]:25: Matched subjectAltName: dane.sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25: subjectAltName: sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25 CommonName dane.sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25: subject_CN=dane.sys4.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=41:B5:70:D5:35:68:72:B2:64:4C:5E:DE:74:52:23:E1:3B:3A:03:07, pkey_fingerprint=E5:CD:96:DD:35:8C:91:30:75:5B:D0:66:47:1D:CD:83:39:9A:D5:CC posttls-finger: Verified TLS connection established to dane.sys4.de[194.126.158.134]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
With the first line showing working DNSSEC resolution.
posttls-finger: Untrusted TLS connection established to dane.sys4.de[194.126.158.134]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
As a result, authentication fails, since no CAs are trusted by default, and the default security level is opportunistic "dane" not CA-based "secure".
Certificate verification fails and I wind up with an untrusted connection. Is this something I did or is there a real problem?
Your server's local DNS resolver is not a DNSSEC validating resolver. Or perhaps is not even local.
To enable outbound DANE, you need an /etc/resolv.conf with 127.0.0.1 as the only nameserver, and DNSSEC validation via the ICANN root enabled in that resolver0.
My resolve.conf points to google (8.8.8.8, 8.8.4.4 + their ipv6 equivalents). I have heard rumours of problems with Google DNS, I am not sure that I believe them but ... Is this their problem or mine (its mine because I have it) and what might be my best solution. TIA -- Sent from my Samsung Galaxy Tab 3
On 9 April, 2015 10:04:41 AM Viktor Dukhovni ietf-dane@dukhovni.org wrote:
On Thu, Apr 09, 2015 at 08:40:27AM -0400, John Allen wrote:
When I try "posttls-finger dane.sys4.de" I get the following. I have emphasized a couple of areas in the following text that cause me some concern.
posttls-finger: Connected to dane.sys4.de[194.126.158.134]:25
No TLSA records were found. Your DNS resolver is not returning the "AD" bit for this domain. Check /etc/resolv.conf.
I get:
$ posttls-finger -c dane.sys4.de posttls-finger: using DANE RR: _25._tcp.dane.sys4.de IN TLSA 3 0 1 C8:B7:60:93:10:0F:05:3B:95:B5:12:DA:D8:B5:9B:B3:43:02:F7:6B:A8:C0:7E:D8:7F:BF:56:65:BF:05:F1:D1 posttls-finger: dane.sys4.de[194.126.158.134]:25: depth=0 matched end entity certificate sha256 digest C8:B7:60:93:10:0F:05:3B:95:B5:12:DA:D8:B5:9B:B3:43:02:F7:6B:A8:C0:7E:D8:7F:BF:56:65:BF:05:F1:D1 posttls-finger: dane.sys4.de[194.126.158.134]:25: Matched subjectAltName: dane.sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25: subjectAltName: sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25 CommonName dane.sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25: subject_CN=dane.sys4.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=41:B5:70:D5:35:68:72:B2:64:4C:5E:DE:74:52:23:E1:3B:3A:03:07, pkey_fingerprint=E5:CD:96:DD:35:8C:91:30:75:5B:D0:66:47:1D:CD:83:39:9A:D5:CC posttls-finger: Verified TLS connection established to dane.sys4.de[194.126.158.134]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)With the first line showing working DNSSEC resolution.
posttls-finger: Untrusted TLS connection established to
dane.sys4.de[194.126.158.134]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
As a result, authentication fails, since no CAs are trusted by default, and the default security level is opportunistic "dane" not CA-based "secure".
Certificate verification fails and I wind up with an untrusted connection. Is this something I did or is there a real problem?
Your server's local DNS resolver is not a DNSSEC validating resolver. Or perhaps is not even local.
To enable outbound DANE, you need an /etc/resolv.conf with 127.0.0.1 as the only nameserver, and DNSSEC validation via the ICANN root enabled in that resolver0.
-- Viktor.
I ran the same test again, without changing anything, and it come back without error. not sure what that means, but just in case its of interest.
On 4/9/2015 12:09 PM, John wrote:
My resolve.conf points to google (8.8.8.8, 8.8.4.4 + their ipv6 equivalents). I have heard rumours of problems with Google DNS, I am not sure that I believe them but ... Is this their problem or mine (its mine because I have it) and what might be my best solution. TIA -- Sent from my Samsung Galaxy Tab 3
On 9 April, 2015 10:04:41 AM Viktor Dukhovni ietf-dane@dukhovni.org wrote:
On Thu, Apr 09, 2015 at 08:40:27AM -0400, John Allen wrote:
When I try "posttls-finger dane.sys4.de" I get the following. I have emphasized a couple of areas in the following text that cause me some concern.
posttls-finger: Connected to dane.sys4.de[194.126.158.134]:25
No TLSA records were found. Your DNS resolver is not returning the "AD" bit for this domain. Check /etc/resolv.conf.
I get:
$ posttls-finger -c dane.sys4.de posttls-finger: using DANE RR: _25._tcp.dane.sys4.de IN TLSA 3 01 C8:B7:60:93:10:0F:05:3B:95:B5:12:DA:D8:B5:9B:B3:43:02:F7:6B:A8:C0:7E:D8:7F:BF:56:65:BF:05:F1:D1 posttls-finger: dane.sys4.de[194.126.158.134]:25: depth=0 matched end entity certificate sha256 digest C8:B7:60:93:10:0F:05:3B:95:B5:12:DA:D8:B5:9B:B3:43:02:F7:6B:A8:C0:7E:D8:7F:BF:56:65:BF:05:F1:D1 posttls-finger: dane.sys4.de[194.126.158.134]:25: Matched subjectAltName: dane.sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25: subjectAltName: sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25 CommonName dane.sys4.de posttls-finger: dane.sys4.de[194.126.158.134]:25: subject_CN=dane.sys4.de, issuer_CN=StartCom Class 2 Primary Intermediate Server CA, fingerprint=41:B5:70:D5:35:68:72:B2:64:4C:5E:DE:74:52:23:E1:3B:3A:03:07, pkey_fingerprint=E5:CD:96:DD:35:8C:91:30:75:5B:D0:66:47:1D:CD:83:39:9A:D5:CC posttls-finger: Verified TLS connection established to dane.sys4.de[194.126.158.134]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
With the first line showing working DNSSEC resolution.
posttls-finger: Untrusted TLS connection established to
dane.sys4.de[194.126.158.134]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
As a result, authentication fails, since no CAs are trusted by default, and the default security level is opportunistic "dane" not CA-based "secure".
Certificate verification fails and I wind up with an untrusted
connection.
Is this something I did or is there a real problem?
Your server's local DNS resolver is not a DNSSEC validating resolver. Or perhaps is not even local.
To enable outbound DANE, you need an /etc/resolv.conf with 127.0.0.1 as the only nameserver, and DNSSEC validation via the ICANN root enabled in that resolver0.
-- Viktor.
On Thu, Apr 09, 2015 at 12:09:39PM -0400, John wrote:
My resolv.conf points to google (8.8.8.8, 8.8.4.4 + their ipv6 equivalents).
1. MTAs should run their own caching resolvers, even if they forward to another caching resolver upstream (e.g. 8.8.8.8).
2. If you are doing any RBL lookups, you must not make them via an upstream forwarder (avoid looking up RBLs via 8.8.8.8 and friends).
3. If you want any security from DANE when sending outbound email to remote domains, you MUST use a local 127.0.0.1 resolver that validates DNSSEC record signatures for itself.
If you're not using 'smtp_tls_security_level = dane', then the local resolver is not essential for security, but is still a good idea.
1. MTAs should run their own caching resolvers, even if they forward to another caching resolver upstream (e.g. 8.8.8.8).
I used to run a local caching server, but ran into a problem when I first started using DNSSEC. To make life a little easier while sorting out the DNSSEC problems I got rid of it. reinstated as of today. using posttls-finger now produces expected results.
2. If you are doing any RBL lookups, you must not make them via an upstream forwarder (avoid looking up RBLs via 8.8.8.8 and friends).
A little thought and this is obvious.
3. If you want any security from DANE when sending outbound email to remote domains, you MUST use a local 127.0.0.1 resolver that validates DNSSEC record signatures for itself.
done, but why?
If you're not using 'smtp_tls_security_level = dane', then the local resolver is not essential for security, but is still a good idea.
On Fri, Apr 10, 2015 at 10:30:25PM -0400, John Allen wrote:
3. If you want any security from DANE when sending outbound email to remote domains, you MUST use a local 127.0.0.1 resolver that validates DNSSEC record signatures for itself.done, but why?
Because Postfix trusts whatever resolver it queries, DNSSEC validation is performed only by the resolver. DANE is supposed to protect you from MiTM attacks, but if you trust packets purportedly from 8.8.8.8, you're leaving yourself open to MiTM attacks. Thus DANE via remote trusted resolvers is pointless.
On 10/04/2015 11:17 PM, Viktor Dukhovni wrote:
On Fri, Apr 10, 2015 at 10:30:25PM -0400, John Allen wrote:
3. If you want any security from DANE when sending outbound email to remote domains, you MUST use a local 127.0.0.1 resolver that validates DNSSEC record signatures for itself.done, but why?
Because Postfix trusts whatever resolver it queries, DNSSEC validation is performed only by the resolver. DANE is supposed to protect you from MiTM attacks, but if you trust packets purportedly from 8.8.8.8, you're leaving yourself open to MiTM attacks. Thus DANE via remote trusted resolvers is pointless.
OK, makes sense and I should have been able to answer that one on my own, I am getting old and far too trusting. Or maybe I have been retired too long and am beginning to forget that the internet is a pool full of piranhas. Or much more likely I need to engage brain more often. Anyway, thanks for answering my dumb questions. John A
participants (3)
-
John -
John Allen
-
Viktor Dukhovni