[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] Overly permissive hostname matching

From: Jeffrey Walton
Subject: Re: [Bug-wget] Overly permissive hostname matching
Date: Tue, 18 Mar 2014 11:00:51 -0400

On Tue, Mar 18, 2014 at 10:11 AM, Daniel Kahn Gillmor
<address@hidden> wrote:
> Hi Jeffrey--
> On 03/18/2014 01:43 AM, Jeffrey Walton wrote:
>> I believe wget 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.
> Have you tested this certificate and CA with other HTTPS clients (like
> browsers?)
Firefox and Chromium reject.

Two non-browsers reject: cURL and  aria2c.

Seven other non-browsers fail to reject.

More testing to come with additional programs as I find them.

> Section 11.1.3 of the CA/Browser Forum's baseline requirements for CAs
> are that compliant CAs MUST NOT issue wildcard certs for an entire
> registry-controlled zone or public suffix "unless the applicant proves
> its rightful control of the entire Domain Namespace":
> https://cabforum.org/wp-content/uploads/Baseline_Requirements_V1_1_6.pdf
Thanks. I was aware of the two CA/B guides (and RFC 5280/6125), but I
did not go through them looking for references. I appreciate you
saving me the trouble.

> So arguably, it is the responsibility of the CA, not the responsibility
> of the relying party, to determine what certs are legitimate.
Oh, gotcha. Isn't that a lot like saying, CAs will never need to be
revoked so there's no need to specify the behavior. (just kidding).

In the case of a non-browser program that silently accepts the super
cert, how is the program supposed to know to prompt the user if it
[incorrectly] thinks everything is OK?

> Put another way: should every TLS client library embed the public suffix
> list?
Yes. Browsers do it, some others do it, and I do it in my software.
(not that I matter).

Or perhaps a distro could provide the list in standardized format for
any program to use. (much like the way they provide a trusted
certifcate list).

> how often should they update it?
Yeah, that sucks. I have to keep an eye on Mozilla's Public Suffix
List and update it, parse it and format it as required (actually, I
have a script to do the lifting).

I embed the list as a resource in my executable. I embed it because I
don't want an un-informed user deleting it because they don't know
what it is.

I don't really care about the size of the resulting executable. But I
do care about program correctness, especially when I know a
mitigatable threat exists.

> What if a certificate is issued by a trusted CA that *does*
> match part of the public suffix list (perhaps because the
> CA has determined tha tthe application has rightful
> control over the entire zone)?
In practice we know four things. First, no one authority controls the
entire domain space in a gTLD. So its really a non-sequitur. We might
inadvertently see it in cases like Diginotar, but that's a negative
case and not a typical use case. However, we should expect these
corner cases on occasion.

Second, anyone claiming such is probably trying to subvert the secure
channel. Since there are two endpoints in the channel, that would me
someone is claiming to have permission from both parties (the employee
and his bank, an employee and her husband. etc) to intercept the
communications. I doubt its ever the case that the second party agrees
to such terms.

Third, we know some CAs are more than happy to issue certificates
outside their authority. Trustwave comes to mind. The market did not
"correct itself" because Trustwave is still in business in a sector
where trust is a commodity. That means CAs have learned its OK to
break the rules, so we should expect more of the same in the future.

Fourth, there's no need for a CA to perform the checks if they can
offload the risk. And the CPS'es and warranties I have read from CAs
do a good job of that. That means the relying party will probably
assume the risk. Since the relying party (you and I) have all the risk
pushed on us, its our software that should be performing the checks.

If we did not have hostile environment and negative cases, then we
wouldn't even need to perform hostname matching (and other
verification). Anonymous Diffie-Hellman and self-signed certs would be
fine. But we do have to do these things so a defensive posture is in


Attachment: no-super-cert.png
Description: PNG image

reply via email to

[Prev in Thread] Current Thread [Next in Thread]