SSL support

[jonnor]

Needed when connecting WebSocket from a website served over HTTPs, and is generally preferred when the process is accessible over untrusted network or the internet.

There was a PR here, which unfortunately got invalidated by a refactor: #11

[psvensson]

As a newcomer to noflo, this gave me some problems yesterday as I installed everything on my node.js server according to the getting started guide, and the server did show up in the flowhub.io dashboard, but trying to use that runtime results in an unspecific error. After looking at the console I realize that the browser tries to connect from a secured (by ssl) page to an unsecure (the node.js runtime ws:// endpoint) and you're not allowed to do that.

Adding ssl support is not that hard, especially with letsencrypt (https://letsencrypt.org/), but it does require you to have a specific domain name that the certificate should be valid for, so it's not point and shoot like a http service.

To begin with, I'd recommend to add some notes in the readme or as part of the output that you need to load the flowhub page in http mode, otherwise things just don't work. Adding a sensible error message to flowhub itself would also help.

I'll see if I can find some time to add some kind of ssl support this week, so I don't just whine about it :)

[jonnor]

Can one get some sort of certificate for localhost, the most typical case when doing local development?

[jonnor]

Seems like there may be issues with self-signed certificates and WebSockets (no way to accept/add them): https://bugzilla.mozilla.org/show_bug.cgi?id=594502
But http://www.chovy.com/web-development/self-signed-certs-with-secure-websockets-in-node-js/ suggest that in Chrome at least, going to the https::// page of the same thing will prompt a dialog for the certificate, allowing to accept it and will then be used also for WebSocket protocol..

[psvensson]

Right! I always use WS as a second step after loading a page which have some ws-client inside it, so I've never seen that on Firefox.

So localhost might work, but wouldn't it be possible to make noflo-nodejs outgoing instead, and use flohub as a proxy between runtimes, so that the ws logic in the flohub page client logic always connects to the flohub server and that in turn proxies the messages to/from the runtimes? Maybe too complicated, but would definitely solve the problem.

[psvensson]

I'll try to add the letsencrypt node.js package to a fork of noflo-nodejs and see how it goes;
https://github.com/Daplie/node-letsencrypt

My idea is that if one has letsencrypt installed and have generated certificates with it (which is a one-liner) then it would be great to be able to refer to them and have them used to open a wss:// service that can be connected to from the flowhub dashboard.

[jonnor]

I really really don't want to make the noflo-nodejs WebSocket outgoing. That breaks all offline development, decentralized deployments, and makes Flowhub API a man-in-the-middle for all runtime connection - and that data there contains basically everything that goes on in an app - including all private things.
Better then to use WebRTC. There is NoFlo support for browser, but node.js is currently lacking, see noflo/noflo-runtime-webrtc#1

[jonnor]

Idea of using letsencrypt sounds fine to me. Proper trusted certificates always better than self-signed, and it seems they have some easy tools and momentum.

[psvensson]

OK, I hear you (re: outgoing ws), I know too little of the system as of yet.
But it looks like adding wss should doable. I don't have more time today, but if one already have used the letsencrypt command-line tool to generate a certificate, the files can then be used pretty much as any other certificate, so that in noflo-weboskcet-runtime I think it would be possible to just create an options object to refer to the pem-files and create a https server from them, as described here;

https://community.letsencrypt.org/t/node-js-configuration/5175

I'll do a hardcoded try as soon as I can.

[psvensson]

TO create certs, use for example the following;

sudo letsencrypt certonly
--agree-tos --email john.doe@example.com
--webroot --webroot-path /srv/www/example.com
--config-dir /etc/letsencrypt
--domains example.com,www.example.com
--server https://acme-staging.api.letsencrypt.org/directory

As described here; https://github.com/Daplie/letsencrypt-cli

If someone has more time and want to try it out.

[jonnor]

Tried getting a cert with them now. It requires that the domain has DNS entry to points the right IP already, and that the machine running letsencrypt is on this IP and is publically available. While these restrictions make sense for the service they provide, it makes it very inconvenient to use for developer/laptop setups.
For instance I did not manage to complete it now, as I've forgotten the router password to set up required port forwarding. And my VPS is temporarily down...

So maybe its better to just add commandline options to specify certificate file, and document a couple of options for getting the certificate? Letsencrypt can be one, self-signed can be another.

[psvensson]

Yes, well. This is the way certificates work and is not something unique to letsencrypt, sadly. The whole point with a certificate is to certify that this endpoint is this or that domain and that you have control over it, so that not someone else has maliciously hijacked it.

It's a clear example of my old idea that usefulness and security are two ends of a spectrum where you pay for one of them when you gain the other - no exceptions :)

Actually letsencrypt is probably to easiest way to date to get certificates for a domain you own and control, but it really is a bother when developing.

But just having an option when starting noflo-nodejs to refer to an existing directory with certificate files would be great - if you have already a certificate for a public server you would want to deploy to, using flohub. Then if the hubs docs (and getting started guide) just stress that you must use flowhub through http:// if you have not set up ssl with a proper certificate, that would probably be sufficient for now to not have people tripping. I'll find some more time in 16 hours or so.

[psvensson]

After a number of false starts, I think I've managed to get something working. However, I know too little of noflo and its ecosystem and protocols to be sure.

In the following clone git@github.com:psvensson/noflo-nodejs.git I've made changes to noflo-nodejs-init to take a --cert property, which then points out the letsencrypt/etc/live catalog (or possibly any other catalog with a directory with the same name as the domain you have certificates for, which then should include the files 'cert.pem chain.pem fullchain.pem privkey.pem'.

I realize this is a bit too hardcoded on letsencrypt and what's needed is a more general https strategy. I hope to implement that in the future.

When starting no-nodejs, adding (as you suggested on twitter) the --host flag will be necessary to enforce the domain that you have in the cert, otherwise the (possibly private) IP address of your server will be served to the flohub service.

I have managed to start a secure websocket version of noflo-nodejs on my server running on Google Compute Engine under a specific domain name, which I have certificates for, and when opening flohub with https://app.flohub.io, I could see the runtime registered as wss://..

I was then able to select the runtime and the familiar grphical flow UI appeared. It looks like things are running, but trying to get something to show in the console does not work, but as I said - I'm quite new to noflo and I may have done the wrong thing.

Please try out the clone and see if it works for someone who knows what they're doing! :)

[rhalff]

@psvensson I've tried your fork and got it working using the certificates from https://github.com/Daplie/localhost.daplie.com-certificates

Of course this can all be setup more strictly, but your fork and those certificates allow for a quick https setup to try out the nodejs runtime.

mkdir noflo-test && cd $_
npm init -y
npm i noflo noflo-core noflo-nodejs  --save
npm i localhost.daplie.com-certificates --save-dev
mkdir graphs
echo "Read(filesystem/ReadFile) OUT -> IN Display(core/Output)" > graphs/ShowContents.fbp
node node_modules/.bin/noflo-nodejs-init
DEBUG=* ./node_modules/.bin/noflo-nodejs \
  --graph graphs/ShowContents.fbp \
  --host localhost.daplie.com \
  --certs ./node_modules/localhost.daplie.com-certificates

Note: https://localhost.daplie.com just points to localhost but is a valid certificate.

$ ping localhost.daplie.com
PING localhost.daplie.com (127.0.0.1) 56(84) bytes of data.
64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.039 ms
64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.038 ms

[psvensson]

OK, great that it works, but yes it is a bit of a hack. I think it would
probably be better to just point out the name of the respective certificate
files used so it's not so tied to letsencrypt. Also I should look into some
kind of https wrapper, like one does with apache and nginx, to let them
terminate the https connection and then route to stuff happily behind. Hmm

On Fri, Apr 15, 2016 at 12:28 AM, Rob Halff notifications@github.com
wrote:

@psvensson https://github.com/psvensson I've tried your fork and got it
working using the certificates from
https://github.com/Daplie/localhost.daplie.com-certificates

Of course this can all be setup more strictly, but your fork and those
certificates allow for a quick https setup to try out the nodejs runtime.

mkdir noflo-test && cd $_npm init -ynpm i noflo noflo-core noflo-nodejs --savenpm i localhost.daplie.com-certificates --save-devmkdir graphsecho "Read(filesystem/ReadFile) OUT -> IN Display(core/Output)" > graphs/ShowContents.fbpnode node_modules/.bin/noflo-nodejs-initDEBUG=* ./node_modules/.bin/noflo-nodejs
--graph graphs/ShowContents.fbp
--host localhost.daplie.com
--certs ./node_modules/localhost.daplie.com-certificates

Note: https://localhost.daplie.com just points to localhost but is a
valid certificate.

$ ping localhost.daplie.comPING localhost.daplie.com (127.0.0.1) 56(84) bytes of data.64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.039 ms64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.038 ms

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#54 (comment)

Peter Svensson, Lead developer, Evothings (https://evothings.com)

http://se.linkedin.com/in/petersvensson (LinkedIn)
https://plus.google.com/u/0/109826099655556298824
https://plus.google.com/u/0/109826099655556298824/posts (Google+)
http://twitter.com/psvensson (@psvensson)

[bergie]

Via #142