Opal 5.0-RC3 regression due to increased security of TLS endpoint (?) when using self-signed certs (default)

Thanks for the great improvements and upgrades to the DataSHIELD tech stack, greatly appreciated. I was eager to try it as soon as possible (just after I’d returned from the Bonn conference).

My setting is

Opal 5.0-RC3 using my local (WSL2) Docker compose based setting, 3 * (Opal+Rock+Mongo) containers + 1 client container (dsBase + R).

The (bash+R) script automatically creates nodes, adds data, users, configures everything then runs simple stat analysis to verify if nothing broke since the last release before we consider upgrading our production environment. I’d say this is simple but good enough local specific regression testing of capabilities we use in our prod env.

It used to work perfectly with previous releases and now I encounter an error when a client is trying to establish a connection.

What works: all the Opal APIs are working fine (import data, configure metadata, create projects, users, assign permissions), no regressions detected, works fine as always.

What broke: the client (dsBase 6.3.0, another container in the same docker-compose network) is unable to connect to the Opal server.

Logging into the collaborating servers
Login study1 [=================>-------------------------------------------------------] 25% / 0sError: [Client error: (400) Bad Request] 400

We use default self-signed TLS certificates for Opal endpoints and the use override when creating client connections.
(options = "list(ssl_verifyhost=0, ssl_verifypeer=0)

(It’s acceptable for this kind of local laptop based dev / testing environment without any sensitive data, we want to avoid unnecessary complexity with certbot etc.).

Now it seems not to be possible anymore due to TLS encryption changes.

I investigated more with curl to provide more info about this issue.

Both

curl -k --resolve https://datashield-opal-1:8443

and

curl -k --resolve datashield-opal-1:8443:172.18.0.10 https://datashield-opal-1:8443

Result in

<html>
<head>
<meta http-equiv=“Content-Type” content=“text/html;charset=ISO-8859-1”/>
<title>Error 400 Invalid SNI</title>
</head>
<body>
<h2>HTTP ERROR 400 Invalid SNI</h2>
<table>
<tr><th>URI:</th><td>https://datashield-opal-1:8443/\</td></tr>
<tr><th>STATUS:</th><td>400</td></tr>
<tr><th>MESSAGE:</th><td>Invalid SNI</td></tr>
</table>

</body>
</html>

Is it expected behavior (increased security etc.)?

Is there a known workaround? (Server-side settings for HTTP endpoint would be my guess).

We’d like to keep an option to use self-signed certificates for testing/local dev purposes. Of course, everything that improves security is well welcome for prod environments.
We’re looking for an off/override switch here.

Please advise.

Hi,

Indeed, this is an extra security from TLS that came out of the box with the java/jetty upgrade.

So that the default https works with self-signed certificate, I assume that it cannot be generic anymore and must be created with a specific Common Name (CN), which is the host name from which opal server will be accessed. Given that the HTTPS configuration of Opal is relatively limited, and given also that using a reverse proxy is more flexible and up-to-date in terms of security, I recently created an example of docker compose based deployment, which delegates the https dirty work to Traefik: GitHub - obiba/datashield-deployment: Deployment of OBiBa for DataSHIELD You could give it a try.

The other option is that I could use the Opal setting “productionMode”, and when false (default is true), the SNI host check would be disabled in Jetty.

Regards
Yannick

I assume Jetty is embedded as I cannot see any explicit jetty configuration file anywhere. So now I understand why it would have to be Opal option and then I’d guess you’d change the way Jetty is initialized. (SslContextFactory etc.)

I have not changed anything, it is jetty 12 that has this extra security feature.

Thank you.

I got inspired by initial step of generating custom certificates, but did it differently, with 3 x nginx + custom local CA + establishing trust to this local CA by the client

A bit of work but my local setup / laptop playground is still autonomous (from external services) and works end to end locally once set up.

Happy to report everything works fine, no API changes nor behavioural changes were detected / nothing was affected (there’s configuration code using Opal APIs, there’s analytical code running some analysis). So the only breaking change for me was this increased TLS protection.