Please don't forget however that you must configure Node-RED to require TLS security (HTTPS). Without that, adding these methods is pointless.
Probably many folk using Node-Red on the Pi, like me, know nothing about HTTPS. I have run TotallyInformation's script but I get errors, warnings and instructions that I just don't understand.
Oh, and that script worryingly says
Primarily for using with SSL/TLS to secure communications between local servers and clients NOT ON THE INTERNET!
My prose on the matter was intentionally direct because of this simple reason. Web security is hard to get right and hard to keep right. It is correspondingly easy to make a mistake that undoes your good work.
The example of adding an id/password but then not using TLS is a good example. Without TLS, the id/password is transmitted in clear text - hence the first quote you give.
Another example is securing the main web interfaces (there are 2, the admin interface and the Dashboard - if you are using it) but then forgetting to also secure the websocket connections.
This is not simple and I'm reluctant to try and write a beginners guide as I am concerned that people will attempt to follow it without understanding the risks and issues.
For these reasons, I generally strongly suggest that people without good knowledge of these things don't expose Node-RED to the Internet at all. Instead use an alternative interface that has decent security baked in. Such as Telegram.
In regard to my script for generating valid TLS certificates, if you are getting errors, please raise an issue on GitHub. It has been a long time since I looked at it and it is likely that some parameters have changed in the underlying tools.
The reason I say that it is best for local connections is that it generates a self-signed certificate chain. Trying to remove browser or server warnings with such certificates is, itself, somewhat involved. My recommendation there is to use a firewall to prevent all access to your server except from Cloudflare. Then use the free Clouflare TLS service to front the TLS connection. Putting everything through CF will also protect you from some other Internet based attacks as well.
I did not mean to suggest that you especially should write such a guide TotallyInformation, it's just that the page linked to in the big blue banner at the top of every page in turn refers to your script.
I have heard of Telegram and Cloudflare but I don't know anything about them.
Do they provide an easy and safe way to make a web page from Node-Red?
I understand that Node-Red was not originally intended for the web, yet it has a browser based UI and the dashboard nodes (including a web server?) are simple additions. It's easy to assemble useful code without expertise in a programming language. It seems inevitable that beginners will use it to explore the Internet of Things.
Except when it comes to the Internet - I shouldn't try to go there because I have never been there before? You could say the same thing about New York.
I have seen the warnings generated by self signed certificates. I feel that's a problem to consider once I have my first https page running, not a show stopper.
I know the internet is an unfriendly environment. I have experimented by opening port 22 and waited 3 minutes till the first malicious login attempt. I have learned how to secure ssh with strong passwords, key exchange, non standard port numbers and fail2ban.
I really would like to learn about TLS / HTTPS too.
It would be cool if the friendly and easy to learn Node-Red offered a friendly and easy to learn path to making my dashboard securely accessible from the internet.
As a beginner I am reluctant to post an issue on GitHub. It's much more likely to be something I did or didn't do than a bug. But I don't mind posting in a forum, maybe you can say if this should be raised as an issue?
req: Error on line 12 of config file "./ssl.cnf"
unable to find 'distinguished_name' in config
problems making Certificate Request
1996137888:error:0E06D06A:configuration file routines:NCONF_get_string:no conf or environment variable:../crypto/conf/conf_lib.c:272:
Signing the server request with your Root CA, creates the actual server cert
x509: Cannot open input file tmp/csr.pem, No such file or directory
@jbudd If I could add my support. This is a recurring issue for novices and newbies and I have spent many hours researching and working on learning some of the options. The recent cryto mining script was a warning that Node Red is gettting more well known. It would be helpful to get some advice on the most likely direction that would provide an reasonably effective solution. There has been mention of Passport.js ? Will it be necessary to only use Node Red at the backend and not use the excellent Dashboard?. Would appreciate comments from all the geniuses here:grinning:
Telegram is a secure messaging service. Like Facebook messenger but without the issues that being part of Facebook brings. One of it's benefits is that it is easy(ish) to write a "bot" using Node-RED. That lets you send and receive information between NR and Telegram. It lets you create commands and conversational interfaces and receive back information. Certainly not a website but something that works well on mobile as well as desktop and Telegram takes care of the security, you don't need to open Node-RED nor your Pi (or other platform) to the Internet. The node on Node-RED reaches out to the Telegram API service - over TLS of course - and so doesn't open up a hole into your local network.
Cloudflare is a set of services - many free - that take up some of the load from your own website(s). Over time, they have also introduced a number of additional security services. Bottom line is that, by forcing all access to your website (or Node-RED in this case) via the Cloudflare services, you greatly reduce the ability for people to attack you.
Just like NY, you are absolutely free to go there! I'll not stop you, I wouldn't dream of it. However, just like NY, I would advise you not to go to certain places. Go to the wrong place in NY and the best you could hope for would be to come back without your wallet. All I am saying is that you need to treat the Internet in the same way you would treat going to a new city that has a reputation for bad people wondering the streets (sorry NY, I'm not implying that of New Yorkers especially. I've been there and very much enjoyed it.). Think of Johannesburg or SĂŁo Paulo. I've been to Jo'burg too and while it was interesting, it was a seriously scary place.
OK, good start.
Excellent, now we can see where you are up to in your journey. And you already have some skills you will need in order to protect your system.
That's fine. We've covered the dangers. Lets cover two more concepts: Authentication and Authorisation. Sorry if you already get this distinction but it helps to frame the remaining issues.
SSL/TLS is mostly about creating an encrypted link between one system and another. At it's simplest, it doesn't really help with either authentication nor authorisation. Typically, you have an inherent trust of a servers certificate because it is signed by someone else who is also trusted. That's why self-signed certificates are marked as "untrusted" by browsers. This annoys me actually since self-signed certs, when done correctly, can be a lot more trusted than publicly signed ones (something for another day).
Once we have a reasonably trusted, encrypted, channel, we can now begin the process of authentication. Actually TLS does have extensions for this but I'll leave that to you to discover or this post will exceed the 32k limit! Node-RED does, of course, have a very simple set of mechanisms to authenticate users. This is all in the docs. NR has very little in the way of authorisation however - as yet. So if you need to have more nuanced authorisation, you will need to engineer that yourself.
Now, one of the remaining issues may be that, while you have security in place for the web interfaces (using HTTPS now instead of HTTP, and using basic authentication), there is another really important channel used by Node-RED. That is "websockets". This is where things get a bit cloudy and perhaps Nick or Dave will be able to add more clarity since I've not looked in detail at what additional security has been put in place recently.
Certainly in the past, while changing Node-RED to use TLS meant that the websocket connections were also upgraded to be encrypted, the authentication mechanism wasn't extended to websockets. So in theory, it would be possible to intercept the websocket traffic and even insert your own. I say "in theory" since it isn't especially easy and, while Node-RED was relatively narrowly used, the risk was small (tiny really). As we've seen recently though, that risk profile has changed somewhat.
Websockets are used for the "realtime" communications between the browser and Node-RED - it saves you having to reload the browser page to get updates. In practice with Node-RED, that means that much of the important traffic is going over websockets.
To try and wrap this up, there is one more issue I need to mention. This applies more to commercial use of Node-RED but still has an impact to everyone. That is that Node-RED has never been (as far as I'm aware) security vetted. I believe that some organisations may have done penetration testing on specific implementations but the core itself hasn't been reviewed for security issues. Now, that would be relatively expensive of course so is not something easily done. However, I mention this because even if any of us put together what we think is secure, experience tells (I should mention that I am head of Technology & Information Security for a large UK public sector organisation) that there are always edge cases that only professional red teams and security analysts will discover.
Will all that matter to you if you are just turning on and off a few lights in your house? Nope, absolutely not.
Will it matter if you later extend that to control your heating, some security, people presence detection and so on? Well, all I'll say is that it matters to me. You, of course, will make your own risk judgement.
Cloudflare can help a little here. They have the resources to secure their infrastructure and services. Using their certificate service gives you well managed certificates and you can simply continue to use a self-signed cert (since only Cloudflare will direct access it). They also now have an authentication and authorisation service. I've not had a chance to try it yet but it might well help.
Anyway, I'm sticking with Telegram for now, it's enough for me. If you want to get NR up over the internet, there are other secure options depending on your needs, these are outlined in the article. If you want to give access purely over the internet, I'll just say that I would recommend doing it with a test system first and build in some external checks so that you pick up any of the unauthorised change issues we've recently seen.
Please don't worry about that. Raising an issue costs nothing and I get alerted so I can do something with it. Not all issues turn out to be actual issues but every bit of feedback is helpful.
I'm going to suggest, because these posts are long enough already, that you go ahead and raise the issue, we can link it in here in case anyone is following the conversation.
Passport is a middleware for ExpressJS. ExpressJS is used by Node-RED to provide the web servers. ExpressJS is the most common web server framework used with Node.JS.
So Passport adds many different choices to help authors add authentication and authorisation to their application.
If you look at the settings.js file for NR, you will see that there is a placeholder to insert middleware. You could use Passport there. You may also see that newer versions of NR also have a second placeholder to add middleware to the websocket connections. So this would let you add authentication and authorisation to the socket connections as well.
If you are thinking about my uibuilder node, it is worth mentioning that I built those middleware placeholders into uibuilder too. Though I'm not sure how much they've been tried out in anger.
If you have adminAuth set, then any editor websocket connection must go through an application-level exchange to prove it has a valid authentication token before any application data is allowed to flow.
I'm starting again with a clean SD card and documenting what I do. I'll post on GitHub when I get to that point.
If you don't mind, I'm going to write down everything a novice (me!) might want to be able to do, and the steps I take to get a working Pi ready for this stuff. I'll try and keep it short!
I've taken some Sunday afternoon time to start an article. Not sure when it will get finished but feel free to use the comments to make sure I include the things you want to see.
Sorry, had to break for family time. So I've only now seen this - absolutely, this is how open source gets improved. The more people who take part, the better it is for everyone.
The only reason I've added an article to my blog is that it means I can easily update it without having to worry about other people's style, pull requests and thinking about where it would otherwise best go. Happy to pull my post if there is something better or include parts of something you write if you are happy to have it on my blog. Or something else entirely - could be an official documentation update perhaps. Whatever is best for everyone.
Hi @TotallyInformation, I became interested in this discussion after assuming I could just secure Node-RED with a username and password, restrict it to HTTPS only and create a cert, then publish the page through the firewall. After reading this page (I believe you wrote this too) about how to secure Node-RED, it basically scared me off quick smart. I know this page is a year old now, but the way I read it, because of the section on web sockets, I can't just secure it by HTTPS and use NR's built-in authentication. At least not without quite a bit of effort and future maintenance.
I'm starting to build-up an automation system based around Node-RED, including using only the Node-RED dashboard which I find to be extremely flexible in the way I can make it work for me. I prefer it to all the "purpose-built" interfaces in openHAB, Home Assistant, and more. And one of the basic things I'd like to do is expose this dashboard online so I can e.g. turn the heating down or the music off when I'm away.
So my question is this. Why would one go to all the bother of using Telegram, Cloudfare, or securing it yourself, when you could surely just set up a VPN connection to home and work as if you're within your home network?
(Of course, my question is relating only to my personal use - and that of my family - of Node-RED as a home system, I'm aware it can be so much more.)
I guess I'm interested in exactly why you might use Telegram, e.g. for your own use scenario. And those of others here.
It strikes me that I can do away with all the stress and bother of keeping things perfectly up-to-date by simply not exposing any of it, and using a VPN with a Siri Shortcut on the iPhone for reasonably quick access to the home system whilst away.
That is not correct. If you enable adminAuth and HTTPS, the websocket the editor uses will use a secure socket and will get authenticated. If that's what you are worried about, then you shouldn't be.
If you want to use websocket in your flows, then you do need to think about how to authenticate the connections at the application level.
My Cloudflare TLS certificate is valid until 2031, should I start worrying any time soon?
Expiration
Note that by default, newly generated certificates are valid for 15 years. If you wish to generate shorter-lived certificates (e.g., as short as 7 days), you should use the API or CLI tools provided.
The point is to be a bit shocked into thinking. So you've made it past the first bonus point. Next point is not to be scared but rather to keep thinking things through and assessing the risks.
Yup, that's right. And thanks to the work of Nick and Dave mainly with the help of others now, things have moved forwards. To begin with, adding TLS just added TLS to all the interfaces including websockets. But now we have some authentication available on the websockets too as Nick has said.
Well, the initial effort is a bit, for sure. Mainly related to head scratching to make sure the right things are secured. Maintenance though isn't too bad actually. Once you've set up the basics, maintenance is pretty easy.
The main maintenance is to make sure you are renewing certificates properly. Thankfully, if you can get Let's Encrypt set up properly, this also becomes pretty easy now. I've a blog post mainly written about setting up Let's Encrypt in what I think is probably about the easiest way. I'll be posting that, hopefully this week and the results are nice. I've set up a Pi with a wildcard certificate (so it can be used for any subdomain without needing additional certificates) and without having to expose anything from your local network to the Internet (if you don't want to). LE certificates have to be renewed every 90d so automation is key and that is taken care of thanks to a 3rd-party script.
I will post to Discourse when the blog is updated so stay tuned.
Yup, me too. I've tried some other HA tools but always ended up fighting them more than they helped. I guess I always have to have things my own way. Node-RED gives me the total flexibility without having to spend many hours slaving over obscure JavaScript code.
Really good question. And the truth is - you don't need to bother at all if you don't want to.
However, there are advantages. Firstly, you don't have to worry about a VPN or other client. With a VPN or other tunnel, you need a client. This makes it OK, sometimes, for use on a PC/Mac but not always so good on a mobile/tablet. And it's a faff. Turning on a VPN effectively isolates you from the network you were on and this is not always convenient.
On the other hand, using Telegram, for example, you can always be connected without things interfering with your existing configuration. And Telegram is available on pretty much every platform including all mobiles.
Then you mention family. Again, Telegram is a tool that your family can use for messaging as well so that it can be a single and familiar interface. Both for family communication and then extended to integrate your home. Treating your home as an extension of the "family" using either/both a command interface and a conversational interface.
So anyone can use a command in Telegram to do /lights hall on to turn on the hall light. Or /heating living 20 to turn the living room temperature to 20 deg. These are pretty easy examples to set up with a simple Telegram bot written in Node-RED. The communications are well secured by default and we don't need to expose ourselves to the Internet as we are making a direct, outward connection to the Telegram infrastructure, borrowing from their tried and trusted security model. Which is good enough to get them kicked out of their home country of Russia!
Yup, that is indeed the point of all this.
And this is most certainly a practical alternative - but not very family friendly. Does it pass the "significant other test"? If that doesn't matter, then sure, go ahead and you have a relatively easy to set up and pretty secure connection back into your local network which lets you do more than just Node-RED things.
Just remember that VPN's and similar configurations are not cure-all's. If your PC is compromised, attackers potentially now have access to your home network again. Probably not that big a risk if you keep your PC patched and secured but certainly more than zero. A PC with a VPN or similar tunnel solution presents a bigger attack surface area than Telegram.
You, of course, will need to assess the risks and the ease of use for whoever you need to give access to.
Hope that this makes sense and puts things into perspective for you. Whatever though, the main thing is to have fun while staying safe (and keeping others safe).
Personally, I like having my house "chatting" to me, telling me what's going on, I like being kept informed. My wife, on the other hand, just wants the simplest possible interface to our smart home. She doesn't want the chatter on her phone. So, I'll never just have a single interface. But for me, the Telegram bot is great for the house telling me what is going on and the occasional command sent back when I'm on the go. But while in the house and connected to the WiFI, a simple dashboard interface is generally more convenient for all. So I have a web page with all of the switch statuses for example and that lets us see the switch status and turn on/off switches all on a single page. Other pages show environmental details (temperature, humidity, weather). More detailed pages show the heating status. Soon, I should have some simpler heating controls than the app that our Draytek Wiser heating system gives us.
Haha! As long as you prevent any access from the Internet except via Cloudflare, you are good for external access. But how about internal? With a Let's Encrypt certificate you can also keep communications encrypted within your LAN as well as externally. Watch out for my soon to be posted blog post for some setup instructions.
I don't think that is necessarily correct. There can be an issue if your home network uses the common subnet of 192.168.1.nnn and the network you are on also uses that subnet as the VPN client doesn't know where to send packets to. However if you change your local subnet to use a non-standard range, 192.168.31.xxx or something then it should be ok. At least that is my experience.
When you create a VPN connection from a device on a local network to your remote network, you have a choice. You either isolate the device from its local network in order to place it on your remote network. Or you bridge the two networks.
Bridging a local network to a remote one is certainly possible but generally discouraged unless you have permission from both network owners and have considered the possible differences in security levels. I'll admit that I assumed the situation I most commonly come across - being on a corporate network and wanting to connect to my home network. If I bridged the networks, even if I could, I would end up in a lot of trouble. It should also go without saying that bridging a coffee shop WiFi network to your home would also open you to a world of pain.
There are alternatives to VPN's that will create application level connections rather than device level. Those wouldn't necessarily isolate you from your local network for other applications nor at the device level. However, it is not always possible to make such connections from corporate or WiFi networks as the ports - and sometimes the traffic patterns - may be blocked.
I would like to write such a guide it is true.
