Re: [Bug-wget] Overly permissive hostname matching

[Darshit Shah]

Hi Jeffrey,

Thanks for pointing this out!
I am no expert in security or SSL for that matter. However, this does
seem like a huge security flaw.

I'll try and set up a test case as soon as I can using the materials
provided by you. It would be even more helpful if someone could pitch
in with more help since: 1. This is not my domain and I don't
understand it much. 2. I'm keeping really busy with my real life work
and GSoC right now.

The new test suite can implement a HTTPS Server, so it shouldn't be
too difficult to set this up.

On Tue, Mar 18, 2014 at 6:43 AM, Jeffrey Walton <address@hidden> 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.
>
> 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.
>
> I suspect wget also accepts certificates for .COM's friends, like
> .NET, .ORG, .MIL, etc.
>
> Its probably not limited to gTLDs. Mozilla maintains a list of
> effective TLDs at https://wiki.mozilla.org/Public_Suffix_List. The
> 1600+ effective TLDs are probably accepted, too.
>
> Attached are the certificates, keys, and commands to set up a test rig
> with OpenSSL's s_server. The certificates are issued for example.com,
> and require a modification to /etc/hosts to make things work as
> (un)expected.
>
> Jeffrey Walton
> Baltimore, MD, US



-- 
Thanking You,
Darshit Shah