riseupvpn: https://api.black.riseup.net:9001/json: connection_refused

[bassosimone]

Describe the bug

Running ./miniooni -n riseupvpn I see in the output:

[      4.243393] <info> [  4.0%] riseupvpn: measure https://api.black.riseup.net:9001/json: connection_refused

which in turn leads to this JSON result:

{
    "api_failure": "connection_refused",
    "api_status": "blocked",
    "ca_cert_status": true,
    "failing_gateways": null,
    "transport_status": {
      "obfs4": "ok",
      "openvpn": "ok"
    }
}

By looking at this result, one would conclude that the API is blocked, but I'm not sure this is really the case unless RiseupVPN has now been blocked in Italy for my ISP (Vodafone Italia SpA).

To Reproduce

Just run ./miniooni -n riseupvpn or ./ooniprobe run circumvention.

Expected behavior

To define the correct behavior, we need first to confirm that this is an issue with RiseupVPN's API. To this end, I am asking whether one of @cyBerta and @kalikaneko could perhaps help me understand here.

Screenshots

N/A

System information (please complete the following information):

Not relevant.

Additional context

I investigated this issue because I was told by @agrabeli that this issue has been reported to her today.

[sarathms]

I can confirm this is exactly how it appears from my network as well.
From running miniooni

[      2.563231] <info> [  4.0%] riseupvpn: measure https://api.black.riseup.net:9001/json: connection_refused

From the measurement collected by the desktop app on October 17

However, this wasn't the case on October 13

[fortuna]

If you got a connection refused it means the 3-way handshake was never completed and the domain was never sent.
So it can't be SNI-based. Blocking would be either IP-based or perhaps you got the wrong IP from DNS. Or it may just be a server-side failure

[kalikaneko]

it's a reliability issue on the side of the riseupvpn api; there's the question of how to validate cases when the service is down. A CI test is going to be added to at least have a canonical way of checking for interruptions in the service.

[cyBerta]

Expected behavior

To define the correct behavior, we need first to confirm that this is an issue with RiseupVPN's API. To this end, I am asking whether one of @cyBerta and @kalikaneko could perhaps help me understand here.

Currently there's no way do distinction between server side failures and blocking attempts. The result

    "api_failure": "connection_refused",
    "api_status": "blocked",

can be caused by both. In order to reduce the amount of false positives, we might consider excluding the endpoint https://api.black.riseup.net:9001/json for the evaluation of Riseup's backend. (Maybe the failure of that endpoint should cause a warning, not an error).
That endpoint is currently optional to optimize load balancing, but the system works without it as well. Also, server side failures of that endpoint caused false positives in the past iirc.

I'll discuss that with Riseup.

[bassosimone]

@cyBerta wrote:

Maybe the failure of that endpoint should cause a warning, not an error
[...]
Also, server side failures of that endpoint caused false positives in the past iirc.

I agree with emitting a warning and I do remember the same with respect to false positives.

I'll discuss that with Riseup.

Let us know! I think we can quite easily make a failure in calling this API non fatal!

[bassosimone]

I have started adapting riseupvpn to make it more robust. Since ooni/probe-cli#1363 and ooni/probe-cli#1360, the probe does not ever flag riseupvpn as failed, rather we only consider it an experimental test for collecting data useful to riseup (as discussed in ooni/probe-cli#1125 (review)).

Additionally, since ooni/probe-cli#1355, riseupvpn can be conditionally enabled and disabled using the check-in API and the default status is disabled. Which means that we have a mechanism in the probe to make sure we're able to prevent this test from running in case of data quality issues.

The final step to transform riseupvpn into a data-collection only nettest is to modify the scoring logic of the pipeline to be more lax, as I documented in ooni/backend#745.

So, as far as the probe is concerned, this issue is solved. Further improvements will include using richer input to serve input to riseupvpn, which will make it more robust and effective (see #2559).

As such, I feel safe with closing this issue because I did enough work in the probe to mitigate and the rest of the work that is needed is either documented follow up work or backend work.