Try dane and still got "Untrusted TLS connection..."

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
gao
Reply | Threaded
Open this post in threaded view
|

Try dane and still got "Untrusted TLS connection..."

gao
Hi,

I am trying to setup dane on my mail server. But I never seen a "Verified TLS connection..." in the log. I always got:
Oct 26 13:52:23 cac postfix/smtp[18165]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[74.125.124.26]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

My system is Postfix 3.2.3 on Centos 7.4
# postconf -d | grep mail_version
mail_version = 3.2.3


main.cf:
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_loglevel = 1


DNSSEC has been setup and added TLSA record. Passed test at https://www.huque.com/bin/danecheck and https://dane.sys4.de/

TLSA records found: 1
TLSA: 3 1 1 f2545e3b5b42c7d309127c3a7f326b509f8bd199daf950d5f5bbf7530c7dc616

Connecting to IPv4 address: 45.62.235.110 port 25
recv: 220 cac.mydomain.com ESMTP Postfix
send: EHLO cheetara.huque.com
recv: 250-cac.mydomain.com
recv: 250-PIPELINING
recv: 250-SIZE 10240000
recv: 250-VRFY
recv: 250-ETRN
recv: 250-STARTTLS
recv: 250-ENHANCEDSTATUSCODES
recv: 250-8BITMIME
recv: 250 DSN
send: STARTTLS
recv: 220 2.0.0 Ready to start TLS
TLSv1.2 handshake succeeded.
Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
Peer Certificate chain:
 0 Subject CN: cac.mydomain.com
   Issuer  CN: Let's Encrypt Authority X3
 1 Subject CN: Let's Encrypt Authority X3
   Issuer  CN: DST Root CA X3
 SAN dNSName: cac.mydomain.com
 SAN dNSName: mydomain.com
DANE TLSA 3 1 1 [f2545e3b5b42...] matched EE certificate at depth 0
Validated Certificate chain:
 0 Subject CN: cac.mydomain.com
   Issuer  CN: Let's Encrypt Authority X3
 SAN dNSName: cac.mydomain.com
 SAN dNSName: mydomain.com

[0] Authentication succeeded for all (1) peers.


So I must missed something... I can't figure it out. Please help.


Thanks.

Gao

Reply | Threaded
Open this post in threaded view
|

Re: Try dane and still got "Untrusted TLS connection..."

Christian Kivalo


Am 26. Oktober 2017 23:08:16 MESZ schrieb Gao <[hidden email]>:

>Hi,
>
>I am trying to setup dane on my mail server. But I never seen a
>"Verified TLS connection..." in the log. I always got:
>Oct 26 13:52:23 cac postfix/smtp[18165]: Untrusted TLS connection
>established to gmail-smtp-in.l.google.com[74.125.124.26]:25: TLSv1.2
>with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)
>
>My system is Postfix 3.2.3 on Centos 7.4
># postconf -d | grep mail_version
>mail_version = 3.2.3
>
>main.cf:
>smtp_dns_support_level = dnssec
>smtp_tls_security_level = dane
>smtp_tls_loglevel = 1
>
>DNSSEC has been setup and added TLSA record. Passed test at
>https://www.huque.com/bin/danecheck and https://dane.sys4.de/
>
>TLSA records found: 1
>TLSA: 3 1 1
>f2545e3b5b42c7d309127c3a7f326b509f8bd199daf950d5f5bbf7530c7dc616
>
>Connecting to IPv4 address: 45.62.235.110 port 25
>recv: 220 cac.mydomain.com ESMTP Postfix
>send: EHLO cheetara.huque.com
>recv: 250-cac.mydomain.com
>recv: 250-PIPELINING
>recv: 250-SIZE 10240000
>recv: 250-VRFY
>recv: 250-ETRN
>recv: 250-STARTTLS
>recv: 250-ENHANCEDSTATUSCODES
>recv: 250-8BITMIME
>recv: 250 DSN
>send: STARTTLS
>recv: 220 2.0.0 Ready to start TLS
>TLSv1.2 handshake succeeded.
>Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
>Peer Certificate chain:
>  0 Subject CN: cac.mydomain.com
>    Issuer  CN: Let's Encrypt Authority X3
>  1 Subject CN: Let's Encrypt Authority X3
>    Issuer  CN: DST Root CA X3
>  SAN dNSName: cac.mydomain.com
>  SAN dNSName: mydomain.com
>DANE TLSA 3 1 1 [f2545e3b5b42...] matched EE certificate at depth 0
>Validated Certificate chain:
>  0 Subject CN: cac.mydomain.com
>    Issuer  CN: Let's Encrypt Authority X3
>  SAN dNSName: cac.mydomain.com
>  SAN dNSName: mydomain.com
>
>[0] Authentication succeeded for all (1) peers.
>
>So I must missed something... I can't figure it out. Please help.
It looms you have your inbound dane config setup and Dane checking systems can utilize Dane to verify your certs.

