Security: Disabling TLS 1.0 and 1.1

Hello everyone!
It’s been awhile, but still here and developing on Meteor. So got a question about TLS. I’ve been running some Meteor/Galaxy apps through the federal HealthIT certification testing utilities; and the latest security testing checks for TLS 1.0 and 1.1 vulnerabilities.

A bit of research for anybody interesting why TLS 1.0 and 1.1 are now considered vulnerabilities:

So, okay, we need to disable TLS in Meteor and Galaxy. How do we do that? Digging into stack overflow finds this article:

How to disable tls 1.0 and use only tls 1.1 using nodejs

With this code sample:

const { constants } = require('crypto')
https.createServer({
    secureOptions: constants.SSL_OP_NO_TLSv1 | constants.SSL_OP_NO_TLSv1_1
    pfx: fs.readFileSync(path.resolve(pathToCert))
}, app).listen(443)

So, my question for you fine folks, is the following:

Do we have any options to pass in options to https.createServer via environment variables? Is there a NODE_OPTIONS we can pass in? Or will we need to patch the meteor or webapp packages?

I’m usually working on clinical workflows and business logic, and this is way closer to the metal than I usually work with. So thought I’d reach out in case anybody knows some wizardry to make this happen.

Thanks in advance!

4 Likes

In Galaxy on the Options page under Security there’s the following:

SSL TLS Protocol support:
ALL
Minimum 1.2

If I’m not understanding anything incorrectly (which is always a possibility), this should help you out.

Additional reading here: Container environment | Galaxy Docs

3 Likes

My understanding… NodeJS runs on a OS together or separately w/from its DB or micro-services or other dependencies. Within the VPN, communication runs on port 80 (HTTP). Outside, things rather be TLS-ed with at least 1.2. However clients connect to a router/balancer and not to Node directly. It is true, you can add Mongo via TLS from a 3rd party but rather have it inside the VPN on HTTP.

I added a sketch on how I build my things in Amazon AWS just to support my little “article” with some image. If I am not wrong, Galaxy is built in AWS and this diagrame applies to Galaxy as well.

Looking at this packages, I think TLSing Node not only requires a “proprietary” server created, but also a “proprietary” client to talk to that server on either HTTPS, Socket, SSH, XHR etc. node-tls - npm

1 Like

Opa! I’m blind and/or not scrolling down the settings page enough! D’oh! That being said, after setting the config, am still getting the error. Am starting/stopping servers to see if I can kick it into gear; and going to wait 24 hours in case there’s any sort of nightly cron script or something. But thank you for the links. This is obviously the lead I needed!

1 Like

Hi @awatson1978

We are not blocking these requests on the first proxy layer as we still have applications running on these legacy versions.

We are working on migrating clients that use TLS in version 1.0 and 1.1… so that we can disable this from our first layer which is the proxy.

But if your app is set to Minimum 1.2 in the Galaxy settings, we do block the request before it reaches your app.

There is something I usually send to clients to assure compliance.

If you run this code by passing in your app’s “URL”, you’ll see that requests with TLS below 1.2 will be refused if the Security > “Minimum 1.2” option in your app on Galaxy is enabled.

var https = require('https') 
var options = {
hostname: 'YOUR HOSTNAME WITHOUT HTTPS',
port: 443,
method: 'GET',
secureProtocol: "TLSv1_method"
}
https.request(options, res => {
let body = ''
res.on('data', d => body += d)
res.on('end', () => {
data = JSON.parse(body)
console.log('SSL Version: ' + data.tls_version)
})
}).on('error', err => {
// This gets called if a connection cannot be established.
console.warn(err)
}).end()

Best Regards,

Philippe

1 Like

Hmmm… okay, I’m going to try to talk to the HealthIT.gov folks to see if they can emit a warning instead of an error. Until then, it looks like this is going to prevent Galaxy from passing federal healthcare credentialing until the last of the clients are migrated off of the old versions of TLS. :confused:

1 Like

@alimgafar @fredmaiaarantes

Thanks @storyteller and @awatson1978.
We are going to analyse this carefully and try to drop old TLS versions as soon as possible.

4 Likes

FYI, we (boomlearning.com) have also been dinged in 3rd-party security review b/c of how the old TLS requests are rejected via Galaxy.

1 Like

FYI, I’ve logged a ticket with the Office of the National Coordinator HealthIT, and the team that manages the Inferno testing suite.

We have an HL7 connectathon happening this weekend, and I was re-running the National Care Directory against Inferno, the federal HealthIT testing platform:

OAuth is working well. But as we can see, federal testing servers don’t recognize the TLS 1.0 and 1.1 termination that Galaxy has implemented.

1 Like

Questions:

  • How many Galaxy clients are still using TLS 1.0 and 1.1?
  • What is their volume of users?
  • How critical is TLS 1.0 and 1.1 for them?
  • How critical can their systems be if they’re still relying on TLS 1.0 and 1.1?
  • At what point do we say they are holding back other projects who want to be federally certified and win government contracts?
1 Like

Hello,

We are working on dropping TLS 1.0 and 1.1. We will communicate before dropping it and also give some time to people to update their code accordingly. We are still internally discussing the options for those who will still need to use 1.0 and 1.1.

4 Likes

Hello!
Tis me again. I’ve rolled onto a new project which is (again) fetching data from hospital EHRs, and found myself trying to run Galaxy hosted Meteor app through the HealthIT.gov certification website (again).

I’ve been super excited to follow the End of Support for TLS 1.0 and 1.1 announcement, and the disabling of TLS 1.0 and 1.1 options in the Galaxy user interface. Compared to a year ago, this is big movement! No complaints here. I really appreciate all the work that the Meteor Team is doing behind the scenes.

The above being said, I’m at a healthcare conference, and have been re-running the certification process, and wanted to do a check in. Our app is configured with TLS 1.2:

But certification processes are still identifying the end-to-end connection as being invalid, presumably because TLS 1.0 and 1.1 are still enabled on the docker/amazon load balancer.

Question is: with the older versions of TLS hitting End of Support in May, and the deadline of August 1st now being past… how close are we to disabling TLS 1.0 and 1.1 on the public proxy / docker load balancer / watchyamacallit?

3 Likes

Hello @awatson1978 , how are you?

Some apps still had traces of the old TLS connection and we have made a fix for that.

You can take a new test here: TLS Checker - Instant Results | CDN77.com and test again on the website that sent the screenshots.

Best Regards,

Philippe Oliveira

3 Likes

My dudes!!! You all ROCK!!! :boom:

Hot damn, this calls for a celebration toast this evening! :clinking_glasses:

I know this was a lot of work, and couple years in the making, so… THANK YOU!!!

6 Likes

Amazing work, great quick fix!

3 Likes