OPENSSL_config deprecation warning

[Jeffrey Walton]

Hi Everyone,

I'm building Wget 1.20.3 from the source tarball against OpenSSL 1.1.1d.

I'm catching a warning that looks like low hanging fruit:

gcc -DHAVE_CONFIG_H
-DSYSTEM_WGETRC=\"/home/jwalton/tmp/build-test/etc/wgetrc\"
-DLOCALEDIR=\"/home/jwalton/tmp/build-test/share/locale\" -I.
-I../lib -I../lib -I/home/jwalton/tmp/build-test/include -DNDEBUG
-I/home/jwalton/tmp/build-test/include
-I/home/jwalton/tmp/build-test/include
-I/home/jwalton/tmp/build-test/include
-I/home/jwalton/tmp/build-test/include -DNDEBUG -g2 -O2 -march=native
-fPIC -pthread -MT version.o -MD -MP -MF .deps/version.Tpo -c -o
version.o version.c
openssl.c: In function 'ssl_init':
openssl.c:178:7: warning: 'OPENSSL_config' is deprecated
[-Wdeprecated-declarations]
   OPENSSL_config (NULL);
   ^~

I believe the call to OPENSSL_config can be guarded:

#include 
...

#if OPENSSL_VERSION_NUMBER < 0x10001000L
OPENSSL_config(NULL);
#else
OPENSSL_init_crypto(OPENSSL_INIT_LOAD_CONFIG |
OPENSSL_INIT_ADD_ALL_CIPHERS |
OPENSSL_INIT_ADD_ALL_DIGESTS);
#endif

Jeff

[bug #35122] --auth-no-challenge should not be required to send Basic auth over SSL

[Sergey Ponomarev]

Follow-up Comment #1, bug #35122 (project wget):

I proposed to remove the Auth challenge at all in the
https://savannah.gnu.org/bugs/index.php?57686 

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[bug #57686] Basic Auth: make auth-no-challenge mode by default

[Sergey Ponomarev]

URL:
  

 Summary: Basic Auth: make auth-no-challenge mode by default
 Project: GNU Wget
Submitted by: stokito
Submitted on: Tue 28 Jan 2020 05:32:29 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Originator Name: 
Originator Email: 
 Open/Closed: Open
 Discussion Lock: Any
 Release: trunk
Operating System: None
 Reproducibility: Every Time
   Fixed Release: None
 Planned Release: None
  Regression: None
   Work Required: None
  Patch Included: None

___

Details:

I didn't find anywhere what was a motivation of developers to introduce the
Basic Auth challenge mechanism was introduced except of that "it imitates the
web browser experience". My only guess is that this is needed to allow to
server to set some cookie but I'm pretty sure that that wasn't a real case.

I would like to ask you to reconsider this because in fact it makes almost no
sense for security reason but create an additional network load instead and
confusion for users who got an error.

The only documentation about that descibes the Auth challenge mode is:

> ‘--auth-no-challenge’
>  If this option is given, Wget will send Basic HTTP authentication
information (plaintext username and password) for all requests, just like Wget
1.10.2 and prior did by default.
> Use of this option is not recommended, and is intended only to support some
few obscure servers, which never send HTTP authentication challenges, but
accept unsolicited auth info, say, in addition to form-based authentication.

So let's think about the attack vector and how the auth challenge flow
protects us.
1. If the original sever stopped to ask for auth this may happens because of
few reasons:
  * the API is not protected anymore and become public (low possibility). In
this case it's ok show credentials because the just not needed anymore.
  * the API endpoint was moved somewhere else (version change) or it was
removed at all. In this case it's also fine to send credentials but wget will
receive 404 or 302 error.

In both cases an attacker can get an access to server's access logs and see
the Authorization header with credentials but in any case if the  the original
server was written correctly will not show the Authorization header in logs.
But if the API is really requires credentials then the same situation.


2. If the original server gone (it's domain expired, service closed etc.) and
now there is some another server with the same URL then there is two
possibility:
 * The new server with the same URL belongs to an attacker: then it will just
imitate the API and ask for the Basic Auth as previous service did and send
WWW-Realm header. So the auth challenge won't help in this case.
 * The new service is non frauding then they just receive the Authorization
header but they won't do anything with it.
In both cases credentials are leaked to someone else but anyway the original
server is not exists anymore so there is not a big deal. Except of if your
password is the same on other sites but here nobody can help you.

3. An attacker sitting on a wire (MITM). The HTTPS protects from this. But
even for HTTP an attacker will see your credentials on successful API call. In
case if the call wasn't successful this means that original server gone as I
described in situation 2.

So, in fact the Auth challenge doesn't protect credentials in any case. Then
why to do this?

The problem is that "some few obscure servers" are in fact not so few and one
of them is for example GitHub OAuth server. I can't retrieve user info from GH
OAuth because it doesn't sends the realm on first request.
So I lost some time of my life trying to figure out what was wrong. You may
found in internet forums that there is a lot of people who faced the similar
issue.
Another issue is that this violates Postel's law: "be conservative in what you
do, be liberal in what you accept from others".
But what is even more important is that this creates an additional load to
client, network and servers and gives absolutely nothing.
For example I wanted to call the GitHub's API from embedded device which is
very slow and with limited resources and bad connectivity over wifi. And I was
unpleasantly surprised that in fact all my API calls are made two times: one
for the challtnge and another a real useful call.

Please disable the Auth challenge mode or even remove it from wget. I'm pretty
sure that nobody will miss it.





___

Reply to this item at:

  

___