You will only have "verified" in your logs when you /send/ mail to a Dane enabled domain. Try this service to check your outbound Dane config:
https://havedane.net/


>Thanks.
>
>Gao

--
Christian Kivalo
gao
Reply | Threaded
Open this post in threaded view
|

Re: Try dane and still got "Untrusted TLS connection..."

gao


On 2017-10-26 02:58 PM, Christian Kivalo wrote:

Am 26. Oktober 2017 23:08:16 MESZ schrieb Gao [hidden email]:
Hi,

I am trying to setup dane on my mail server. But I never seen a 
"Verified TLS connection..." in the log. I always got:
Oct 26 13:52:23 cac postfix/smtp[18165]: Untrusted TLS connection 
established to gmail-smtp-in.l.google.com[74.125.124.26]:25: TLSv1.2 
with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

My system is Postfix 3.2.3 on Centos 7.4
# postconf -d | grep mail_version
mail_version = 3.2.3

main.cf:
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_loglevel = 1

DNSSEC has been setup and added TLSA record. Passed test at 
https://www.huque.com/bin/danecheck and https://dane.sys4.de/

TLSA records found: 1
TLSA: 3 1 1
f2545e3b5b42c7d309127c3a7f326b509f8bd199daf950d5f5bbf7530c7dc616

Connecting to IPv4 address: 45.62.235.110 port 25
recv: 220 cac.mydomain.com ESMTP Postfix
send: EHLO cheetara.huque.com
recv: 250-cac.mydomain.com
recv: 250-PIPELINING
recv: 250-SIZE 10240000
recv: 250-VRFY
recv: 250-ETRN
recv: 250-STARTTLS
recv: 250-ENHANCEDSTATUSCODES
recv: 250-8BITMIME
recv: 250 DSN
send: STARTTLS
recv: 220 2.0.0 Ready to start TLS
TLSv1.2 handshake succeeded.
Cipher: TLSv1.2 ECDHE-RSA-AES256-GCM-SHA384
Peer Certificate chain:
 0 Subject CN: cac.mydomain.com
   Issuer  CN: Let's Encrypt Authority X3
 1 Subject CN: Let's Encrypt Authority X3
   Issuer  CN: DST Root CA X3
 SAN dNSName: cac.mydomain.com
 SAN dNSName: mydomain.com
DANE TLSA 3 1 1 [f2545e3b5b42...] matched EE certificate at depth 0
Validated Certificate chain:
 0 Subject CN: cac.mydomain.com
   Issuer  CN: Let's Encrypt Authority X3
 SAN dNSName: cac.mydomain.com
 SAN dNSName: mydomain.com

[0] Authentication succeeded for all (1) peers.

So I must missed something... I can't figure it out. Please help.
It looms you have your inbound dane config setup and Dane checking systems can utilize Dane to verify your certs. 

You will only have "verified" in your logs when you /send/ mail to a Dane enabled domain. Try this service to check your outbound Dane config:
https://havedane.net/



Thank you for the information. I tested at the site and m=now my maillog shows:

Oct 26 15:43:18 cac postfix/smtp[19178]: connect to dont.havedane.net[2001:1af8:4700:a118:90::7c0]:25: Network is unreachable
Oct 26 15:43:18 cac postfix/smtp[19179]: connect to wrong.havedane.net[2001:1af8:4700:a118:90::7c0]:25: Network is unreachable
Oct 26 15:43:19 cac postfix/smtp[19179]: 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 [hidden email]
Oct 26 15:43:19 cac postfix/smtp[19179]: 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)
Oct 26 15:43:19 cac postfix/smtp[19178]: Anonymous TLS connection established to dont.havedane.net[5.79.70.105]:25: TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)
Oct 26 15:43:19 cac postfix/smtp[19174]: Verified TLS connection established to do.havedane.net[5.79.70.105]:25: TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Oct 26 15:43:19 cac postfix/smtp[19179]: 1687A20C5404: to=[hidden email], relay=wrong.havedane.net[5.79.70.105]:25, delay=12, delays=11/0.07/1.5/0, dsn=4.7.5, status=deferred (Server certificate not trusted)
Oct 26 15:43:19 cac postfix/smtp[19178]: 1687A20C5404: to=[hidden email], relay=dont.havedane.net[5.79.70.105]:25, delay=12, delays=11/0.06/1.7/0.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as B22A8C0867)
Oct 26 15:43:19 cac postfix/smtp[19174]: 1687A20C5404: to=[hidden email], relay=do.havedane.net[5.79.70.105]:25, delay=12, delays=11/0.04/1.7/0.2, dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as B8636C0868)


