Ever since Netscape Navigator 2.0, over 10 years ago, NSS has recognized
SSL server certificates that use "wildcards" in the certificate common
names (and more recently, also in certificate Subject Alternative Names.
A cert could have an SSL server name such as
*
*.com
*.xyz.com
*.stw.xyz.com
and a "star" (*) would recognize any number of characters of any type,
including dots. So, a certificate with the pattern
*.xyz.com
matched www.xyz.com and also match www.stw.xyz.com.
They also recognized certain other forms of "regular expressions",
so that a cert with a pattern like "(ftp|www|imap).xyz.com" would
match each of these strings:
ftp.xyz.com
www.xyz.com
imap.xyz.com
And these could be combined in various ways, e.g.
*.(xyz|pqr).com
This has all been documented for years at:
http://wp.netscape.com/eng/security/ssl_2.0_certificate.html#Site
In recent years, IETF RFC standards have arisen that prescribe the
wildcard patterns that are allowed for each application protocol (e.g.
there is a standard for http, one for LDAP, etc.). None of the new
standards permit any form of wildcarding except "*". Some permit
only one "star" per name (e.g. *.xyz.com, but not *.*.xyz.com), while
others explicitly allow it. NONE allow a star to match a dot, so that
in no case would "*.xyz.com" be allowed to match "www.stw.xyz.com".
Now, there is a request asking that NSS's code for matching the
application's desired host names to the names in the cert adopt the more
restricting IETF standards, and the NSS team wholeheartedly agrees.
It is proposed that we change NSS to accept only wildcards that meet
these rules:
- exactly one star (*) and no more.
- star matches any numbers of characters EXCEPT DOT.
- There can be no dots to the left of the star, and a dot must
immediately follow the star.
- There must be at least two dots after (to the right of) the star,
and each dot must be followed by one or more non-dot characters.
- There may be characters OTHER THAN DOTS to the left of the one star.
Acceptable wildcards in the proposal:
*.xyz.com
*.stw.xyz.com
pqr*.xyz.com
NOT acceptable:
*
*.com
*.*.xyz.com
www.*.com
www.*.xyz.com
*stw.xyz.com
This means that shops that have certs with DNS names like *.xyz.com
on servers whose domain names are like www.stw.xyz.com (note the
different number of dots) will find that those certs no longer work with
NSS clients, if this change is made.
So the NSS team wonders: are there products or deployments that use
NSS that would stop working if NSS (and by extension, Mozilla, FireFox,
ThunderBird, etc.) were to adopt the more restrictive standards that
disallow some of the old forms that it previously allowed?
Note that this is an issue principally for SSL clients, not servers.
That is, the proposed software change would not affect products that
are using NSS *SOLELY* as servers, but would affect products that use
NSS to act as clients, to visit other servers.
Also note that Microsoft Internet Explorer (MSIE) already disallows many
of the wildcard patterns that we propose to disallow in NSS.
So, this change will mostly affect "closed" shops that use only NSS
clients (e.g. Mozilla clients) and is not likely to affect shops using
MSIE clients on Windows, because those already do not work with most of
NSS's old Netscape forms of wildcards.
If the proposed change will cause you grief, please let the NSS team
know by posting a message to this news group or mailing list, or by
adding a comment in bugzilla bug 159483, or by sending email to me
(you must demangle my email address) SOON. (This week, please.)
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
