Subject: [dbound] Certificate wildcards vs. DNS wildcards

From: "John Levine" <[email-masked]>
Date: 15 Jun 2015 01:36:40 -0000

I was surprised to find that the rules for domain wildcards in SSL
certificates is different from the rules in the DNS.  In the DNS, the
only wild card is *. as the terminal name, while in certs, it's more
like shell wildcards, abc*.example.com matches what it looks like.  I
verified that this isn't a bug, in that the description of cert
wildcards in RFC 6125 is deliberately different and matches what
browsers do.

If we use something like my DNS hack (look in the list archives) to
publish PSL-ish information, this could in principle be a problem.
But I wondered how many certs actually use wildcards other than a
plain *.

I used the University of Michigan's HTTPS Ecosystem data, available
here:  https://scans.io/study/umich-https
(It's newer than the EFF's SSL Observatory and a lot easier to
download.)

It has about 147M certificates.  I mechanically went through and
extracted every certificate CN= that contained a * and deduped them,
coming up with 852K, a very small fraction.  I then went through
and selected the CN= that didn't start with *.x where x was not
a *, of which there were only 5182.  I put those files at
http://www.taugh.com/certs, in stars.txt and oddstars.txt.

Of those 5182 that didn't start with *., over 4000 were some odd
pseudo-hex stuff starting \x00 that looks to me either intended for a
non-standard application, or maybe they're just broken.  So of the
147M certificates, I see less than a thousand that have plausible
non-DNS wildcards, and eyeballing them, the wildcard stuff is all to
the left of an ordinary domain name.

So even though the wildcard rules are different, in practice it
doesn't matter.

R's,
John

---

From: Jeffrey Walton <[email-masked]>
Date: Sun, 14 Jun 2015 22:04:51 -0400

> non-standard application, or maybe they're just broken.

This looks like the start of Marlinspike's Null Prefix attack*. I
would reject it as malformed since the ASN.1 payload length is not
equal to strlen(cstr of ASN.1 string).

That still leaves about 1000 certificates from the reduced data set.

Jeff

* https://www.blackhat.com/presentations/bh-usa-09/MARLINSPIKE/BHUSA09-Marlinspike-DefeatSSL-SLIDES.pdf

---

From: Gervase Markham <[email-masked]>
Date: Mon, 15 Jun 2015 08:53:02 +0100

> wildcards in RFC 6125 is deliberately different and matches what

I'm surprised that you've verified that, in that my understanding is
that no browser for many years has supported abc*.example.com (or, for
that matter, foo.*.example.com). This is why you don't see them in the
wild. Do you have evidence to the contrary?

Gerv

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 15 Jun 2015 04:15:33 -0400

> wild. Do you have evidence to the contrary?
Browsers are only one type of user agent.

Jeff

---

From: Gervase Markham <[email-masked]>
Date: Mon, 15 Jun 2015 09:19:19 +0100

> Browsers are only one type of user agent.

Indeed so. But you said "matches what browsers do", not "matches what
user agents do".

I admit I have much less insight into the behaviour of non-browser user
agents. I would still be interested in the names of current bits of
software which recognise "abc*.example.com" or similar.

Gerv

---

From: Gervase Markham <[email-masked]>
Date: Mon, 15 Jun 2015 09:19:26 +0100

> Browsers are only one type of user agent.

Indeed so. But he said "matches what browsers do", not "matches what
user agents do".

Gerv

---

From: Jeffrey Walton <[email-masked]>
Date: Mon, 15 Jun 2015 04:28:48 -0400

> software which recognise "abc*.example.com" or similar.

OpenSSL has an option to match multiple wildcards at any label, and
not just the leftmost label. And by default, it matches partials. See
X509_check_host (3)
(https://www.openssl.org/docs/crypto/X509_check_host.html) man pages.

(Sorry if the terseness made it sound argumentative. That was not the point).

Jeff

---

From: Tomoyuki Sahara <[email-masked]>
Date: Mon, 15 Jun 2015 17:51:36 +0900

Hi,

> software which recognise "abc*.example.com" or similar.

Current versions of Python3, Ruby, and curl allow such wildcards
and try partial matching.  LibreSSL does not.

https://hg.python.org/cpython/file/f4b4e23475d0/Lib/ssl.py#l194
https://github.com/ruby/ruby/blob/trunk/ext/openssl/lib/openssl/ssl.rb#L200
https://github.com/bagder/curl/blob/master/lib/hostcheck.c#L60

Thanks,
Tomoyuki

---

From: "John R Levine" <[email-masked]>
Date: 15 Jun 2015 08:49:51 -0400

> wild. Do you have evidence to the contrary?

No, but the spec says what it says.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.

---

From: Gervase Markham <[email-masked]>
Date: Mon, 15 Jun 2015 13:57:07 +0100

> No, but the spec says what it says.

Indeed it does; but you made claims both about the spec (which are
right) and about browser behaviour (which are wrong).

https://bugzilla.mozilla.org/show_bug.cgi?id=159483#c11
and many related bugs.

Gerv

---

From: "John Levine" <[email-masked]>
Date: 15 Jun 2015 19:09:05 -0000

>Indeed so. But you said "matches what browsers do", not "matches what

Indeed, you're right.  As we say, so sue me.  

We appear to be in agreement with the conclusion that although non-DNS
wildcards are allowed, they are very uncommon in practice.

R's,
John

---

From: Rick Andrews <[email-masked]>
Date: Mon, 15 Jun 2015 16:39:48 -0700

Also Windows SChannel supports those wildcards: 
http://support.microsoft.com/kb/258858

-Rick

From: Tomoyuki Sahara [mailto:[email-masked]]
Sent: Monday, June 15, 2015 1:52 AM
To: Gervase Markham
Cc: [email-masked]; [email-masked]
Subject: Re: [dbound] Certificate wildcards vs. DNS wildcards

Hi,

Thanks,

Tomoyuki