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.
