Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 21 May 2015 14:46:50 -0400 (EDT)
Subject: Re: CVE request: ssl.match_hostname(): sub string wildcard should not match IDNA prefix

Hash: SHA1


Our perspective on issue17997 is that the "multiple wildcards" issue
can have a CVE ID but the "IDNA prefix" issue probably cannot.

RFC 2818 says "Names may contain the wildcard character * which is
considered to match any single domain name component or component
fragment. E.g., * matches but not
f*.com matches but not" It isn't completely clear
whether multiple instances of '*' such as *.*.com were considered
valid. Also, says "For security
reasons matching rules like *.*.com should be not supported." Use
CVE-2013-7440 for this issue.

The IDNA report seems to be about wanting to change the specification
from RFC 2818 to RFC 6125. mentions
that the old behavior 'can result into false positive matches for a
rule like "x*"' but, in practice, it seems unlikely that
anyone would have a need for rules beginning with x* or xn* or xn-*
(these are essentially the only three cases). It seems more likely
that someone would have created a rule for xn--* because
they specifically wanted to match all IDNA names but did not want to
match (which might be separately administered). In
other words, the IDNA aspect of 10d0edadbcdd doesn't seem to be a
vulnerability fix; it seems to be a policy change that, relative to
existing deployments, sometimes strengthens security and sometimes
weakens security. The policy change (i.e., adopting a more recent RFC)
does, of course, seem appropriate for new deployments. Similarly, says "I won't apply this for 3.2
since at this point a behavior change might do more harm than good."
In any case, because RFC 2818 was intended when the code was written,
we feel that 'false positive matches for a rule like "x*"'
is not a vulnerability and should not have a CVE.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1.4.14 (SunOS)


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.