On Sun, Mar 30, 2014 at 11:20:51AM +0200, Steffen Ullrich via RT wrote:
> - wrong: according to RFC 6125 section 7.2 only the leftmost label should be
> checked for wildcards, but you support also something like
> www.*.example.com (there is even a test for it).
Well, "wrong" is perhaps too strong a claim, it is however not
RFC6125 conformant, and applications should be able to (perhaps by
default) get RFC6125 conformant behaviour. Therefore, there should
probably be a flag to disable (if on by default) or enable (if not)
the RFC6125 restriction on "*" lying in the left-most label of the
wildcard pattern.
Separately, there should be a flag to relax the RFC6125 restriction
that disallows that left-most wildcard to match more than one
leading label, say with X509_CHECK_FLAG_MULTI_LABEL_WILDCARD:
foo.bar.example.com ~ *.example.com
Also the current code insists that "*" match at least one character,
but RFC6125 (based on all too brief text in RFC2818) is silent
on the question of whether:
foo.example.com ~ foo*.example.com
Lacking normative text, what is current practice? How do browsers
handle this?
> - wrong: you match wildcards within IDNA labels (there is also a test for
> it), which is not allowed. While according to
> http://rt.openssl.org/Ticket/Display.html?id=2909#txn-35213
> the IDNA handling could not be found in any standard, RFC6125 section 7.2
> is actually quite clear about it.
Indeed this should be fixed. If the pattern label containing the wildcard
matches (case insensitive) one of:
/^xn--.*\*/
/^\*.*xn--/
then the wildcard is definitely taboo. There are subtler cases:
/^x*--/
here the pattern is not obviously an A-label, but matches some
A-labels. The solution is I think to enhance the pattern validity
checks to more fully check the required LDH structure:
# No trailing '.'
# No consecutive '.' characters
# No consecutive '-' characters, except when part of "xn--" at the
start of a pattern label
# No '-' characters at the beginning or end of a label
> - insufficient: you have a flag X509_CHECK_FLAG_NO_WILDCARDS to disable
> wildcard checking and a flag X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT to check
> the CN even if subject alternative names are present. That's not
> sufficient to describe the hostname checking which needs to be done for
> the various protocols:
Indeed there is as yet no flag that enables/disables the use of
"foo*" and "*foo" in which "*" matches only part of a label. Such
a flag should be added.
> - in theory X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT should be false too, but
> its behavior does not match whats required from the RFC: the current
> implementation does check CN if there are no subject alternative
> names, but it should check CN if the are no DNS subject alternative
> names. So if SAN sections contains only IP it should check CN too.
Indeed the TLS support code contributed by Lutz Jaenicke for Postfix
over a decade ago suppresses CN checks only when no DNS altnames
are found, rather than when no altnames are found at all. So this
is easy to fix without interface changes, just change the implementation
to only skip the Subject CN when DNS altnames are present.
> - ldap only allows in subject alternative names something like
> *.foo.com, but not x*.foo.com like it is allowed with http and done
> with the current wildcards check
> - it also should check the CN always, but does not allow wildcards in
> the CN
This LDAP behaviour is bizarre, and reflects the absurd mess of
PKIX name checks prior to RFC6125, which RFC6125 is unfortunately
forced to accept and document. It makes little sense to allow
wildcards in altnames but disallow them in the subject CN. So I
don't think that a separate flag for wildcard support in CN vs.
DNS altname is warranted.
> - smtp, imap, pop3, nntp ... (RFC2595, RC4642, RFC5539...)
> - these protocols don't allow x*.foo.com too, e.g only *.foo.com
There is no specification for name checks in MTA to MTA SMTP, name
checks, if any, are "local policy". There is a partial specification
for submission. There is a new draft under development in the
Using TLS for Applications (UTA) working group to specify name
checks for MTA to MTA SMTP and the situation is rather different
when DANE TLSA authentication is used (in this draft "*" again
matches only the complete label).
With Postfix, the administrator can specify *multiple* valid
reference identities, which can match the server certificate. And
indeed this will be required by DANE TLSA for SMTP and with SRV
records.
The Postfix "local policy" is rather flexible. The "*" wildcard
must be a complete label in the server certificate, but by default
can match more than one label in the reference identity.
The administrator can specify multiple reference identities. When
a reference identity takes the form ".example.com" (starts with a
leading "."), it matches server names that are in any sub domain of
example.com:
foo.example.com ~ .example.com
*.example.com ~ .example.com
foo*.example.com ~ .example.com
> - probably useful: while no RFC currently forbids something like *.com you
> have a check to disallow wildcards in the two rightmost suffixes. I think
> it makes sense to have that, although it is not sufficient (e.g. *.co.uk
> should also not be allowed). But doing this 100% correct will be tricky,
> because there is currently no definition of correct behavior in this area:
> While chrome disallows *.co.uk firefox allows it.
Such a policy would be too complex for OpenSSL, and will be even
more complex to get right once all the new TLDs ICANN is blessing
us with come online.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
