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.
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.
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
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!
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()
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.
We have an HL7 connectathon happening this weekend, and I was re-running the National Care Directory against Inferno, the federal HealthIT testing platform:
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.
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?
