Re: [mailop] Outgoing TLS

[Vick Khera]

On Thu, May 12, 2016 at 4:52 PM, Jeffry Dwight 
wrote:

> I can't figure out how to tell the
> difference between a "real" untrusted root and a cert issued by some
> admin's
> personal CA.
>

Because there is none.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outgoing TLS

[ml+mailop]

On Thu, May 12, 2016, Jeffry Dwight wrote:

> Is it even worth checking the cert chain at all?

Sure, if you want to enable further requirements.
For example, I use something like this:

smtpc_rcpt_conf:@$IMPORTANTDOMAIN   tls_requirements { flags={verified}; 
cipher_bits_min=256; hostnames = { .$IMPORTANTDOMAIN }; }

for some domains; so without checking the cert the "verified"
requirement would never be fulfilled.

Depending on your MTA, you can specify other requirements based on
your needs/out of band agreements, e.g., cert-issuer or cert-fingerprint.


___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outgoing TLS

[Vladimir Dubrovin via mailop]

In the case of STARTTLS failure SMTP falls back to cleartext (unless
DANE or SMTP STS is used to indicate STARTTLS is required). Encryption
with invalid certificate in this case is better than no encryption.

Jeffry Dwight пишет:
> Thanks for all the replies.
>
> Is it even worth checking the cert chain at all?
>
> Right now, I've taken your advice and am ignoring the following errors:
>
> Untrusted CA
> Untrusted Root
> Untrusted Test Root
> CN Name Mismatch
> Cert Expired
>
> This leave only revocation, invalid cert use, and miscellaneous unlikely 
> errors
> to encounter after a successful handshake (not much).
>
> Probably revocation is important, but log-diving shows a lot of self-signed 
> and
> expired certs used by legit MTA recipients. I can't figure out how to tell the
> difference between a "real" untrusted root and a cert issued by some admin's
> personal CA.
>
> Jeffry
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


-- 
Vladimir Dubrovin
@Mail.Ru
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outgoing TLS

[Jeffry Dwight]

Thanks for all the replies.

Is it even worth checking the cert chain at all?

Right now, I've taken your advice and am ignoring the following errors:

Untrusted CA
Untrusted Root
Untrusted Test Root
CN Name Mismatch
Cert Expired

This leave only revocation, invalid cert use, and miscellaneous unlikely errors
to encounter after a successful handshake (not much).

Probably revocation is important, but log-diving shows a lot of self-signed and
expired certs used by legit MTA recipients. I can't figure out how to tell the
difference between a "real" untrusted root and a cert issued by some admin's
personal CA.

Jeffry



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outgoing TLS

[Vladimir Dubrovin via mailop]

STARTTLS itself doesn't protect against active MitM attack, because
attacker can strip STARTTLS from server's banner and according to
standard, client should fall back to cleartext in this case. To protect
against passive MitM, there is no need to validate certificate because
self-signed certificate provides same level of protection. Switch off
certificate validation, because it doesn't provide any additional
security and you loose passive MitM protection in the case of self
signed certificates.

There are 2 protocols to provide strict SMTP security and to protect
against active MitM attacks:

1. DANE (RFC 6698) - is only useful with DNSSEC, so it is actually
nearly useless
2. SMTP STS https://tools.ietf.org/html/draft-brotman-mta-sts-00 - is a
draft and is not yet ready for implementation AFAIK.