I tested before by sending email to a Gmail account.  I was wrong to think Gmail support DANE and they probably don't.

Thanks a lot!
Gao
Reply | Threaded
Open this post in threaded view
|

Re: Try dane and still got "Untrusted TLS connection..."

Viktor Dukhovni
In reply to this post by gao


> On Oct 26, 2017, at 5:08 PM, Gao <[hidden email]> wrote:
>
> I am trying to setup dane on my mail server.

Thanks for been an early adopter.  Your enthusiasm is appreciated.
Don't forget to *monitor* your deployment, by periodically (at
least daily) checking that your DNSSEC is working and your
SMTP server certificate chain matches the published TLSA
records.  Make sure you understand how to do certificate
rotation correctly:

   http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444
   https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766
   https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/
   https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
   http://tools.ietf.org/html/rfc7671#section-8.1
   http://tools.ietf.org/html/rfc7671#section-8.4

By combining "3 1 1" + "2 1 1" TLSA records, the rollover process can be
substantially simplified:

   https://www.ietf.org/mail-archive/web/uta/current/msg01498.html

> But I never seen a "Verified TLS connection..." in the log.
> I always got:
> Oct 26 13:52:23 cac postfix/smtp[18165]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[74.125.124.26]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

There are two prerequisites for DANE verification to happen:

   1. Your DNS resolver in /etc/resolv.conf needs to be a *validating*
      DNS resolver and for any meaningful security must be either on
      the loopback interface or reachable via a securely keyed IPsec
      tunnel or similar.

AND

   2.  The destination domain and its MX host must be in DNSSEC signed
       zones

   3.  The MX host must have TLSA records published.

Conditions 2 and 3 are false for google's MX hosts.

> My system is Postfix 3.2.3 on Centos 7.4
> # postconf -d | grep mail_version
> mail_version = 3.2.3
>
> main.cf:
> smtp_dns_support_level = dnssec
> smtp_tls_security_level = dane
> smtp_tls_loglevel = 1

Condition 1 may be false for your system.

--
        Viktor.

gao
Reply | Threaded
Open this post in threaded view
|

Re: Try dane and still got "Untrusted TLS connection..."

gao

On 2017-10-26 17:02, Viktor Dukhovni wrote:



On Oct 26, 2017, at 5:08 PM, Gao <[hidden email]> wrote:

I am trying to setup dane on my mail server.

Thanks for been an early adopter.  Your enthusiasm is appreciated.
Don't forget to *monitor* your deployment, by periodically (at
least daily) checking that your DNSSEC is working and your
SMTP server certificate chain matches the published TLSA
records.  Make sure you understand how to do certificate
rotation correctly:

   http://postfix.1071664.n5.nabble.com/WoSign-StartCom-CA-in-the-news-td86436.html#a86444
   https://community.letsencrypt.org/t/new-certbot-client-and-csr-option/15766
   https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/
   https://community.letsencrypt.org/t/please-avoid-3-0-1-and-3-0-2-dane-tlsa-records-with-le-certificates/7022
   http://tools.ietf.org/html/rfc7671#section-8.1
   http://tools.ietf.org/html/rfc7671#section-8.4

By combining "3 1 1" + "2 1 1" TLSA records, the rollover process can be
substantially simplified:

   https://www.ietf.org/mail-archive/web/uta/current/msg01498.html

But I never seen a "Verified TLS connection..." in the log.
I always got:
Oct 26 13:52:23 cac postfix/smtp[18165]: Untrusted TLS connection established to gmail-smtp-in.l.google.com[74.125.124.26]:25: TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)

There are two prerequisites for DANE verification to happen:

   1. Your DNS resolver in /etc/resolv.conf needs to be a *validating*
      DNS resolver and for any meaningful security must be either on
      the loopback interface or reachable via a securely keyed IPsec
      tunnel or similar.

