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
