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!