Mailing List Archive: exim: users

tls_verify_hostname

Index | Next | Previous | View Threaded

jgh at wizmail

Apr 15, 2012, 1:13 PM

Post #1 of 6 (273 views)
Permalink

tls_verify_hostname

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

--
Thanks,
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

exim-users at spodhuis

Apr 15, 2012, 11:52 PM

Post #2 of 6 (265 views)
Permalink

Re: tls_verify_hostname [In reply to]

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

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

jgh at wizmail

Apr 16, 2012, 1:51 PM

Post #3 of 6 (261 views)
Permalink

Re: tls_verify_hostname [In reply to]

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

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

jgh at wizmail

Apr 16, 2012, 2:24 PM

Post #4 of 6 (261 views)
Permalink

Re: tls_verify_hostname [In reply to]

On 2012-04-16 21:51, Jeremy Harris wrote:
> 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.

While I think of it, I'm also thinking of writing an authenticator which
(server-side only) accepts iff a TLS connection is present and the client
has presented a certificate valid for one of a given (as an authenticator
option) list of names.

Does this sound like a valid use-case for certificates?

--
Jeremy

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

pdp at exim

Apr 16, 2012, 6:12 PM

Post #5 of 6 (263 views)
Permalink

Re: tls_verify_hostname [In reply to]

On 2012-04-16 at 21:51 +0100, Jeremy Harris wrote:
> On 2012-04-16 07:52, Phil Pennock wrote:
> > 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.)?

Should be able to set it as a resolver client option and check bits in
the result, leaving it up to the administrator to install a verifying
resolver. That way we avoid implementing a lot of logic which breaks
with new algorithms, bug-fixes etc, and which is prone to security
implications. We just delegate. The admin can install "unbound" or
configure "bind" to verify, or whatever.

> > 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?

I didn't look but assumed that the actual parse logic was necessarily in
the original patch, to be able to get CN out.

> > 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?

I wasn't an Exim developer in 2002. I have no context, beyond what I
saw in the thread, which suggests that things simply got lost.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

pdp at exim

Apr 16, 2012, 6:16 PM

Post #6 of 6 (270 views)
Permalink

Re: tls_verify_hostname [In reply to]

On 2012-04-16 at 22:24 +0100, Jeremy Harris wrote:
> While I think of it, I'm also thinking of writing an authenticator which
> (server-side only) accepts iff a TLS connection is present and the client
> has presented a certificate valid for one of a given (as an authenticator
> option) list of names.
>
> Does this sound like a valid use-case for certificates?

I think this is normally done with EXTERNAL, so that the client still
requests AUTH within the SASL framework.

I'd have thought it could be accomplished with "plaintext", ignoring
what's sent by the client and just looking at $tls_* variables, but I
might be wrong.

-Phil

--
## List details at https://lists.exim.org/mailman/listinfo/exim-users
## Exim details at http://www.exim.org/
## Please use the Wiki with this list - http://wiki.exim.org/

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads