http-proxy fails with: Assertion failed at proxy.c:250 (strlen(p->up.username) > 0)

[simu]

Hi,
http-proxy seems NOT to cache username/password anymore. When it first connects, it is asking for username/password to management-console and successfully connects with this credentials. But when openvpn-client re-connects, it fails with: Assertion failed at proxy.c:250 (strlen(p->up.username) > 0) and the logging does not show that it was asking for username/password again. For me it seems that the client thinks he has still his username/password cached (maybe a flag somewhere) but the memory of username and password is already deleted.
My setup is working fine on Version 2.3.18, so there must be a change in http-proxy between 2.3.18 and 2.4.x (I also tested it with 2.4.3, 2.4.4, 2.4.5, same failure)
thanks
Simu

[tct]

See log here:
​https://forums.openvpn.net/viewtopic.php?f=4&t=28359

[BhenChod]

spam

[Gert Döring]

could this be related to the client-side auth-token changes?

[Gert Döring]

This needs re-testing with 2.4.10 and 2.5.1 and either closing or fixing.

@simu: what does this need? A windows machine with --http-proxy in its config and a http proxy that asks for HTTP auth?

[Eriol]

I have the same exact problem (version 2.4.x and 2.5.1) with the same exact logfile:

Client starts the connection and first tries to connect to the proxy server. As soon as the TCP connection is successful it sends the username/password and manages to connect to the proxy.

After that it tries to connect to the OpenVPN server but it gets a SIGUSR1[soft,connection-reset] from the OpenVPN server without any further explanation about the reason of the reset.

The client naturally wants to reconnect:
It tries to connect to the proxy server again but after the successful TCP connection it does not sends the username/password but tries to connect to the OpenVPN server right away (at least based on the client's logfile).
This action fails with:

MANAGEMENT: Client disconnected
Assertion failed at proxy.c:250 (strlen(p->up.username) > 0

Also I found that the reason of the initial OpenVPN server reset is that the server's CRL has expired. It would be great to get at least description about the reset reason to the client from the server to know where to start digging at the first place.

[simu]

@Gert Döring
Yes, that is exact my testcase. A http-proxy in between of the VPN server and the VPN-Client. The VPN-Client is a windows machine using the flag --http-proxy and the http-proxy in between.
As Eriol stated, this happens only when the client reconnects.

[Antonio Quartulli]

Hi all, we are trying to reproduce this bug using OpenVPN 2.5.1 on Windows with GUI.
We have a proxy server requiring authentication between us and the OpenVPN server.
However, when reconnecting we are always re-asked for username and password.

Any hint as to what might be needed to see the issue?

Maybe any of you could share the exact client config (and command line arguments) used to launch the client?

[Selva Nair]

While I too cannot reproduce username = NULL error in 2.5.1 reported here, there is an issue with caching of proxy credentials. As per the docs its always cached and should not get prompted again during reconnect. And that used to be the case pre 2.5.1. It appears there was regression that broke caching.

On SIGUSR1 and SIGHUP restart we always call http_proxy_new() and there we have a call to get_user_pass_http() with force = true. The latter is defined in proxy.c as

static void
get_user_pass_http(struct http_proxy_info *p, const bool force)
{
    /*
     * in case of forced (re)load, make sure the static storage is set as
     * undefined, otherwise get_user_pass() won't try to load any credential
     */
    if (force)
    {
        clear_user_pass_http();
    }
    if (!static_proxy_user_pass.defined)
    {
        ...
        get_user_pass(&static_proxy_user_pass, ....)
        ...
    }

so the user gets queried on restart instead of using the cached value. Looks like this has been so for ever, but with a subtle difference: the latter part used to be

if (!static_proxy_user_pass.defined || force)
{
    ...
    get_user_pass(&static_proxy_user_pass, ....)
    ...
}

Though get_user_pass() gets called in both cases, the latter is essentially a no-op if the cached static_proxy_user_pass buffer is pre-filled.

Commit 86b58ceb29 (with good intentions) decided to change the meaning of "force" as to clear the cache. Actually the original purpose of that "force" appears to be just to get p->queried_creds and p->up set on initialization.

if its required to support credential change when proxy IP changes, we need to do it without breaking caching. However, multiple proxies with different credentials in the same config file feels like a strange use case.

[Antonio Quartulli]

@selva does it mean this is a different bug compared to what was pointed out in this ticket? I am just trying to wrap my head around the actual issue, and I'd like to decouple them if there is more than one.