AND

   2.  The destination domain and its MX host must be in DNSSEC signed
       zones

   3.  The MX host must have TLSA records published.

Conditions 2 and 3 are false for google's MX hosts.

My system is Postfix 3.2.3 on Centos 7.4
# postconf -d | grep mail_version
mail_version = 3.2.3

main.cf:
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
smtp_tls_loglevel = 1

Condition 1 may be false for your system.

 

For the DNS part (condition 1) I run a local bind DNS server. The named.conf have lines:

forward only;
forwarders {
    8.8.8.8;
    8.8.4.4;
};

dnssec-enable yes;
dnssec-validation yes;

And in ifconfig-eth0 I have: (CentOS 7 use networkmanager so the DNS setting is no longer in resolv.conf  )

DNS1=0.0.0.0

I think this will take care the *validating* DNSSEC issue, am I right?

I'll start working on the cert automatic rotation issue. I am using Lets Encrypt so I have to solve it. 

Cheers,

 

Gao

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Try dane and still got "Untrusted TLS connection..."

Viktor Dukhovni


> On Oct 27, 2017, at 12:34 AM, [hidden email] wrote:
>
> For the DNS part (condition 1) I run a local bind DNS server. The named.conf have lines:
>
> forward only;
> forwarders {
>     8.8.8.8;
>     8.8.4.4;
> };
>
> dnssec-enable yes;
> dnssec-validation yes;

Personally, I would not choose to forward all my DNS queries to
Google they collect enough information about everyone already.

Otherwise, this is fine, but you also need to make sure that you've
implemented RFC 5011 automatic root trust anchor rollover.  While
the originally planned root key was postponed from this month to
some time in 2018, it will eventually happen.  So every reading
this list who's using a validating resolver needs to be sure that
their resolvers are doing automated root zone key tracking.

--
        Viktor.

Reply | Threaded
Open this post in threaded view
|

Re: Try dane and still got "Untrusted TLS connection..."

Kris Deugau
In reply to this post by Viktor Dukhovni
Viktor Dukhovni wrote:
> There are two prerequisites for DANE verification to happen:
>
>    1. Your DNS resolver in /etc/resolv.conf needs to be a *validating*
>       DNS resolver and for any meaningful security must be either on
>       the loopback interface or reachable via a securely keyed IPsec
>       tunnel or similar.

I'm curious how necessary this really is in the case of "many" servers
all talking to a local cache on the same switch.  Do I really have to
set up IPsec tunnels for DANE-friendly DNS resolution on those machines?

Setting up a cache on each machine would be simpler, but then you lose
the benefit of merging cached results from multiple requesting systems -
you end up either forwarding to another local cache anyway, or
multiplying your external DNS lookup traffic by the number of servers in
the cluster.

-kgd
Reply | Threaded
Open this post in threaded view
|

Re: Try dane and still got "Untrusted TLS connection..."

Viktor Dukhovni


> On Oct 27, 2017, at 10:29 AM, Kris Deugau <[hidden email]> wrote:
>
>> There are two prerequisites for DANE verification to happen:
>>
>>   1. Your DNS resolver in /etc/resolv.conf needs to be a *validating*
>>      DNS resolver and for any meaningful security must be either on
>>      the loopback interface or reachable via a securely keyed IPsec
>>      tunnel or similar.
>
> I'm curious how necessary this really is in the case of "many" servers
> all talking to a local cache on the same switch.  Do I really have to set
> up IPsec tunnels for DANE-friendly DNS resolution on those machines

With UDP queries the attacker need not be on the same network, they just
need to forge UDP packets with a source address of the other server.
And you're exposed to anything else with access to the switch.  In any
case, you don't need to query a remote cache when a local one works
just as well or better.

> Setting up a cache on each machine would be simpler, but then you lose
> the benefit of merging cached results from multiple requesting systems

No, you don't.  Each local cache can forward to the same designated
cache you'd otherwise use directly.  But, because the local caches
would have *validation* enabled, this is completely safe.

> - you end up either forwarding to another local cache anyway, o
> multiplying your external DNS lookup traffic by the number of servers
> in the cluster.

This is not the case.  With validation in the local cache, it does not
matter what path DNSSEC-authenticated responses take to get to that
cache.

For full security with a local loopback cache, it may be necessary to
configure the system firewall to drop forged packets with 127.0.0.0/8
or ::1/128 source addresses arriving from non-loopback interfaces.
IIRC, not all operating systems will do this automatically.

--
        Viktor.