[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-wget] Overly permissive hostname matching
From: |
Daniel Kahn Gillmor |
Subject: |
Re: [Bug-wget] Overly permissive hostname matching |
Date: |
Tue, 18 Mar 2014 10:11:22 -0400 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.2.0 |
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.
thanks for raising this concern.
Have you tested this certificate and CA with other HTTPS clients (like
browsers?)
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
So arguably, it is the responsibility of the CA, not the responsibility
of the relying party, to determine what certs are legitimate.
Put another way: should every TLS client library embed the public suffix
list? how often should they update it? 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)?
--dkg
signature.asc
Description: OpenPGP digital signature
Re: [Bug-wget] Overly permissive hostname matching, Tim Rühsen, 2014/03/18