Re: postfix-users@postfix.org: difference between verify and secure
On 05.03.2012 19:39, Wietse Venema wrote: 366AE26E2B: to=t...@test1.prv, relay=s2.mydomain.de[192.168.1.1]:25, ..., dsn=4.7.5, status=deferred (Server certificate not verified) == So my understanding of the difference between verify and secure seems to be wrong. Could someone please explain this? Both verify and secure fail when the certificate signature can't be verified. Sorry, I'm still lost: /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) == And now: /etc/postfix/tls_policy: [s2.mydomain.de] verify match=s1.mydomain.de (nothing changed on the server side) == 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) == So: it looks to me like I got a server certificate which can be verified. 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). Instead, verify and secure are behaving in the same way: they only work when the match clause is configured. Regards, Robert
Re: postfix-users@postfix.org: difference between verify and secure
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.
Re: postfix-users@postfix.org: difference between verify and secure
On 06.03.2012 16:57, Viktor Dukhovni wrote: 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. Ouch. I may have deserved that. :-) After reading a bit more about smtp_tls_verify_cert_match and smtp_tls_secure_cert_match let's see if I understand better now: Default strategy for verify: ask DNS about MX, then check if the servers CN matches. Check if the trust chain is valid. Default strategy for secure: accept any CN presented by the server if that is the domain or a subdomain of the recipient address or the canonized hostname from the transport table. Do not add MX names looked up in DNS to the list of feasible CNs. Check if the trust chain is valid. Both can be overridden in tls_policy with the match attribute. Real world example: two organizations agree upon mandatory TLS. A list of domains requiring TLS and a list of MX hosts are transmitted. Each side configures: /etc/postfix/tls_policy: first-otherdomain XXX match=mx1:mx2 .first-otherdomain XXX match=mx1:mx2 second-otherdomain XXX match=mx1:mx2 .second-otherdomain XXX match=mx1:mx2 XXX may be verify or secure, it is overridden by match anyway. Regards, Robert
Re: postfix-users@postfix.org: difference between verify and secure
On Tue, Mar 06, 2012 at 06:19:59PM +0100, Robert Dahlem wrote: Default strategy for verify: ask DNS about MX, then check if the servers CN matches. Check if the trust chain is valid. Yes, though there is no promise of whether the name or the trust chain is checked first. Both need to be acceptable. Default strategy for secure: accept any CN presented by the server if that is the domain or a subdomain of the recipient address or the canonized hostname from the transport table. Do not add MX names looked up in DNS to the list of feasible CNs. Check if the trust chain is valid. If the transport table specifies a nexthop, then, if I recall correctly, it is used verbatim, I don't believe it is canonicalized (nor canonized by the Catholic Church). As before the order of the checks is implementation specific. Both can be overridden in tls_policy with the match attribute. Once explicit match criteria are specified, the two levels become indistinguishable, they apply the match criteria to the peer certificate whose trust chain is verified in the same way at either level. -- Viktor.
Re: postfix-users@postfix.org: difference between verify and secure
Robert Dahlem: 366AE26E2B: to=t...@test1.prv, relay=s2.mydomain.de[192.168.1.1]:25, ..., dsn=4.7.5, status=deferred (Server certificate not verified) == So my understanding of the difference between verify and secure seems to be wrong. Could someone please explain this? Both verify and secure fail when the certificate signature can't be verified. Wietse
Re: postfix-users@postfix.org: difference between verify and secure
On Mon, Mar 05, 2012 at 07:26:18PM +0100, Robert Dahlem wrote: I'm on Postfix 2.5.6 and implementing TLS. I'm having difficulties to understand the difference between verify and secure. These are documented in TLS_README.html http://www.postfix.org/TLS_README.html#client_tls_verify The only difference between these levels is the default certificate match policy, the former is hostname (not MITM secure) and the latter is dot-nexthop, nexthop (MITM secure). /etc/postfix/main.cf disable_dns_lookups = yes Unwise in most contexts, what's wrong with MX lookups? smtp_tls_loglevel = 2 Too verbose. Try 1. smtp_use_tls = yes smtp_enforce_tls = no Obsolete, try smtp_tls_security_level = may. smtp_tls_CApath = /etc/ssl/certs smtp_tls_policy_maps = hash:/etc/postfix/tls_policy /etc/postfix/transport: test1.prv smtp:[s2.mydomain.de] /etc/postfix/tls_policy: [s2.mydomain.de]verify For destinations with a manually configured destination (no MX lookups) the verify and secure match strategies are identical. On the server side I've got an SSL key and a certificate for that key signed by Thawte. The CN is s1.mydomain.de. Note the difference between s1 (key and certificate) and s2 (in the client configuration). This has been configured deliberately to explore the difference between secure and verify. My expectation was that verify would work (certificate chain checks out) but secure would not (CN does not match next hop). Instead, verify doesn't work too: Correct, the hostname for this connection is s2.mydomain.de. Verify will match MX hosts (insecurely), but you're not using MX records, you have a static nexthop. -- Viktor.
