On Tue, Mar 06, 2012 at 11:52:54AM +0100, Robert Dahlem wrote: > /etc/postfix/transport: > test1.prv smtp:[s2.mydomain.de] > /etc/postfix/tls_policy: > [s2.mydomain.de] verify > ================================================================== > s2.mydomain.de[192.168.1.1]:25: Trusted subject_CN=s1.mydomain.de, > issuer_CN=Thawte DV SSL CA > Trusted TLS connection established to s2.mydomain.de[192.168.1.1]:25: > TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA > 6F68526E2E: to=<te...@test1.prv>, relay=s2.mydomain.de[170.1.1.1]:25, > ..., dsn=4.7.5, status=deferred (Server certificate not verified) > ==================================================================
The trust chain is valid but the name does not match, so the verification fails. > /etc/postfix/tls_policy: > [s2.mydomain.de] verify match=s1.mydomain.de > ================================================================== > s2.mydomain.de[192.168.1.1]:25: Matched subject_CN=s1.mydomain.de, > issuer_CN=Thawte DV SSL CA > Verified TLS connection established to s2.mydomain.de[192.168.1.1]:25: > TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA > 6F68526E2E: to=<te...@test1.prv>, relay=s2.mydomain.de[170.1.1.1]:25, > ..., dsn=2.0.0, status=sent (250 2.0.0 Ok: queued as 5CF654330) > ================================================================== The trust chain is still valid, but now the name matches so verification succeeds. > So: it looks to me like I got a server certificate which can be > verified. No, it is a certificate whose trust chain is valid and anchored at a trusted root, but this is meaningless, anyone can get a certificate with a valid trust chain, just verifying the trust chain is silly. > It's just that its CN does not match the server name, but that > should be ok when using "verify" (and not when using "secure"). Considering that Postfix documentation does not say this, and clearly states the opposite, you're just overloading your wishful interpretation of these words with total disregard for the documentation. > Instead, "verify" and "secure" are behaving in the same way: they only > work when the "match" clause is configured. Exactly as documented. They differ only in the matching strategy. Yes, I have in the past observed, though perhaps in offlist conversation, that there should perhaps not have been separate "verify" and "secure" levels, rather just "verify" could have been enough with a default matching strategy that is the same as the current "secure", and anyone who wanted (less secure MX) "hostname" matching could just tweak the matching rules. So "secure" is perhaps a minor design error, but on the other hand it serves to emphasize that "hostname" matching is rather different from "nexthop" matching, and the former is not MITM resistant, which after all is the entire purpose of all the X.509 baggage. If you are bothering with certs, you may as well get your money's worth. Otherwise, just do anonymous TLS, or install self-signed certs, you get passive-eavesdropping resistance from that with much less fuss and no tax paid to the usual cabal of public CAs. -- Viktor.