On 2012-04-16 07:52, Phil Pennock wrote:
> tls_verify_hostname seems to be accomplished via
> tls_verify_certificates, the documentation for which was updated a
> version or two back to be clearer about what's covered. That's
> OpenSSL-only, though, and the semantics for remote SMTP hostname
> verification are not well-defined.
In particular, I don't see in the docs a discussion of checking "the remote"
against the cert CN vs. the cert "X509v3 Subject Alternative Name" set.
I *think* it only does the former; part of Steve's patch was dealing with the
latter as an addition.
> Do you verify the email domain, which is the only trusted information?
> One server can handle many domains. Or do you verify the hostname you
> talk to, derived from the email domain over untrusted DNS? Not without
> DNSSEC, unless you want the verification to be a charade: the point
> being to tie a server-presented identity to something *verifiably*
> linked to an identifier which was trusted/supplied by a human.
Agreed this is an issue. I'd like a string-expansion for testing a peer's cert
against a specified name (using any of the CN + SAN-set, as it happens).
Then where the name comes from is a separable policy item.
> we'd better have DNSSEC
> support in Exim
Also a good notion. Wishlist item, or should it be handled by some
other software component on the system (nscd, etc.)?
> $tls_peercn -- we have $tls_peerdn, is the difference merely that
> $tls_peercn extracts the correct field from the string?
Yup
> I suspect that
> we'd be better off with DN parse routines exposed as expansion
> operators (or items), which would help with LDAP too.
That would work. It's not something I know about; does anyone
else work in that area who's prepared to take it on?
> TLS debugging: I'm all in favour of more detailed information in debug
> logs.
The implication is that it got lost and ought to
be accepted, as opposed to wasn't found useful?
--
Cheers,
Jeremy
