SSL hostname matching does not allow subdomain matching

[Kees Cook]

Binary package hint: irssi

The wildcard implementation in irssi only allows a single hostname depth for "*", so *.freenode.net does not match chat.us.freenode.net. As seen in match_hostname() from src/core/network-openssl.c:

...
   } else if (cert_hostname[0] == '*' && cert_hostname[1] == '.' && cert_hostname[2] != 0) { /* wildcard match */
       /* The initial '*' matches exactly one hostname component */
       hostname_left = strchr(hostname, '.');
       if (hostname_left != NULL && ! strcasecmp(hostname_left + 1, cert_hostname + 2)) {
           return TRUE;
       }
   }
   return FALSE;
}

20:20 < kees> 19:34 -!- Irssi: warning None of the Subject Alt Names in the certificate match hostname 'chat.us.freenode.net'
20:20 < kees> 19:34 [freenode] -!- Irssi: Connection lost to chat.us.freenode.net

[Jamie Strandboge (jdstrand)]

AIUI, this is the desired behavior. From rfc2818 regarding HTTP Over TLS (http://www.faqs.org/rfcs/rfc2818.txt):
3.1. Server Identity
...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.

Also, rfc2595 regarding Using TLS with IMAP, POP3 and ACAP is slightly more ambiguous, but implies the same behavior (http://www.faqs.org/rfcs/rfc2595.html):
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.

It is also known that while some browser implementations do honor hostname.subdomain.domain, they are out of spec. I don't see any RFCs regarding IRC wrt SSL, so following other implementations seems most correct.

Simply put, seems that *.us.freenode.com needs to have its own wildcard certificate to properly use SSL.

[Kees Cook (kees)]

It probably makes sense to follow the HTTP spec, as that is what most people think of for SSL. I will open an upstream bug report and see what happens. (I'll also test xchat with SSL, possibly need to open a bug with freenode too.) Thanks for looking into that!

[Launchpad Janitor (janitor)]

[Expired for irssi (Ubuntu) because there has been no activity for 60 days.]

[Rhonda D'Vine (rhonda)]

 Kees, did you actually open the upstream bug? If so, could you kindly link it?

 Thanks in advance,
Rhonda

[Kees Cook (kees)]

Hi, I have not, since it was not clear if multi-level wildcards were convered by the spec.

[Rhonda D'Vine (rhonda)]

Erm, AIUI a wildcard doesn't cover further sub domains in SSL spec. It's exactly the same behavior how web browsers handle this and is consistent. If you have a convincing reason why you believe this has to work (like, pointing at the specifications) then this has a chance to get covered - otherwise I'd say it works as intended. A wildcard doesn't cover subdomains.