[uss_qualifier] netrid: DSS0020 - check DSS endpoints are encrypted

[Shastick]

This new scenario checks that port 80 of a DSS's base URL either:

• refuses connections
• answers with a redirect to the https base url

The scenario also checks that the https port is available to receive requests. Currently there is no check to enforce a minimal cipher strength.

Note: this scenario requires a DSS configured with an https:// base url, meaning that locally and in CI, it will be skipped.

Part of the effort on #754

[mickmis]

I don't think it is valid to fail the requirement by calling a GET on the base URL. It is not specified in the OpenAPI so even if something is served as HTTP here, that would not be invalid.
Alternatively, attempt to do a valid query (e.g. search for some ISAs) by forcing HTTP and not following redirects: if that succeeds, we can for sure fail the requirement because an endpoint got served over HTTP.

[Shastick]

For background, the requirement states:

Communication between a USS and DSS instances shall (DSS0020) be encrypted using an industry-standard encryption mechanism with a minimum encryption strength of 128 bits.

Here I interpret that anything else than a redirection is a form of communication, and that if it happens over HTTP, then the requirement is failed. Hence a query to any endpoint is fair game.

I also agree that issuing a query that we would expect would succeed over https would make sense, and we can probably simply do both. Would it make sense to you if I add it separately? (and with doing two requests instead of one we already reduce the chances of running into a spurious timeout)

[Shastick]

It should also be noted that DSS0020 has nothing to do with the OpenAPI Spec (it does not mention it).

[mickmis]

Hence a query to any endpoint is fair game.

My point was that the raw base URL is actually not an endpoint. It's a prefix to the endpoints.
Depending on how the infra around the DSS is deployed, the request might not even reach at all the DSS, e.g. if you have an ingress/RP that will forward calls only for specific paths. In that case it could be responding through HTTP and I'd see no failure of the requirement.

[mickmis]

IIUC this if the parent exception of all exceptions from requests. If so it does not appear valid to interpret that as passing the test: a network timeout or DNS issue due to unrelated reasons could be interpreted as a successful test.

[Shastick]

I agree that this might be a little bit too wide and I can narrow things down to cover time-outs and explicit connection refusals.

Regarding the specific points you noted, however:

• a timeout may occur even if we narrow down to catching timeouts or refused connections
• permanent DNS issues would cause the whole test suite to fail, so this check passing would not carry much weight?

I'm not sure we can reasonably cover the situation where we get a false positive due to a time-out?

We could attempt multiple connections, but we still won't cover situations where routing was consistently broken for a short while.

[Shastick]

Now specifically looking for errno.ECONNREFUSED and errno.ETIMEDOUT

[mickmis]

Same remark as above: this is not specified in OpenAPI so we should not rely on it to succeed/fail tests.

[Shastick]

The way I see it, is that the OpenAPI spec defines an application protocol, and that here we are testing something about the transport layer.

At the level we are testing we don't really care about what happens at the application level: we're expecting the socket to open successfully and that's it.

Ie, requirement DSS0020 has nothing to do with the OpenAPI spec, and if something is broken with the HTTP protocol while the secure socket is fine, then a whole load of other requirements will fail?

[mickmis]

I've reworked the scenario to simplify it after the discussions regarding hitting an endpoint or not.
Since it cannot run in the CI, I tested it locally by hard-coding URLs http://github.com and https//github.com in the python scenario, and it behaves as expected.