[Bug-wget] Overly permissive hostname matching
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 hostname-verification.tar.gz Description: GNU Zip compressed data
Re: [Bug-wget] Overly permissive hostname matching
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
[Bug-wget] [Bug-Wget] Issues with Metalink support
I was trying to download a large ISO (4GB) through a metalink file. The first thing that struck me was: The file is first downloaded to /tmp and then moved to the location. Is there any specific reason for this? I understand that downloading partial files to /tmp , stitching them and then moving them to the actual download location might be good on I/O. But, a very popular case in such scenarios is when /tmp is not large enough to store the file, but I have enough capacity in the location where I'm trying to store it. Wget tried to download the file to /tmp, where it failed since it ran out of free space. As a result, Wget crashed instead of exiting gracefully. Failing in itself should be considered a bug since I never intended to save it to /tmp. The download location I selected has enough disk space. We know that origin/master does not fail even with very large files. Even if the disk is out of capacity, Wget manages to exit gracefully. I'll try to dive into the code once I get time, but if anyone has any ideas in the meantime, it would be greatly appreciated! -- Thanking You, Darshit Shah
Re: [Bug-wget] Overly permissive hostname matching
I don't think wget should be checking correct hostname scope of the certificate. I mean, it'd be ok to have some general rule as noone can use a certificate for *.whatever or *. [1] but embedding the Public Suffix List seems overkill. And the implementation should probably be performed at openssl/gnutls level. If an attacker was able to get a CA-signed certificate for *.com (even though browsers reject that), he is very likely to have also been able to create a certificate for the domain you are browsing or directly a sub-CA. Daniel, how does cURL check correctness of the certificate hostname suffix? 1- And even them, we might end up with a new TLD (eg. *.apple ) where turns out to be correct.
Re: [Bug-wget] Overly permissive hostname matching
Hi Jeffrey, thanks for pointing this out. BTW, to reproduce the issue I used a GnuTLS compiled/linked version of Wget: $ wget -d --ca-certificate=ca-rsa-cert.pem --private-key=ca-rsa-key-plain.pem https://example.com:8443 2014-03-18 21:48:04 (1.88 GB/s) - Read error at byte 5116 (The TLS connection was non-properly terminated.).Retrying. There seems to be a problem in Wget 1.15 (on Debian SID)... But despite from that, Wget uses the hostname checking facility of the GnuTLS library (or of OpenSSL library if appropriately compiled). And I saw you already addressed bug-gnutls, which seems the right way to go. IHMO, the Public Suffix List (PSL) should not only be used to verify cookies but also be used for certificate hostname checking. Libraries as GnuTLS should offer an API for this kind of checking, best would be having the PSL as a separate file, maintained by the distribution maintainers (or the user, if he wants to to it). The SSL library should load/unload the PSL under the applications control. Maybe it would be a good idea to provide a separate PSL library that could be used by SSL libraries for hostname checking and HTTP(S) clients for cookie verification. If of any interest, there is already some LGPLed code at https://github.com/rockdaboot/mget/blob/master/libmget/cookie.c There are also some unit test routines in the project. Regards, Tim signature.asc Description: This is a digitally signed message part.
Re: [Bug-wget] Overly permissive hostname matching
On 03/18/2014 05:31 PM, Tim Rühsen wrote: $ wget -d --ca-certificate=ca-rsa-cert.pem --private-key=ca-rsa-key-plain.pem https://example.com:8443 2014-03-18 21:48:04 (1.88 GB/s) - Read error at byte 5116 (The TLS connection was non-properly terminated.).Retrying. There seems to be a problem in Wget 1.15 (on Debian SID)... hm, i'll try to take a look at this. But despite from that, Wget uses the hostname checking facility of the GnuTLS library (or of OpenSSL library if appropriately compiled). And I saw you already addressed bug-gnutls, which seems the right way to go. IHMO, the Public Suffix List (PSL) should not only be used to verify cookies but also be used for certificate hostname checking. Libraries as GnuTLS should offer an API for this kind of checking, best would be having the PSL as a separate file, maintained by the distribution maintainers (or the user, if he wants to to it). The SSL library should load/unload the PSL under the applications control. that sounds really fiddly to me -- you want the application to know why the TLS stack needs to know about the public suffix list, and to be able to control it appropriately? I think we need good sensible defaults, and a locally-cached, frequently-updated copy of the public suffix list; then if we really really want the application to be able to control the use of an alternate suffix list we can provide an API for that, but i can't imagine we'd want to require the application to specify anything (even asking the application to load the default local PSL seems like too much to expect from most apps that just want to layer in some TLS). Maybe it would be a good idea to provide a separate PSL library that could be used by SSL libraries for hostname checking and HTTP(S) clients for cookie verification. I maintain publicsuffix in debian, and i try to help on the gnutls side of things too (both upstream and a little bit of kibbitzing about the debian packaging). debian has php, python, perl, and haskell bindings for the public suffix list, but i don't think anyone has packaged a C library for it. I've got discussion in my mailbox that i haven't processed in ages with Florian Sager about packaging regdom-libs [0], though, and the library looks like it's been revived a bit since i gave up on it last [1]. Do you think this C interface would be a useful one or would you expect a different API? [0] http://www.dkim-reputation.org/regdom-libs/ [1] https://bugs.debian.org/683881 If of any interest, there is already some LGPLed code at https://github.com/rockdaboot/mget/blob/master/libmget/cookie.c There are also some unit test routines in the project. hm, do you know if the libmget folks are willing to break that code out separately? linking to all of libmget doesn't sound like a good idea, and it would be a shame to have to maintain separate copies of this codebase. --dkg signature.asc Description: OpenPGP digital signature
[Bug-wget] wget with sms api help
I have an account with smsglobal, they have sms http api as so: http://www.smsglobal.com/http-api/ If I use a browser like so: http://www.smsglobal.com/http-api.php?action=sendsmsuser=mynamepassword=mypasswordfrom=myselfto=targetcellphonetext=Hello%20world browser says: OK: 0; Sent queued message ID: e506.28 SMSGlobalMsgID:64.80337 and, I receive an sms OK on cellphone if I try wget with same url, I get[1]: do I need to escape strings...? how ? downloaded file has like: # cat http-api.php?action=sendsms ERROR: Missing parameter: user ERROR: Missing parameter: password ERROR: Missing parameter: from ERROR: Missing parameter: to [1] # wget http://www.smsglobal.com/http-api.php?action=sendsmsuser=mynamepassword=mypasswordfrom=mysekfto=targetcellphonetext=Hello%20world [1] 18942 [2] 18943 [3] 18944 [4] 18945 [2] Doneuser=myname [3]- Donepassword=mypassworde from=myself # --2014-03-19 10:56:39-- http://www.smsglobal.com/http-api.php?action=sendsms Resolving www.smsglobal.com... 203.89.193.162 Connecting to www.smsglobal.com|203.89.193.162|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 130 [text/html] Saving to: `http-api.php?action=sendsms.1' 100%[==] 130 --.-K/s in 0s 2014-03-19 10:56:39 (8.76 MB/s) - `http-api.php?action=sendsms.1' saved [130/130] (then I hit 'cr' ot propmt doesn't come back) [1]- Donewget http://www.smsglobal.com/http-api.php?action=sendsms [4]+ Doneto=mycellphone
