On 2012-04-15 at 21:13 +0100, Jeremy Harris wrote:
> Anyone recall what happened to Steve Haslam's TLS patch from
> ten years back? Introduced a tls_verify_hostname smtp transport option,
> among other things - which has come up on my radar.
>
> Ref: http://www.exim.org/lurker/message/20020911.100440.23a73e82.ca.html
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.
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.
Given a choice between presenting deceptive security or leaving things
as they are, with "this is susceptible to MitM and there's no good
solution yet", I prefer the latter; to change, we'd better have DNSSEC
support in Exim first.
$tls_peercn -- we have $tls_peerdn, is the difference merely that
$tls_peercn extracts the correct field from the string? I suspect that
we'd be better off with DN parse routines exposed as expansion
operators (or items), which would help with LDAP too.
TLS debugging: I'm all in favour of more detailed information in debug
logs.
-Phil
