Re: [exim-dev] [Bug 1479] hostname check missing when verify…

Top Page
Delete this message
Reply to this message
Author: Viktor Dukhovni
Date:  
To: exim-dev
Subject: Re: [exim-dev] [Bug 1479] hostname check missing when verifying X509 certificate
On Sun, May 18, 2014 at 04:09:39AM +0100, Phil Pennock wrote:

> There are rules for wildcard name matching in RFC 6125 section 6.4.3 which
> beyond your code add support for the `*` not being the only component of a
> label. Frankly, that's stupid and adds yet more complexity in an already
> overly twisted area, especially since there's no statement around labels with
> multiple wildcards in them (`f*b*r`) and handling that quickly leads into DoS
> opportunities.


There are not cases in which the wildcard is in the middle of the
label not cases with multiple wildcard characteres. RFC 6125
strongly recommends against wildcards other than "*" as the whole
label, and also discourages wildcards (not as strongly). For SMTP
existing MUA to MTA practice is to support only "*.example.com"
as a wildcard, with no partial label matching.

There is no definite precedent for name checks with MTA to MTA
SMTP, but I'm also working with the UTA (Using TLS in Applications)
IETF working group draft authors who are defining some conventions
for MTA to MTA namechecks in the absense of DANE (even though this
generally yields no security for lack of secure MX indirection)...

Turns out people are doing silly things, so they may as well be
insecure interoperably. So bottom line:

    - "*.example.com" should match "mx.example.com".
    - "m*.example.com" should not match "mx.example.com"


> So I'm inclined to have the wildcard support only handle where a complete label
> is replaced by `*`, exactly as you have it, but we probably need to document
> this as "how Exim handles wildcards in certificates".


Fortunately Exim will soon have a couple of RFCs to lean on.

> Viktor, any strong feelings on wildcards other than whole-label?


Whole label only. And only because such wildcard certs continue
to be popular, and we don't need to needlessly surprise their
expectation that these should work.

Both drafts are new ground, and we could define MTA to MTA as
supporting no wildcards at all, but while this is a more "pure"
approach, we'd annoy people more than help them? If you feel
otherwise, speak up now!

-- 
    Viktor.