Jeffry Dwight пишет:
> We've recently modified our main outgoing MTA to perform STARTTLS if 
> advertised
> by the server. This is primarily to satisfy our Gmail customers, because GMail
> now sports a nasty red lock symbol beside any incoming mail that was not 
> encrypted.
>
> We've discovered that many servers don't have a CN that remotely resemble 
> either
> the domain name we're sending to or the CNAME for the MX record of the server
> we're connecting to.
>
> For just one example, domains hosted by dreamhost come up with an MX of
> mx1.balanced.homie.mail.dreamhost.com, which offers a cert with
> CN=*.mail.dreamhost.com. According to RFC2818 and others, the wildcard should
> not match, because the wildcard is good for only one node. Testing with
> http://www.checktls.com/perl/TestReceiver.pl shows that our logic is correct 
> --
> the CN does not match.
>
> In other cases, the MX record is some completely different network, with no
> relationship to the domain or the rDNS for the answering server. In those 
> cases,
> the cert's CN has no hope of matching.
>
> I briefly considered using the server's self-identification on the first 220
> greeting, but some log-diving shows that it often bears no resemblance to
> anything at all.
>
> So, what do you all do? Right now, I'm verifying the cert and its chain, but
> ignoring CN mismatches. That seems to be fine for ensuring encryption, but
> rather defeats the purpose of knowing we're connecting to the proper server.
>
> Second question: How do you handle self-signed certs? Do you just ignore cases
> where the root isn't a trusted root?
>
> Jeffry
>
>
>
> ___
> mailop mailing list
> mailop@mailop.org
> https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop


-- 
Vladimir Dubrovin
@Mail.Ru
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outgoing TLS

[ml+mailop]

On Thu, May 12, 2016, Jeffry Dwight wrote:

> So, what do you all do? Right now, I'm verifying the cert and its chain, but
> ignoring CN mismatches. That seems to be fine for ensuring encryption, but

Only log "problems" (why should I trust some CA?) unless explicitly
configured to check (for a few "important"/"known" hosts).

> rather defeats the purpose of knowing we're connecting to the proper server.

DANE.

> Second question: How do you handle self-signed certs? Do you just ignore cases
> where the root isn't a trusted root?

Same as above.

___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

Re: [mailop] Outgoing TLS

[Vick Khera]

On Thu, May 12, 2016 at 1:24 PM, Jeffry Dwight 
wrote:

> So, what do you all do? Right now, I'm verifying the cert and its chain,
> but
> ignoring CN mismatches. That seems to be fine for ensuring encryption, but
> rather defeats the purpose of knowing we're connecting to the proper
> server.
>
> Second question: How do you handle self-signed certs? Do you just ignore
> cases
> where the root isn't a trusted root?
>

Don't bother verifying the certificate host names. You've identified many
issues already.

Just use it for the opportunistic encryption unless you're dealing with a
lot of high-risk mail like banks. From what I gather, they only do
certificate checks on specified destinations (ie, other banks they know to
have certificates set up correctly to match) and in those cases they fail
if the cert does not match. For general consumer mail there is no way to do
this.
___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop

[mailop] Outgoing TLS

[Jeffry Dwight]

We've recently modified our main outgoing MTA to perform STARTTLS if advertised
by the server. This is primarily to satisfy our Gmail customers, because GMail
now sports a nasty red lock symbol beside any incoming mail that was not 
encrypted.

We've discovered that many servers don't have a CN that remotely resemble either
the domain name we're sending to or the CNAME for the MX record of the server
we're connecting to.

For just one example, domains hosted by dreamhost come up with an MX of
mx1.balanced.homie.mail.dreamhost.com, which offers a cert with
CN=*.mail.dreamhost.com. According to RFC2818 and others, the wildcard should
not match, because the wildcard is good for only one node. Testing with
http://www.checktls.com/perl/TestReceiver.pl shows that our logic is correct --
the CN does not match.

In other cases, the MX record is some completely different network, with no
relationship to the domain or the rDNS for the answering server. In those cases,
the cert's CN has no hope of matching.

I briefly considered using the server's self-identification on the first 220
greeting, but some log-diving shows that it often bears no resemblance to
anything at all.

So, what do you all do? Right now, I'm verifying the cert and its chain, but
ignoring CN mismatches. That seems to be fine for ensuring encryption, but
rather defeats the purpose of knowing we're connecting to the proper server.

Second question: How do you handle self-signed certs? Do you just ignore cases
where the root isn't a trusted root?

Jeffry



___
mailop mailing list
mailop@mailop.org
https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop