incorrect wildcard certificate handling

[Eero]

Binary package hint: mozilla-firefox

firefox 3.0.10+nobinonly-0ubuntu0.9.04.1

http://www.ietf.org/rfc/rfc2818.txt states the following:
   Matching is performed using the matching rules specified by
   [RFC2459]. If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Firefox accepts *.foo.com certificate for a domain baz.bar.foo.com even though it shouldn't do that. Tested with new DigiCert wildcard certificate and it seems like IE handles this situation correctly.

[Wan-Teh Chang (wtc-google)]

Step 1 seems useful to me. I found that IE doesn't
do step 1 and it is inconvenient to have to type
fully qualified domain names in https URLs in an
intranet.

Step 4 seems overly relaxed. I can't find a test
case for step 4, so I don't know if IE supports it.

In any case, I am afraid that we need to be
compatible with these extensions.

[Nelson-bolyard (nelson-bolyard)]

*** Bug 194285 has been marked as a duplicate of this bug. ***

[Nelson-bolyard (nelson-bolyard)]

Note that RFC 2818 says:

> Status of this Memo
>
> This memo provides information for the Internet community. It does
> not specify an Internet standard of any kind.

NSS attempts to ensure that the set of certs that it matches to the host
name in a URI is at least as great as the set specified in RFC 2818, but
strict adherence to RFC 2818 is not an absolute goal, given that 2818 is
not an Internet standard of any kind.

There are a number of ways in which NSS matches certificates more broadly
than RFC 2818 suggests. Bug 194285 notes another way (in addition to
those already mentioned above). NSS treats host names in certs as unix
regular expressions, where * matches all strings. RFC 2818 says:

> [...] Names may contain the wildcard
> character * which is considered to match any single domain name
> component or component fragment. E.g., *.a.com matches foo.a.com but
> not bar.foo.a.com. [...]

[Nelson-bolyard (nelson-bolyard)]

P3.

[Jo-hermans (jo-hermans)]

is this still being worked at ?

[Nelson-bolyard (nelson-bolyard)]

Perhaps this bug can be RESOLVED as WORKSFORME.
Since it was filed, several changes were made to the comparison of
host names in URLs and host names in certs. IIRC, steps 1 and 4 were
determined to be vulnerabilities, and were eliminated.
Bug 103752 was implemented and SANs are now supported per RFC 2818.

There are some issues that remain that get occasional grumbles, and
are probably the subjects of other bugs. They are:

a) NSS ignores a cert's subject CommonNames if/when there are DNS names
in the subject Alternate Names extension. This is due to a very literal
reading of RFC 2818. IE will match names from either place, even when
DNS names are present in the SAN.

b) (as reported in comment 0), NSS matches a "*" to any characters,
whereas RFC 2818 suggests it should not match a ".". We do this for
backwards compatibility with NSS's original spec on pattern matching.

c) NSS accepts at most one Subject Common Name, the most specific one.
This is specified in RFC 2818, but some CAs think that multiple CNs
should be allowed.

Of these issues, Perhaps I could be persuaded to change the first two.

[Ted-convey (ted-convey)]

(In reply to comment #6)
[...]
> b) (as reported in comment 0), NSS matches a "*" to any characters,
> whereas RFC 2818 suggests it should not match a ".". We do this for
> backwards compatibility with NSS's original spec on pattern matching.
[...]
> Of these issues, Perhaps I could be persuaded to change the first two.

How could I help to persuade you to fix b)? Now please don't say "Threaten to send me explosive devices"...

[Nelson-bolyard (nelson-bolyard)]

Explosives? Heavens, no!
Send pictures of dead American presidents on green paper! :)

[Mozbugzilla (mozbugzilla)]

(In reply to comment #6)
> b) (as reported in comment 0), NSS matches a "*" to any characters,
> whereas RFC 2818 suggests it should not match a ".". We do this for
> backwards compatibility with NSS's original spec on pattern matching.

Count me in as another (strong) proponent of changing this - for two reasons:

1) most other implementations I've encountered so far (MSIE/Schannel,
   Opera, Safari/libsecurity_apple_x509_tp, Konqueror/KDE, GnuTLS)
   apply a more restrictive matching than NSS (although they differ in
   their specific behavior, but at least they do not allow using certs
   with subjects like CN=*)

2) there are at least two other RFCs (besides 2818) which stipulate the more
   restrictive form of wildcard matching, and these are actually on the
   "Standards Track":

   a) RFC 2595 ("Using TLS with IMAP, POP3 and ACAP", June 1999) says
      in 2.4., "Server Identity Check":

      - A "*" wildcard character MAY be used as the left-most name
        component in the certificate. For example, *.example.com would
        match a.example.com, foo.example.com, etc. but would not match
        example.com.

   b) RFC 4513 ("Lightweight Directory Access Protocol (LDAP):
      Authentication Methods and Security Mechanisms", June 2006) states
      under 3.1.3.1., "Comparison of DNS Names":

      The '*' (ASCII 42) wildcard character is allowed in subjectAltName
      values of type dNSName, and then only as the left-most (least
      significant) DNS label in that value. This wildcard matches any
      left-most DNS label in the server name. That is, the subject
      *.example.com matches the server names a.example.com and
      b.example.com, but does not match example.com or a.b.example.com.

[Nelson-bolyard (nelson-bolyard)]

*** Bug 389295 has been marked as a duplicate of this bug. ***

[Nelson-bolyard (nelson-bolyard)]

Note that the passages quoted above from RFC 2595 and RFC 4513 specify
different restrictions on wildcard matching. NSS already does what the
quoted text from RFC 2595 says.

NSS has had this behavior since Netscape Navigator 3, if not before then.

Once upon a time, the Netscape & Mozilla browsers were well entrenched
in corporate intranets. Intranet sysadmins LIKE the present wildcard
behavior, which means they can get by with fewer certs. So far, we've
resisted breaking compatibility for them. Changing it will mean that
sysadmins will need to get new certs for every subdomain.

If you really hate it, identify a vulnerability that is bad enough to
warrant changing it, but not bad enough to warrant discontinuing the
use of wildcards altogether (as many have proposed).

[Wan-Teh Chang (wtc-google)]

The wildcard matching specified in RFC 4513 seems reasonable
to me. But we need to consider the risk of breaking backward
compatibility.

[Mozbugzilla (mozbugzilla)]

(In reply to comment #11)
> Note that the passages quoted above from RFC 2595 and RFC 4513 specify
> different restrictions on wildcard matching.

They don't say exactly the same thing, yes, but other than that, I don't think they contradict each other - or do they?

> NSS already does what the quoted text from RFC 2595 says.

Not in my understanding of that sentence, actually - if it says 'A "*" wildcard character MAY be used as the left-most name component in the certificate', then that does not allow for things like

   www.*
   *.*.example.org
   www.*.example.org
   *.*

on the other hand, I believe... all these have a "*" which is *not* in the left-most component. However, NSS will happily accept these, which leads to issues such as the one reported in bug 285361 (which has been resolved with WONTFIX, I know - but I disagree with that assessment to a certain degree... even if that single CN=* certificate came from a good guy, originally, the security of your browser might depend on the security of the host configured with this certificate, from then on - if an attacker manages to steal this particular private key, he can play MITM for you for any site).

Also, when considering how host name matching is currently done in NSS, I don't think it makes any real sense to support patterns like these in a host name:

> * o * matches anything
> * o ? matches one character
> * o \ will escape a special character
> * o $ matches the end of the string
> * o [abc] matches one occurence of a, b, or c. The only character that needs
> * to be escaped in this is ], all others are not special.
> * o [a-z] matches any character between a and z
> * o [^az] matches any character except a or z
> * o ~ followed by another shell expression will remove any pattern
> * matching the shell expression from the match list
> * o (foo|bar) will match either the substring foo, or the substring bar.
> * These can be shell expressions as well.

(http://lxr.mozilla.org/mozilla/source/security/nss/lib/util/portreg.h#44)

While this allows you playing funny tricks with certs and host names like

   *~.biz$ (any host not in the .biz TLD)
   (|www.)example.org (www.example.org and example.org)
   [^w]* (any host name which doesn't begin with "w")

this might be cool for doing experiments (yes, they do work in Firefox e.g.!), but it's probably not really intended behavior...

Let me encourage you again to drop that kind of pattern matching for host names from NSS, and implement wildcard matching in the spirit of RFCs 2595, 2818 and 4513.

[Bugzilla-mozilla-org-mail (bugzilla-mozilla-org-mail)]

I fully agree to the former poster:

(1) Matching the dot with "*" is a violation of RFC 2818 (HTTPS), and other RFCs regarding TLS-protocols (IMAPS/LDAPS/...) are not less restrictive.

(2) Matching anything with top-level-wildcard "CN=*" is bad practice.

(3) Not showing "subjectAltName:dNSName=*" in the standard vertificate view but matching it with any domain name is VERY BAD PRACTICE (although replacing "CN", "subjectAltName" is hidden in the "details", see bug #238142).

This is a security issue and should be fixed.

[Wan-Teh Chang (wtc-google)]

If anyone would like to write a patch, the starting point is the
CERT_VerifyCertName function:
http://lxr.mozilla.org/security/ident?i=CERT_VerifyCertName

The actual matching is done in the cert_TestHostName function:
http://lxr.mozilla.org/security/ident?i=cert_TestHostName

which delegates pattern matching to the PORT_RegExpCaseSearch
function:
http://lxr.mozilla.org/security/ident?i=PORT_RegExpCaseSearch

Note on the backward compatibility of exported NSS functions:

Since PORT_RegExpCaseSearch will be exported for the first time
in the upcoming NSS 3.12 release, if a patch for this bug is accepted
before NSS 3.12 is released, we can change PORT_RegExpCaseSearch
directly. Otherwise, we will need to add a new function that
does the RFC-compliant pattern matching.

Alternatively, we can move nss/lib/util/portreg.{h,c} to
nss/lib/certdb so that the PORT_RegExpCaseSearch doesn't need
to be exported from the new libnssutil3.so shared library in
NSS 3.12.

[Mozbugzilla (mozbugzilla)]

Created an attachment (id=288137)
Minimal patch (addresses item b in comment 6)

(In reply to comment #15)
> If anyone would like to write a patch,

Here's a patch which I would call "minimal" in the sense that it tries to maintain backward compatibility as far as possible (i.e. it still supports all those patterns mentioned in comment 13).

Specifically, the patch changes these two things:

- in cert_TestHostName(), it makes sure that the '*' character is only considered for wildcard matching if it occurs in the leftmost DNS name component (otherwise, it's just compared as a literal character)

- modifies _shexp_match() to not match the '.' character when using doing wildcard matching with '*'

I will also attach a short test program I used to verify the results of the new code. It's a bit more liberal than what RFCs 2595 and 4513 suggest ("THE left-most name component" implies that things like "www*.example.com", "w*w.example.com", "w*w**w.example.com" aren't valid wildcard expressions), but I don't think it hurts if we allow them for the time being.

> Alternatively, we can move nss/lib/util/portreg.{h,c} to
> nss/lib/certdb so that the PORT_RegExpCaseSearch doesn't need
> to be exported from the new libnssutil3.so shared library in
> NSS 3.12.

I would warmly recommend that - and also change the names of the three PORT_RegExpXXX() wrapper functions at that time... they are quite big misnomers, since the code doesn't do any regex matching at all (just zsh-like wildcard matching - other copies of this code living in the Mozilla tree use better names like "NS_WildCardMatch()"). If the code is left in lib/util, then at least the names should be changed - exporting PORT_RegExpCaseSearch as a public function from libnssutil3 seems like a bad idea to me.

In a further step, cert_TestHostName() could be actually modified to not rely on PORT_RegExpCaseSearch() any longer, in my opinion (or is there any need for supporting shell-style matching besides the '*' character?). Provided that there is a consensus in the NSS team on what exactly should be implemented, I would be willing to give it a try.

What are the chances of getting this into 3.12 (and Fx 3, therefore)? Whom can/should I ask for review?

[Mozbugzilla (mozbugzilla)]

Created an attachment (id=288138)
Test program (for illustration purposes only)

Test program producing the following results, *after* the patch from attachment 288137 is applied (arbitrary patterns/hostnames to test can be specified as cmdline arguments):

---------- snip ----------
*.example.com does not match hostname www
*.example.com does not match hostname example.com
*.example.com MATCHES hostname www.example.com
*.example.com MATCHES hostname foo.example.com
*.example.com MATCHES hostname foobar.example.com
*.example.com does not match hostname foo.bar.example.com

www*.example.com does not match hostname www
www*.example.com does not match hostname example.com
www*.example.com MATCHES hostname www.example.com
www*.example.com does not match hostname foo.example.com
www*.example.com does not match hostname foobar.example.com
www*.example.com does not match hostname foo.bar.example.com

f*.example.com does not match hostname www
f*.example.com does not match hostname example.com
f*.example.com does not match hostname www.example.com
f*.example.com MATCHES hostname foo.example.com
f*.example.com MATCHES hostname foobar.example.com
f*.example.com does not match hostname foo.bar.example.com

foo*bar.example.com does not match hostname www
foo*bar.example.com does not match hostname example.com
foo*bar.example.com does not match hostname www.example.com
foo*bar.example.com does not match hostname foo.example.com
foo*bar.example.com MATCHES hostname foobar.example.com
foo*bar.example.com does not match hostname foo.bar.example.com

* MATCHES hostname www
* does not match hostname example.com
* does not match hostname www.example.com
* does not match hostname foo.example.com
* does not match hostname foobar.example.com
* does not match hostname foo.bar.example.com

foo.*.example.com does not match hostname www
foo.*.example.com does not match hostname example.com
foo.*.example.com does not match hostname www.example.com
foo.*.example.com does not match hostname foo.example.com
foo.*.example.com does not match hostname foobar.example.com
foo.*.example.com does not match hostname foo.bar.example.com

*.*.example.com does not match hostname www
*.*.example.com does not match hostname example.com
*.*.example.com does not match hostname www.example.com
*.*.example.com does not match hostname foo.example.com
*.*.example.com does not match hostname foobar.example.com
*.*.example.com does not match hostname foo.bar.example.com
---------- snip ----------

[Wan-Teh Chang (wtc-google)]

(From update of attachment 288137)
>+ /* remaining string must not contain any dots */
>+ if (str[x] && PORT_Strchr(&str[x], '.'))
>+ return NOMATCH;
>+ else
>+ return MATCH;

Should we allow a single terminating dot? I seem
to recall DNS names can be terminated with a dot.

    /*
     * renaming string must not contain any dot
     * followed by another component
     */
    if (str[x]) {
        char *dot = PORT_Strchr(&str[x], '.');
        if (dot and dot[1])
            return NOMATH;
    }
    return MATCH;

[Reed Loden (reed)]

It wouldn't upset me at all if we just dropped backwards compatibility and only supported RFC 2818 like some other browsers do. ;)

In particular, I see sites misusing wildcard certs such as *.example.tld for all subdomains under example.tld (foo.bar.example.tld, etc.), which is a violation of RFC 2818, but this violation is currently allowed in Firefox (due to current NSS). :(

[Mozbug1 (mozbug1)]

(In reply to comment #17)
> Created an attachment (id=288138) [details]
> Test program (for illustration purposes only)
<snip>
> *.*.example.com does not match hostname foo.bar.example.com

 *.*.example.com does *should* match foo.bar.example.com. My company uses a *.* certificate and this would break our website in firefox.

[Mozbugzilla (mozbugzilla)]

(In reply to comment #18)
> Should we allow a single terminating dot?

I don't recommend doing so (or if we really do, then we should just strip off a trailing dot at the beginning of cert_TestHostName, and not modify _shexp_match further).

> I seem to recall DNS names can be terminated with a dot.

They're not permitted RFC-wise, actually... RFC 952 says:

   1. A "name" (Net, Host, Gateway, or Domain name) is a text string up
   to 24 characters drawn from the alphabet (A-Z), digits (0-9), minus
   sign (-), and period (.). Note that periods are only allowed when
   they serve to delimit components of "domain style names". (See
   RFC-921, "Domain Name System Implementation Schedule", for
   background). No blank or space characters are permitted as part of a
   name. No distinction is made between upper and lower case. The first
   character must be an alpha character. The last character must not be
   a minus sign or period.

[Note that RFC 1123 slightly changes one of these requirements:

      The syntax of a legal Internet host name was specified in RFC-952
      [DNS:4]. One aspect of host name syntax is hereby changed: the
      restriction on the first character is relaxed to allow either a
      letter or a digit. Host software MUST support this more liberal
      syntax.

 I'm not aware of any other updates to RFC 952 which would change this syntax.]

The "trailing dot issue" is actually the topic of bug 134402, and normalizing the hostname in PSM (maybe even in Necko?) seems like the better fix to me. (If really considered appropriate/necessary - IE7 e.g. also treats www.example.com and www.example.com. as different names, as does Opera.)

[Mozbugzilla (mozbugzilla)]

Created an attachment (id=288681)
Alternative patch for (more restrictive) wildcard matching

(In reply to [my own] comment #16)
> In a further step, cert_TestHostName() could be actually modified to not rely
> on PORT_RegExpCaseSearch() any longer, in my opinion (or is there any need for
> supporting shell-style matching besides the '*' character?).

Here's an alternative patch (for cert_TestHostName) which implements a more "radical" solution, by further limiting the cases where '*' is interpreted as a wildcard character. From the explanation in the source:

   /* for a cn pattern to be considered valid, the wildcard character...
      - may occur in the first component only, and must be its last character
      - may occur only once
      - may be preceded by additional characters
    */

Of course this is (still) in line with RFCs 2595, 2818 and 4513, and has the advantage of no longer depending on PORT_RegExpCaseSearch (so portreg.{h,c} could actually be dropped from NSS, since cert_TestHostName is its only caller).

Can somebody (Nelson?) advise on how I should proceed? Is this patch acceptable for review, or would it also need to cover the changes to lib/util? Thanks for any guidance.

[Mozbugzilla (mozbugzilla)]

As a small addendum: I'm aware of the current priority of this bug (P3), but given the fact that Firefox 3 will introduce considerable improvements when dealing with invalid certificates (bug 327181), wouldn't this be a good opportunity to tighten wildcard matching at the same time (making it RFC compliant)? Could we increase its priority therefore?

[Mozbug1 (mozbug1)]

While reading RFC 2595:

- A "*" wildcard character MAY be used as the left-most name
     component in the certificate. For example, *.example.com would
     match a.example.com, foo.example.com, etc. but would not match
     example.com.

And in RFC 2818:

 Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment.

So *.*.example.com should work according to 2818 but not 2595. But 2818 is "HTTP Over TLS" and 2595 is "Using TLS with IMAP, POP3 and ACAP", and since Firefox is a web browser and not an email client I think it should follow 2818. Furthermore the wording in 2595 seems to have been intended to ensure that wildcards were leftmost, and to disallow cases example.*. It seems to me just sloppy wording on the part of the author that disallowed *.*.example.com

(In reply to comment #20)
> (In reply to comment #17)
> > Created an attachment (id=288138) [details] [details]
> > Test program (for illustration purposes only)
> <snip>
> > *.*.example.com does not match hostname foo.bar.example.com
>
> *.*.example.com does *should* match foo.bar.example.com. My company uses a
> *.* certificate and this would break our website in firefox.
>

[Nelson-bolyard (nelson-bolyard)]

I concur with Kaspar's comment 21.

Here is some perspective that will guide decisions on which way to go.

1) NSS is used by many applications, not just FireFox, and not even just
Mozilla client products. So it must meet the needs of a general audience.

2) libSSL does not decide for itself whether a cert is valid to be used as
a server cert. Instead, it calls a callback function that is supplied by
the application (!). That callback function decides. The point here is
that the responsibility for deciding if a cert passes or fails rests upon
the application. The application provides the function that makes the
decision according to the application's criteria. If Mail and Web
applications have different criteria, they should provide different
callback functions.

3) NSS provides a function that an application can choose to use as that
callback function, IFF it meets that appliation's needs for this purpose.
It is SSL_AuthCertificate. It calls CERT_VerifyCertNow to verify that the
cert chain is valid, and it calls CERT_VerifyCertName to determine that
the cert is valid for the host name that the application has given to NSS.
It was written before either RFC 2818 or RFC 2595 were written.
It is not intended to work only with https or only with mail protocols,
but to be more generally useful. Its acceptance grammar is intended to
be the union of those of the various protocols for which it will be used.
It should declare that a cert is valid for a host name if any of the
protocols for which it may be used would declare it to be valid.

It appears to me that the rules for RFC 2818 allow a proper superset of
wildcard patterns that are allowed by RFC 2595.

Having said that, it does seem that wildcard patterns with stars in the
top two levels of domain (such as "*" and "*.com") are undesirable. So,
I would be willing to impose a new restriction, that wildcards must be
followed by at least two dots (that is, two domains) excluding a trailing
dot, which I do not propose to ignore (in concurrence with comment 21).

[Mozbugzilla (mozbugzilla)]

(In reply to comment #25)
> Having said that, it does seem that wildcard patterns with stars in the
> top two levels of domain (such as "*" and "*.com") are undesirable.

When modifying the "*" to no longer match a ".", CN=* could still make some sense for Intranet URLs (such as "https://webmail"). I'm not opposed to this drop this option as well, but others might complain vociferously if we do so.

> I would be willing to impose a new restriction, that wildcards must be
> followed by at least two dots (that is, two domains) excluding a trailing
> dot, which I do not propose to ignore (in concurrence with comment 21).

Would you want to support patterns like www.*.example.com? It's true that RFC 2818 doesn't disallow such patterns (since it doesn't require the wildcard character to occur in the left-most component only), but given a number of other recent TLS related RFCs and Internet drafts, my impression is that the current consensus is to allow the in the first component only:

- RFC 4642 (October 2006), TLS with NNTP
- RFC 4954 (July 2007), STARTTLS SMTP extension
- draft-ietf-nsis-ntlp-14 (July 2007), General Internet Signalling Transport
- draft-badra-tls-netconf-04 (Oct. 2007), NETCONF over TLS

All these basically use the wording from RFC 2595 ("MAY be used as the left-most name component in the certificate"), so if RFC 2818 - from May 2000 - would be written today, my guess is that we'd see the same wording there, too.

Only allowing the "*" in the first component is also in line with the behavior implemented by Microsoft's Schannel library since Windows 2000 SP1 (see http://support.microsoft.com/kb/258858 - note that some of the "accepted wildcard examples" are completely wrong; the text description is accurate, however).

Therefore I still suggest going for the solution outlined in comment 22 (possibly with dropping support for "dotless" names). It's both in line with the RFCs and with the behavior of a very widespread implementation of another vendor, so chances are pretty small that this will "break the Net"...

What solution does the NSS team favor? Thanks for additional comments/opinions.

[Nelson-bolyard (nelson-bolyard)]

As far as I am concerned, host names in certs must always be FQDNs.
I don't know of ANY CA that will issue certs with non-FQDN host names,
e.g. for "webmail". If no CA issues them, then any certs with such names
in them must be ones that require the user to explicitly trust them.
I have no problem with saying that users must use FF3's new ability to
permanently remember error overrides for certs with mismatched host names
if they want to associate certs with non-FQDN host names.

[Wan-Teh Chang (wtc-google)]

Bug 401317 has a cert for "www". Bug 401317 comment 3 named the
CAs that will issue certs with non-FQDN host names.

[Nelson-bolyard (nelson-bolyard)]

I concur with the reporter of bug 401317 that certs with simple host names
should not validate. What does IE do with them?

[Mozbugzilla (mozbugzilla)]

(In reply to comment #29)
> I concur with the reporter of bug 401317 that certs with simple host names
> should not validate. What does IE do with them?

They work under IE (that's probably why CAs are issuing them in the first place). CN=* doesn't work at all with IE, which would be an argument for dropping support for this in NSS as well. So we would have:

   /* for a cn pattern to be considered valid, the wildcard character...
      - may occur in an FQDN only
      - may occur in the first component only, and must be its last character
      - may occur only once
      - may be preceded by additional characters
    */

Does that sound like a reasonable solution to our problem?

(Re:
> I would be willing to impose a new restriction, that wildcards must be
> followed by at least two dots (that is, two domains) excluding a trailing
> dot, which I do not propose to ignore

That's basically a good idea, but it has the drawback that it isn't really a "universal" solution - there is a considerable number of TLDs where more that two dots would be required to make this restriction effective [see http://lxr.mozilla.org/mozilla/source/netwerk/dns/src/effective_tld_names.dat and bug 331510 [the nsEffectiveTLDService] for what Necko is doing about this - maybe PSM could make use of it?.)

[Nelson-bolyard (nelson-bolyard)]

Perhaps PSM could make use of Necko's TLD stuff, but NSS cannot, so I am
looking for what we can do in NSS.

[Mozbugzilla (mozbugzilla)]

Created an attachment (id=289348)
Alternative patch for wildcard matching, incorporating suggestion from comment 25

(In reply to comment #31)
> Perhaps PSM could make use of Necko's TLD stuff, but NSS cannot, so I am
> looking for what we can do in NSS.

A thorough solution probably needs something similar to the database from nsEffectiveTLDService, but I assume that this is not what you want to have in NSS. Thus, incorporating your previous suggestion

> impose a new restriction, that wildcards must be followed by at least two dots
> (that is, two domains) excluding a trailing dot

is probably better than nothing, and therefore I'm proposing this updated patch and am asking for review. (If that solution gets accepted, I could then prepare another patch which removes the PORT_RegExp stuff from NSS - unless there's really a good reason to keep that code in the library.)

[Nelson-bolyard (nelson-bolyard)]

(From update of attachment 289348)
After reading this patch, it appears to me that it behaves as follows:

> static SECStatus
> cert_TestHostName(char * cn, const char * hn)
> {

>+ char *wildcard = PORT_Strchr(cn, '*');
>+ char *firstdot = PORT_Strchr(cn, '.');
>+ char *seconddot = firstdot ? PORT_Strchr(firstdot+1, '.') : NULL;
>+
>+ /* for a cn pattern to be considered valid, the wildcard character...
>+ - may only occur in an FQDN with at least 3 components
>+ - may occur in the first component only, and must be its last character
>+ - may occur only once
>+ - may be preceded by additional characters
>+ */
>+ if (wildcard && firstdot && seconddot && *(seconddot+1)
>+ && firstdot == wildcard + 1
>+ && seconddot - firstdot > 1
>+ && PORT_Strrchr(cn, '*') == wildcard
>+ && PORT_Strncasecmp(cn, hn, wildcard - cn) == 0
>+ && PORT_Strcasecmp(firstdot, PORT_Strchr(hn, '.')) == 0)
>+ /* valid wildcard pattern match */

It implements these rules for the pattern in "cn":
- One and only one asterisk.
- No dots to the left of the asterisk, but other characters are allowed
to precede the asterisk.
- The asterisk must be followed immediately by the first dot.
- At least two dots, and second dot must not be last character in string.
(Note that this does not eliminate the possibility of a trailing dot.)
- At least one character between first dot and second dot.

If cn contains characters other than dot before the asterisk, then it
will compare those characters against an equal number of leading
characters from hn, and any non-match will mean a pattern match failure.
Otherwise, it will compare the strings beginning with the first dot in
each of cn and hn.

This patch relies on the fact that, presently, PORT_Strcasecmp is
defined as PL_strcasecmp, and unlike POSIX strcasecmp, PL_strcasecmp
is defined to NOT crash if either input string arguement is NULL.

Since the PORT_ functions exist to allow implementors to choose
different implemenations for their platforms, and PORT_Strcasecmp
could be defined as some other implementation, I suggest that the
patch should call PL_strcasecmp directly, to ensure that it gets
an implementation that has the desired property.

I'd prefer if PORT_Strchr(hn, '.') was called separately, and its
result stored in a pointer, and used only if it is non-NULL.

>+ return SECSuccess;
>+ else if (PORT_Strcasecmp(hn, cn) == 0)
>+ /* no valid wildcard pattern, but literal match */
>+ return SECSuccess;
>+ else {

Eliminate the elses immediately after returns. They serve no purpose.

>+ PORT_SetError(SSL_ERROR_BAD_CERT_DOMAIN);
>+ return SECFailure;
>+ }
> }

Unindent the final block and remove the braces from it.

Did you mean to disallow trailing dots from the patterns?
The present rules allow
  *.a.b.
but do not allow
  *.a.
Is that intentional?

Assuming it is, then I suspect this patch does what Kaspar intended for it
to do. So the remaining question is: are any of NSS's customers (teams that
develop products that use NSS) going to have a fit over this change?
I will ask about this in various n...

[Mozbugzilla (mozbugzilla)]

Created an attachment (id=290963)
Alternative patch for wildcard matching v3, addressing review comments

(In reply to comment #33)

Thanks for the review, Nelson.

> I suggest that the
> patch should call PL_strcasecmp directly, to ensure that it gets
> an implementation that has the desired property.
>
> I'd prefer if PORT_Strchr(hn, '.') was called separately, and its
> result stored in a pointer, and used only if it is non-NULL.

I did the latter, so it's not necessary to switch to PL_strcasecmp, I think. I also changed the name of two variables (since I'm introducing "firsthndot"), but other than that, there are no changes to the code logic.

> Eliminate the elses immediately after returns. They serve no purpose.

Done.

> Unindent the final block and remove the braces from it.

Done.

> Did you mean to disallow trailing dots from the patterns?
> The present rules allow
> *.a.b.
> but do not allow
> *.a.
> Is that intentional?

Yes. It follows from implementing your suggestion in comment 25:

> a new restriction, that wildcards must be followed by at least
> two dots (that is, two domains) excluding a trailing dot

["*.a." is only followed by one dot, not counting the trailing one.]

> Oh, and put an asterisk in every line in the block comment, so they
> form a column.

Done.

[Mozbugzilla (mozbugzilla)]

Created an attachment (id=290964)
Updated test program (for illustration purposes only), incorporating code from patch v3 [cf. comment 34]

The difference to the output shown in comment 17 is that it will no longer allow the "foo*bar.example.com" and "*" patterns (i.e. the last two lines with "MATCHES" now turn into a "does not match").

[Nelson-bolyard (nelson-bolyard)]

When I asked
> Did you mean to disallow trailing dots from the patterns?
my point was that the patch I was reviewing does NOT disallow trailing dots.
It merely doesn't count them in the count of dots following the star.
So *.a.b. is allowed, despite the trailing dot.
I asked that question because of bug 134402.
Kaspar, you may be interested in that bug.

[Mozbugzilla (mozbugzilla)]

(In reply to comment #36)
> When I asked
> > Did you mean to disallow trailing dots from the patterns?
> my point was that the patch I was reviewing does NOT disallow trailing dots.
> It merely doesn't count them in the count of dots following the star.
> So *.a.b. is allowed, despite the trailing dot.

Correct, but the primary purpose of the patch is to change/fix the wildcard matching, not checking whether "cn" contains a valid host name / host name pattern. If someone really has a cert with "CN=*.example.com.", then it doesn't hurt if that cert is working for "https://www.example.com./", I'd say.

(Checking for "proper" cn patterns is outside the scope of the cert_TestHostName function, IMO. If we would really want to disallow trailing dots, then we would have to ban things like "-*.example.com" for cn as well. And a number of others, probably...)

> I asked that question because of bug 134402.
> Kaspar, you may be interested in that bug.

I'm aware of that one, yes (see comment 21 above ;-).

[Nelson-bolyard (nelson-bolyard)]

(From update of attachment 290963)
I believe this patch does what you want it to do.
The question is: do we really want to make this change?
I'm trying to find that out now, by making inquiries in several channels.

[Nelson-bolyard (nelson-bolyard)]

(In reply to comment #30)
Kaspar, In comment 30. You wrote;

> CN=* doesn't work at all with IE,

Some followup questions to that:

Do you mean that a cert with CN=* will not match against a "simple host
name" URL such as https://myhost/ in IE?
Or do you mean only that it will not match any names containing dots?
Or do you mean that "*" is allowed only in Subject Alt Names, not in CN ?

Do you know what test/rule makes it fail?
Does IE require that at least one dot follow an askerisk?
Does *.com work with IE?

There have been many objections registered in various bugs to the fact that
NSS allows CN=* to match any DNS name including FQDNs, but the issues in
those complaints seem to be resolved by disallowing * to match any dots.
There seems to be a desire to allow "*" to match simple host names (names
with no dots), and I do not see that any of the above-cited RFCs disallows it.
OTOH, if it doesn't work with IE, then there is a pretty good case for
not supporting it.

[Mozbugzilla (mozbugzilla)]

(In reply to comment #39)
> Kaspar, In comment 30. You wrote;
>
> > CN=* doesn't work at all with IE,
>
> Some followup questions to that:
>
> Do you mean that a cert with CN=* will not match against a "simple host
> name" URL such as https://myhost/ in IE?
> Or do you mean only that it will not match any names containing dots?
> Or do you mean that "*" is allowed only in Subject Alt Names, not in CN ?

"*" doesn't match any unqualified ("dotless") name in IE, no matter if there's a CN=* or a dNSName entry with "*" in the subjectAltName extension. (And IE doesn't allow "*" to match for any host name which includes a dot either, of course - that's what I meant when saying "doesn't work at all".)

> Do you know what test/rule makes it fail?

I can't say what specific rule(s) IE uses, as I haven't seen its sources :-) But from all my tests I conclude that IE's rules are pretty similar to the ones which are now proposed by the latest patch (attachment 290963).

> Does IE require that at least one dot follow an askerisk?

Yes - and more than a dot must follow, actually: "CN=*." (or a subjectAltName entry with this pattern, for that matter) doesn't work for "https://myhost./", e.g.

> Does *.com work with IE?

No.

> There seems to be a desire to allow "*" to match simple host names (names
> with no dots), and I do not see that any of the above-cited RFCs disallows it.
> OTOH, if it doesn't work with IE, then there is a pretty good case for
> not supporting it.

Yes, this was also the conclusion I came to in comment 30, based on which I implemented v2 of the patch (attachment 289348, which is now obsoleted by v3).

[Mozbugzilla (mozbugzilla)]

(In reply to comment #38)
> (From update of attachment 290963 [details])
> I believe this patch does what you want it to do.
> The question is: do we really want to make this change?
> I'm trying to find that out now, by making inquiries in several channels.

Nelson, do you have news on the outcome of these inquiries? Were there objections/arguments which would require a reconsideration of the solution implemented by patch v3?

If not, can we go one step further? (I guess the patch needs a second review - who would be the right person to ask?)

[Reed Loden (reed)]

Hey guys... time is running out to get this in. Nelson, can you review the patch? Does anybody else need to look at it? I'd like to get some momentum going again on this bug. Thanks! :)

[Nelson-bolyard (nelson-bolyard)]

OK, here's the issue. This change will definitely cause some number of businesses to suddenly find that certificates that have been working for
them for a long time are no longer being accepted as valid. It would
effectively be a break in binary compatbility for NSS.

NSS cannot break binary compatbility UNLESS such a break MUST be done to
correct a vulnerability that is widely perceived to be a serious one.
This issue is not presently widely perceived to be a serious vulnerability.

So, our choices are:
a) Have the new behavior and the old behavior coexist in NSS, preserving the
present behavior with the existing function, or
b) wait for public consciousness of this vulnerability to be raised.

The simplest thing to do, and the one I would advocate, is to introduce
the new functionality as a new function, rather than as a modification of
an old function. Then applications can control whether they get the old
or new behavior, and applications that make no change continue to experience
compatible behavior.

[Nelson-bolyard (nelson-bolyard)]

(From update of attachment 290963)
SAdly, I must give this patch r-.
See the preceding comment for the reasons.

[Nelson-bolyard (nelson-bolyard)]

I found a live webmail server on the internet that relies on this "feature".
https://mail.netidentity.com.cust.hostedemail.com/
Their cert uses this wildcard pattern: *.hostedemail.com
They're counting on '*' to match "mail.netidentity.com.cust".

[Reed Loden (reed)]

(In reply to comment #45)
> I found a live webmail server on the internet that relies on this "feature".
> https://mail.netidentity.com.cust.hostedemail.com/
> Their cert uses this wildcard pattern: *.hostedemail.com
> They're counting on '*' to match "mail.netidentity.com.cust".

There is _always_ going to be somebody not doing what they are supposed to be doing. That doesn't mean we shouldn't fix it to be correct, with regards to RFC 2818. Please note that Safari 3.x and IE 7 both consider abusing SSL certificates like that as a failure. Safari completely refuses to load the site while IE 7 allows the user to continue on after accepting a warning dialog. I just don't see why one site (or even multiple sites) doing something wrong should cause us not to fix an actual bug that could be abused by people for nefarious purposes.

[Devel-regnard (devel-regnard)]

This is really problematic since zone delagation possibility extend the validity of the certificate to untrusted fqdn or organisations and this has obvious security issues !

This is easy to understand: *.domain.com in the cn stands for any domain name under .domain.com. * matches everything but the dot ! This is how trusted CAs treat it according to RFC 2818.

With perl the regex to achieve this is as simple as:

/^[^\.]+\.domain\.com$/

this should normally not take years to implement ? Can you please give a final decision on that ?

IE 6 and 7 now implement it that way !!

[Jo-hermans (jo-hermans)]

*** Bug 438322 has been marked as a duplicate of this bug. ***

[Kajtzu (kajtzu)]

It would be nice if someone could make this bug happen considering the two other major browsers (IE, Safari) behave according to RFC 2818. Nobody building a public service/site can use this feature as they need to have it work with all three without security warnings or errors. FF is not at 99% market share yet.

[Nelson-bolyard (nelson-bolyard)]

(From update of attachment 290963)
The time for this change is rapidly approaching. Stay tuned.

[Nelson-bolyard (nelson-bolyard)]

Created an attachment (id=366705)
alternative patch v4 - preserve old code with environment variable

This patch is Kaspar's v3 patch, modified to allow old code to be
preserved with an environment variable. Kaspar, if you approve,
I'll commit this and give you credit. (is that a conflict of interest?)

[Mozbugzilla (mozbugzilla)]

(In reply to comment #51)
> This patch is Kaspar's v3 patch, modified to allow old code to be
> preserved with an environment variable. Kaspar, if you approve,
> I'll commit this and give you credit. (is that a conflict of interest?)

I don't like the option of adding this sort of "backdoor", but if it's the only way to make this change happen, then you have my approval.

Looking at patch v4, both the variable names and the comments now insinuate that the current code supports regex matching:

+ if (useRegex < 0) {
+ useRegex = (NULL != PR_GetEnv("NSS_USE_REGEX_WILDCARDS"));
+ }
+ if (useRegex) {
+ /* Backward compatible code, uses full Regular Expressions. */
+ int regvalid = PORT_RegExpValid(cn);
+ if (regvalid != NON_SXP) {
+ SECStatus rv;
+ /* cn is a regular expression, try to match the shexp */
+ int match = PORT_RegExpCaseSearch(hn, cn);

This is not the case, however, as I wrote in comment 16. Perhaps the environment variable should be named NSS_USE_SHEXP_WILDCARDS, and the comment should make it clear that it's shell-style matching, not regular expressions.

And since you're mentioning RFC 2818 further down in the code (which is certainly useful), maybe it would make sense to add references to RFCs 2595, 4513, 4642, and 4954 as well - these are actually on the standards track, in contrast to RFC 2818.

[Nelson-bolyard (nelson-bolyard)]

Created an attachment (id=366877)
patch v5 - don't call it regex

I used Kaspar's suggestion for the environment variable name.

Each of the RFCs cited in the preceding comment defines a somewhat
different standard from the one implemented in this patch, so I prefer
to continue to cite only the RFC that we're trying to match.
This routine isn't meant to be the one-size-fits-all cert name matcher.
It's really for https. If other application protocol implementations
(such as email) choose to use it, that's their decision, but they're
able to supply alternate functions for this purpose.

[Wan-Teh Chang (wtc-google)]

(From update of attachment 366877)
r=wtc.

>-** may modify cn, so caller must pass a modifiable copy.
>+** This function may modify *cn, so caller must pass a modifiable copy.

Let's still call it cn instead of *cn. You're still using cn
in the other comments in this function.

Nit: The name of the environment variable should ideally
include CERT_NAME. Also note that the old code allows not
only shell-style wildcards but also unions (|), so WILDCARDS
doesn't completely describe what the old code allows.

>+ if (useShellExp) {
>+ /* Backward compatible code, uses full Regular Expressions. */

The comment says "regular expressions", but the environment
variable and static variable say "shell expressions". They
seem to contradict either other.

>+ if (wildcard && secondcndot && secondcndot[1] && firsthndot

Should we also require that secondcndot[1] != '.'?

>+ && PORT_Strrchr(cn, '*') == wildcard

Is it cheaper to test
            && PORT_Strchr(cn+1, '*') == NULL
instead?

>+ && !PORT_Strncasecmp(cn, hn, wildcard - cn)

I verified that if wildcard - cn is 0, PORT_Strncasecmp
returns the desired 0. The reason I checked this is that
for the similar function strncmp, the return value when the
third argument is 0 doesn't seem to be specified:
http://www.opengroup.org/onlinepubs/000095399/functions/strncmp.html

>+ /* CN has no wildcard or shell expression.

Nit: use lowercase cn to match the parameter name.

[Wan-Teh Chang (wtc-google)]

Bug 261900 is a reminder that the old NSS code allows
unions (|) in certificate names.

[Nelson-bolyard (nelson-bolyard)]

(From update of attachment 366877)
I made the changes to comments and variable names suggested by wtc.
Checking in certdb.c; new revision: 1.97; previous revision: 1.96

[Nelson-bolyard (nelson-bolyard)]

I received some feedback from a Sun Java developer, saying that JSSE's
interpretation of wildcards allows "*" to appear any number of times in
each component of a DNS name in a cert. It simply does not match a dot.

So, for example, given an attempt to connect to https://java.sun.com
JSSE would match java.sun.com with
  j*.sun.com
 *va.sun.com
j*va.sun.com
j*v*.sun.com
  java.*.com
    java.*.*
       *.*.*
but would not match
      java.*
    *sun.com

The writer believes that behavior is what is required by RFC 2818.

[georgi (guninski)]

  java.*.com
    java.*.*
       *.*.*

the interesting part which cert seller will sell such certs, especially "*.*.*"

from which cert seller should i buy?

[Mozbugzilla (mozbugzilla)]

(In reply to comment #57)
> The writer believes that behavior is what is required by RFC 2818.

RFC 2818 allows the wildcard character to appear in components other than the leftmost one, that's correct. The goal of my patch, however, was to also comply with RFCs 2595 and 4513 at the same time. See comment 22 and comment 26.

(In reply to comment #58)
> the interesting part which cert seller will sell such certs, especially "*.*.*"
>
> from which cert seller should i buy?

You'll have a (very?) hard time finding one, I guess. And they will definitely not work with that other major browser.

[georgi (guninski)]

>You'll have a (very?) hard time finding one, I guess.

sure. i tried the "*~.whatever" trick with some sellers and they sanitized it.
though i tried it with ordinary cert, not wildcard cert - wildcard certs were too expensive for the odds of the experiment imo.

>And they will definitely not work with that other major browser.

the firefox userbase is ok for me ;)

[Wan-Teh Chang (wtc-google)]

Kaspar, why do you disallow a wildcard to be followed by
additional characters in the leftmost component? That
requirement is not in RFCs 2595 and 4513.

We should update the comment (citing RFCs 2595 and 4513)
to match the code. The current comment "New approach
conforms to RFC 2818" is not accurate.

[Mozbugzilla (mozbugzilla)]

(In reply to comment #61)
> Kaspar, why do you disallow a wildcard to be followed by
> additional characters in the leftmost component? That
> requirement is not in RFCs 2595 and 4513.

It is, actually: both allow it as "*the* left-most component/DNS label", which implies that it can neither be preceded nor followed by any additional characters.

The rules which I implemented don't follow slavishly the RFCs in any case - e.g., none of them requires the component with the wildcard character to be followed by two additional components. We arrived at this solution in earlier discussions (see comment 25, inter alia).

[Johnath (johnath)]

This bug is marked blocking1.9.1. As I understand it, this change was included in the NSS_3_12_3_RC0 tag, which Kai pushed to the 1.9.1 branch in bug 481968 (changeset http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f160224c5221 ). Therefore, I'm marking this bug fixed1.9.1.

Please let me know if I've misunderstood.

[Eero (eero+launchpad)]

Binary package hint: mozilla-firefox

firefox 3.0.10+nobinonly-0ubuntu0.9.04.1

http://www.ietf.org/rfc/rfc2818.txt states the following:
   Matching is performed using the matching rules specified by
   [RFC2459]. If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

Firefox accepts *.foo.com certificate for a domain baz.bar.foo.com even though it shouldn't do that. Tested with new DigiCert wildcard certificate and it seems like IE handles this situation correctly.

[Reed Loden (reed)]

Already fixed upstream. Fix will be in Firefox 3.5 and later. It's possible this may be backported to Firefox 3.0.x, but I'm unsure.

[Kevin Brosnan (kbrosnan)]

*** Bug 495339 has been marked as a duplicate of this bug. ***

[Kevin Brosnan (kbrosnan)]

This is not fixed on Mozilla 1.9.1 or Mozilla-central http://mxr.mozilla.org/mozilla-central/source/security/nss/lib/certdb/certdb.c#1446

[Wan-Teh Chang (wtc-google)]

It's the opposite. Because this bug is fixed, the cert in
bug 495339 no longer matches that host name.

[Brendan-webafrica (brendan-webafrica)]

From my reading of the above, we're now following RFC's blindly with little regard for context. I posted bug 495339. Unfortunately, RFCs aren't infallible.

1. Bad CAs issuing * certs without proper verification? rm -f
2. Prove that removing backwards compatibility has tangibly improved security. Change this bug to REOPENED.
3a. Are regex's supported?
 b. If so, do any CAs support regex's or is this only for self-signed certs?
4. Don't "fix" the trailing dot - it ain't broke

1. Respectable commercial Cert providers shouldn't be issuing certificates for "*.com" or "*.co.za" or "*" or any other similar address. If there's a vendor that does issue these certificates they should be considered untrustworthy and removed from the CA repository.

The cert vendors I've worked with verify that the certificate is actually being issued to the domain administrator. The same applies here - if the CA isn't verifying that the certificate is being issued to the domain's owners then the CA must be removed from the CA repository.

Based on the above, I'd like to see how anyone might prove to a CA that they own the .com domain. If you're able to do it, remove that CA from the repository.

2. The example in my bug 495339 has an address under glodns.net. glodns.net has a certificate that has been issued to the administrators in charge of glodns.net. The administrators of glodns.net are asserting that the full address in question does in fact belong to the glodns.net network - only now we're interpreting things differently from before and the expected behaviour is broken.

Most certificate vendors describe their wildcard certificates as "unlimited subdomains". foo.bar.example.com is still a subdomain of example.com no matter how many dots inbetween the foo and example.

What is the purpose of removing the backwards compatibility here? Can you give me a plausible risk that having the wildcard NOT match the dot really mitigates? "Its RFC" isn't a good answer here. As I said above, RFCs aren't infallible and we've been ignoring it for a VERY long time without any complaints.

Please change this bug to REOPENED.

3a. Are regular expressions supported in any way as mentioned in comment 0? I'm not at work and I don't have the resources at hand to test this properly. I can test this Monday on a self-signed cert.

3b. Assuming regex's are supported, do any cert vendors support regex's?

4. Finally, it seems nobody wants to "fix" the trailing dot but it might come up again - it is the Internet root. In DNS, the . is always implied. Ignoring the trailing dot is fine. Here are my DNS dig results for "bugzilla.mozilla.org" and "bugzilla.mozilla.org.". Take note of the trailing dots in the results for both queries:

> [ brendan@swift : 08:07:17 : ~ ]
> :) dig bugzilla.mozilla.org | grep . | grep -v "^;"
> bugzilla.mozilla.org. 60 IN CNAME bugzilla-mozilla-org.geo.mozilla.com.
> bugzilla-mozilla-org.geo.mozilla.com. 1661 IN CNAME dyna-bugzilla.nslb.sj.mozilla.com.
> dyna-bugzilla.nslb.sj.mozilla.com. 600 IN A 63.245.209.72

> [ brendan@swift : 08:07:41 : ~ ]
> :) dig bugzilla.mozilla.org. | grep . | grep -v "^;"
> bugzilla.mozilla.org. 4 IN CNAME ...

[Brendan-webafrica (brendan-webafrica)]

Um... maybe should have been more specific:
2. Prove that the wildcard NOT matching dots has tangibly improved security.

[Wan-Teh Chang (wtc-google)]

(In reply to comment #67)

You can set the environment variable NSS_USE_SHEXP_IN_CERT_NAME
to 1 before starting Firefox to get the old certificate name
matching behavior. See

http://www.mozilla.org/projects/security/pki/nss/nss-3.12.3/nss-3.12.3-release-notes.html#new

[Johnath (johnath)]

*** Bug 501862 has been marked as a duplicate of this bug. ***

[Dveditz (dveditz)]

Further in reply to comment 67: You make reasonable points (though not new ones) but a fixed bug is not the place to argue policy. For now we have decided that compliance with the RFC--or rather, consistent behavior amongst browsers--is safer for users if occasionally inconvenient for administrators.

If you want to argue for different behavior then the mailing list/newsgroup mozilla.dev.tech.crypto is the right place (or maybe the new mozilla.dev.security.policy?)

[Mozbugzilla (mozbugzilla)]

Can bug 500495 be unhidden, please? Moxie Marlinspike's cat is now out of the bag.

[Samuel-sidler+old (samuel-sidler+old)]

Fixed for 1.9.0.13 by bug 500495.

[georgi (guninski)]

> Moxie Marlinspike's cat is now out of the bag.

it will be interesting what will be blacklisted this time

[georgi (guninski)]

> Moxie Marlinspike's cat is now out of the bag.

just out of curiousity, is the the relevant code FIPS certified ?

[Nelson-bolyard (nelson-bolyard)]

> just out of curiousity, is the the relevant code FIPS certified ?

LOL. No. DNS is entirely out of scope for FIPS-140.

[Jbecerra-mozilla (jbecerra-mozilla)]

Nelson, could you help us verify this bug for Fx3.0.13?

[Nelson-bolyard (nelson-bolyard)]

Sure,
go visit https://swiftspirit.co.za.plesk01.glodns.net/
with both 3.0.12 and 3.0.13.
It should work with 3.0.12 and not 3.0.13.

[Jbecerra-mozilla (jbecerra-mozilla)]

Created an attachment (id=392043)
3.0.12 vs 3.0.13

Verified per comment #78 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.13) Gecko/2009073021 Firefox/3.0.13

Thanks again, Nelson.

[Mozbug1 (mozbug1)]

Great. You've broken my website. Thanks a lot.

[Nelson-bolyard (nelson-bolyard)]

Yup, web sites with broken certs are now just as broken on Firefox as they
were with IE and Opera.

[Mozbug1 (mozbug1)]

A *.*.xxxx.xxx certificate is not broken. Well it wasn't until now.

[Nelson-bolyard (nelson-bolyard)]

Read RFC 2818, and test with IE and Opera.

[Mozbug1 (mozbug1)]

I did read the rfc. The rfc does not prohibit *.*.xxxx.xxx. And while I knew my website was broken with IE I was expecting more from Firefox. Since when do we look to IE for inspiration on how to do things?

[Abillings (abillings)]

Verified per comment #78 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.14pre) Gecko/2009081305 GranParadiso/3.0.14pre (.NET CLR 3.5.30729).

[Iwade (iwade)]

Google is using a multi-level wildcard *.*.appspot.com certificate for App Engine.

It works in Safari, and was previously working in Firefox (up to 3.0.12).

I agree with Comment #53 (Nelson Bolyard) that the routine in question should be crafted specifically for HTTPS, so I fail to understand why RFCs for IMAP, POP3, ACAP, LDAP, NNTP or SMTP over TLS were even considered.

I agree with Comment #24 (<email address hidden>) that the intent for restricting the wildcard character to left most component in other protocols was likely to restrict the wildcard matching to the left side of the hostname. *.* support would be in the spirit of that interpretation.

Would a patch tweaking the behaviour to allow multiple left-aligned wildcard components be considered?

I think it's quite important for shared hosting solutions, not just corporate intranets.

[Jo-hermans (jo-hermans)]

*** Bug 560476 has been marked as a duplicate of this bug. ***