SSL hostname matching does not allow subdomain matching

Bug #573256 reported by Kees Cook
14
This bug affects 2 people
Affects Status Importance Assigned to Milestone
irssi (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

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

Revision history for this message
Jamie Strandboge (jdstrand) wrote :

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.

Revision history for this message
Kees Cook (kees) wrote :

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!

Changed in irssi (Ubuntu):
status: New → Invalid
status: Invalid → Incomplete
summary: - regression is SSL hostname matching
+ SSL hostname matching does not allow subdomain matching
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in irssi (Ubuntu):
status: Incomplete → Expired
Kees Cook (kees)
Changed in irssi (Ubuntu):
status: Expired → Confirmed
status: Confirmed → New
Revision history for this message
Rhonda D'Vine (rhonda) wrote :

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

 Thanks in advance,
Rhonda

Revision history for this message
Kees Cook (kees) wrote :

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

Revision history for this message
Rhonda D'Vine (rhonda) wrote :

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.

Changed in irssi (Ubuntu):
status: New → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.