[gnutls-devel] Overly permissive hostname matching

[Jeffrey Walton]

On Tue, Mar 18, 2014 at 4:40 AM, Nikos Mavrogiannopoulos
<nmav at gnutls.org> wrote:
> On Tue, Mar 18, 2014 at 7:11 AM, Jeffrey Walton <noloader at gmail.com> wrote:
>> I believe GnuTLS has a security flaw in its certificate hostname matching code.
>> In the attached server certificate, the hostname is provided via a
>> Subject Alt Name (SAN). The only SAN entry is a DNS name for "*.com".
>> Also attached is the default CA, which was used to sign the server's
>> certificate.
>> Effectively, wget accepts a single certificate for the gTLD of .COM.
>> That's probably bad. If a CA is compromised, then the compromised CA
>> could issue a "super certificate" and cover the entire top level
>> domain space.
>
> That's a very interesting point, but I am not sure there is an easy
> fix. GnuTLS follows RFC2818 for hostname verification, and that
> document is pretty clear on the scope of the wildcards. It mentions
> for example: "f*.com matches foo.com". Maybe we can forbid a first
> level wildcard, but is that practice documented somewhere? I don't see
> any IETF documents updating RFC2818.
Hi Niko. I don't recall reading a prohibition anywhere. I even seem to
recall the browser's use of the list as voluntary (for lack of a
better term) since it was not prohibited or under specified. Maybe its
one of those things along the lines of "why would anyone ever need to
revoke a CA"....

Intuitively, we know that no one CA services a particular domain in
the gTLD space, so something seems out of place in clients willing to
accept a super cert.

How does GnuTLS handle DNS names with an embedded NULL (Kaminsky's and
Marlinspike's NULL Termination Attacks)? Does it take a proactive
approach by rejecting the certifcate? If so, rejecting a certifcate
for *.COM and *.NET would seem to be consistent behavior.

Jeff