Bart, node-red-contrib-letsencrypt has been/is a very reliable node, having used it now for 4 years without a single problem on 3 individual https Node-RED servers.
I've never understood why you haven't published it, as it a great way to obtain https ceritificates, and if used with your node-red-contrib-certificate-grabber node, it makes handling https certificates very easy and automated.
One cloud server, which is a backup server, has been running for the past 3 years without any attention whatsoever, and it's certificates being routinely renewed automatically as they become due.
Morning Paul,
Well at the time being when I was developing this node, I got a message from somebody in this community. Since that guy is busy with security and gdpr, I am not going to share his name. I really think @TotallyInformation would not appreciate being mentioned here 
It was about my node giving the users a false sense of security. And in fact he is right: to be able to access your keypair from a flow is not really good practice, but that is the way is unfortunately. And people using my node might get the idea: oh I have LetsEncrypt certificates, so nobody can beat me anymore. Which is absolutely not the case. So I let my node die in anonymity
On the other hand:
- Now the less technical people have no decent certificates to protect them, since - let's be honest - most other ways are too complex for them. After all those years I am not convinced anymore whether that is better.
- Moreover - let's be honest again - when somebody somehow (malicious node, malicious code, ...) manages to get access to your flow, the last thing to worry about is that they can get/modify your key pair. Of course I am not a security expert, but I don't see why a hacker would be interested in your key pair when he has direct access to anything else...
Anyway I am still convinced that Julian is right that security should not be inside Node-RED but before you access Node-RED. Which means a reverse proxy in front of Node-RED and that does all this stuff for you. But imho Julian is a bit contradictionary here: with a reverse proxy you still give people a false sense of security. They will think: I have a reverse proxy with Letsencrypt certificates, so nobody can beat me anymore. Which is absolutely not the case (although it is better of course...). Let's remember all the hacking cases of last year, where people used port forwarding and bad/no basic authentication. And - let's be honest for the third time - setting up a reverse proxy is no stuff that we can expect from a less technical user. I know that some people in this community think otherwise about that, but from their discussions it looks to me that they do this kind of stuff in their daily jobs 
So at the end of last year, I ditched my port forwarding, since we had enough examples from poor souls that have been hacked. This time I searched for a complete E2E security setup. I did investigate quickly some of those:
- Cloudflare: very powerful but way too complex for people less technical, or people with very limited free time (like me now...).
- Zerotier: really loved its simplicity. However it lacked some of the basic stuff that you need for Node-RED, so I removed it again.
- Tailscale: imho this is the way to go. You get all out of the box, and it is in fact rather easy to use. Although the documentation is not for novice users. So I started writing a step by step tutorial for our users. However I have not published it yet, because their reverse proxy (embedded in their agents) has a bug. I created a Github issue for it, but no response unfortunately. Perhaps it might help if anybody - who is interested in Tailscale - adds a like or comment in that issue.
EDIT: some context... If that issue is solved, I can completely remove my reverse proxy. Then my tailscale agent does enough for a common Node-RED setup: LetsEncrypt certificates for a tailscale subdomain, simple reverse proxy, tunnels (e.g. for Google Assistant), ...
Summarized: although I think I should have published the Letsencrypt node a few years ago on npm, I believe now it is better to help our users to setup something like Tailscale...
Like you english guys say: just my 2 cents. But I am by far a security expert!!!!
EDIT: And - let's be honest again for the last time - even if you have a such an E2E security system, this is still a false sense of security. If you import a malicious node or flow, everything was for nothing. Then you need to take other extra measures...
2 Likes
I find ngrok by far the easiest.
one time ngrok setup: (link)
- install agent
- add your token
one time node-red setup:
- secure it (docs)
exposing your node-red over https
ngrok http 1880
WARNING:
This is super simplified.
I have not included all the other things that EVERYONE should be doing like using a limited service account to run Node-RED, consider disabling exec node, consider disabling palette or using own library source, re-iterating the multiple warnings Bart posted above, etc.
In short, Here be dragons
Awaits Julians telling off
1 Like
@Steve-Mcl,
Does ngrox also offer letsencrypt (or anything else signed by a CA) certificates out of the box?
Not sure I fully understand the question Bart? I think you are asking in context of the thread topic - so I will provide context: "I just wanted to add to your list of alternatives (additional alternative option for users)"
FYI: NGROK simply puts your Node-RED (or web app, flowfuse, other) online with their own fully up-to-date & working HTTPS + certs. There is absolutely nothing for the user to do regarding certs. It is super simple.
Ah ok, yes indeed that was the reason why I didn't use ngrox (after only a very small investigation).
Yes, I fully appreciate you mentioning ngrox here! Should have mentioned that one in my shortlist, because I quickly reviewed it last year. Because lots of people in this community use it, and are pleased with it.
But last year - after all the hacks of Node-RED systems - I wanted to setup a (as good as possible) secure Node-RED system, which hopefully would be a bit understandable even for the less technical users. So I wanted:
- Something that didn't require me to buy some domain name.
- Something that didn't require me to use a dynamic dns provider, because my duckdns was very often not reachable (which caused my Google Assistant to fail).
- Something that offered LetsEncrypt certificates out of the box and renew them.
- Something that even offered me a way to use LetsEncrypt certificates within my LAN (optionally).
- Something that didn't require me to do port forwarding, both for my Android smartphones (to access my dashboard) and also for my endpoints like for my Google Assistant.
- ...
Finally I figured out that Tailscale does all of this out of the box. But there are 2 issues:
- The issue that I registered on Github, which requires me currently to have a Caddy reverse proxy. Which is way too complex for most users.
- The documentation is quite difficult to understand, while Tailscale is in fact very easy to use. That is why I started writing a tutorial with some visual explanation drawings...
If that issue would be solved, I could ditch my Caddy and have a very easy setup that does everything I need out of the box. That would make my node-red-contrib-letsencrypt node completely useles, which I would not mind in this case. That is why I was mentioning Tailscale here.
If one can find your tunnel endpoint they can still access it (security by obscurity), indeed setting up NR security is essential. I believe ngrok is a hotbed for bad actors.
You could add basic auth to the ngrok tunnel;
ngrok http -auth="username:password" 1880
3 Likes
indeed. See step2
and the big warning
That is another way and definitely worth mentioning.
It means the NR user doesnt have to have setup NR auth (something that regularly trips up users). It means internal access is as was (direct access, no password) and external access is behind HTTPS + username, password.
and before anyone says it, no I do not advocate "no password" (looking at you Julian ;))
Apart from "LetsEncrypt certificates"* NGROK does all of that with a single command.
* NGROK may have some way of using LetsEncrypt certificates but I have not investigated (since they provide good working certs with zero config required by me, I dont bother)
PS: NGROK has changed massively in the last year or so.
Domain names have dropped in price over the past few years, for example using the Cloudflare registrar, node-red.uk is currently available for £3.88p for 1 year, and renews thereafter at £3.88p per year.
If users have multiple servers, subdomains can be added at no cost, such as server 1 = home.node-red.uk, server 2 = backup.node-red.uk etc, etc.
The uk or .co.uk extensions are usually the cheapest.
Renewals are done automatically (unless you untick the box) and havng a domain takes away the problems of dynamic dns, google assistant issues, etc.
Now you got my attention
Could you please explain how that works?
How can you access a Node-RED dashboard in a secure way via Ngrox without port forwarding? Do you mean that you have a tunnel available via Ngrox, that leads you to your dashboard? So that anybody else can access the logon screen of your Node-RED dashboard if he has the url? If so I have thought always it was bad practice to allow access from the internet directly to your Node-RED logon page. Because NodeJs/ExpressJs isn't really up to date with security stuff, in contradiction to revers proxies?
Yes correct. But my problem isn't really the price. My problem is the complexity. I am doing a (desperate) attempt to make sure things can continue at home, in case I would ever not be around on this planet anymore. With Tailscale I have a tailscale subdomain, and corresponding certificate. That is it. And that is probably already too complex to explain to them. If I need to explain them that they need to extend a domain name contract each year (and so on ...) that will unfortunately never be understandable for them.
And I know that Cloudflare is a magnificent system, but there is no way on earth that I will be able to explain them how that works. I gave up myself due to lack of time, after watching a few Youtube tutorials... So that is a no go for me.
So the key is for me a simple setup that works out of the box. Which Tailscale is 99% for me, but I need to get rid of my Caddy reverse proxy before I will be able to explain to my sons how it works.
But if Ngrox or Zerotier or Cloudflare or whatever system is good enough for you guys, please keep using it! And if there is no interest for Tailscale in this community, that is also absolutely fine for me! I just wanted to explain why I switched to Tailscale, and why my letsencrypt node will never be published on npm...
Oh dear - I can see Julian is typing.... 
1 Like
Hi Bart, thanks for the shout-out. 
And I don't mind at all. In fact, let me be even clearer here. I see a slightly concerning trend in regard to Node-RED and I think it stems from its incredible power and flexibility. That trend is to assume that just because you can, you should. Node-RED is a general purpose compute environment engineered to be as friendly as possible, something we all appreciate immensely. But in this day-and-age of constant probes and attacks, failure to understand the security and privacy limitations this carries is, in my view, very dangerous. Especially as Node-RED makes its way more and more into commercial and enterprise environments.
But of course, it is all open source and people are always welcome in the community and welcome to contribute. In terms of a node like your letsencrypt node, if you wanted to publish it, I would recommend a headline banner warning of the issues and limitations of handling the private key file this way.
As for being inconsistent in recommending an external reverse proxy, I can't agree really I'm afraid. That is the best approach if you are going to do everything yourself without an external service, something that is preferred by some. However, the external services have greatly improved over the last few years (driven by those same probes and attacks we are all seeing) and I agree - and generally say - these are now an even better approach than your own proxy.
But as with all security, you cannot ignore the use-case. For example, I might recommend your own proxy for security your user-facing pages where you need maximum performance (ability to scale out your infrastructure for example) or need more user identities than sustainable by an external service (managing costs). But I might still recommend only allowing access to the Editor via an external service.
Each approach has its own strengths and weaknesses and there is no such thing as "perfect" security. It is always a balance of risks. Something I sometimes have to point out to our organisations security teams!
As explained, in a sense, all security can give a false sense of safety. Nobody in the modern tech age should assume that everything is "Safe". However, that cannot stop us from moving forward, we have to mitigate as much as possible within our budgets and abilities and assess whether the risks are still worth it.
For the majority of us doing home automation, simply using an external security service and leaving our home networks otherwise inaccessible from the Internet is going to be sufficient.
For someone in a major enterprise or offering services to many customers for profit, this attitude won't cut it. They need to do more if they don't want, at best, to find themselves out of a job, at worst, owing a LOT of money to people.
I believe you are correct. And now that they've fixed their defaults so that you get a more secure connection by default, I'm more comfortable in recommending it.
Haha, no, you've done the right thing by saying that there may be more too it. A lot of security is about getting people to THINK!
Like most of the external services, the base service uses their own shared certificates rather than yours. This makes it even easier because you don't have to think about certificates at all.
Actually, this is something I would recommend everyone to do that wants to share a service over the Internet. It makes life a LOT simpler. And I strongly recommend using Cloudflare for it because they do not add any overhead costs at all and so they are nearly always the cheapest. In addition, they support the latest security standards and have a very straightforward web admin interface. I've used them for years with my various domains. I also recommend using a personal domain for your email as well but that's a different topic
Not always relavent. For example, my web sites are all proxied via Cloudflare which means that if you reach one of my websites, you will be seeing a Cloudflare shared certificate, but you will never know unless you bother to examine it. The advantage being, I never have to worry about it expiring and the Cloudflare proxy provides significant additional protection, a significant reduction in traffic to the actual web servers and some good analytics without having to expose users to horrors such as Google Analytics.
All this for free in my case, as would be the case for the majority of hobby users!
That would be useless I'm afraid since you would be passing data in the clear. This is the way that NGROK used to do things. Their later clients and default configuration uses https by default. Worth re-checking the docs to get the latest configuration.
No password is the right thing to do if you don't mind anyone being able to look at something. That might be exactly what you want/need.
But that would NEVER be the right thing for your Editor endpoint (except in the very limited case where you wanted to give the public access to an example of Node-RED).
Please let's not perpetuate the old NGROK configurations! Use the new ones that are secure by default.
ngrok config add-authtoken <TOKEN>
That's it! The token is, as usual, unique to your account.
Then you do:
ngrok http http://localhost:8080
And although it says http there, it does not actually serve your site over http, it always uses https with their shared certificate. Of course, this gives you a rather random and changing Internet facing URL, something like https://84c5df474.ngrok-free.dev. You can get a fixed address for free but the domain will still be theirs not yours.
If you want a better looking domain, you have to pay. This is where NGROK differs from Cloudflare Zero Trust. There, you can use any domain where you've put the DNS into their system (you don't have to register the domain with them - though, as mentioned, this is a good option). So you can use your own domain with ZT for free.
The downside is that ZT is rather more complex to set up.
Personally, I will ALWAYS be interested in better tooling. And, as mentioned, there is no SINGLE right answer. Options are important.
And I absolutely agree that all of the DIY solutions so far are too complex. Complexity means mistakes and mistakes mean insecurity.
So please do follow up on Tailscale if you can Bart. We all have a part to play when it comes to security.
A late start today but I think I'm caught up now!
Conclusions?
- DIY solutions such as Tailscale, NGINX, etc are complex to set up but can be highly performance tuned. You need some skills and suitable infrastructure.
- NGROK is easy to set up but you have to pay if you want a custom domain.
- Cloudflare Zero Trust, especially combined with their DNS and other services is both comprehensive and excellent value on their free tier (max 50 user ids). But is more complex to initially configure.
And the final conclusion? For everyone's sake, DO NOT, EVER, connect the Node-RED Editor to the Internet without protection from one of the above.
Happy computing everyone
PS: I am an Enterprise Architect with some background in IT Security, I am not a Cyber Security specialist. If you are offering services to people, engage specialists to test its security! And budget for continuing to do that. For our systems, we now require penetration testing annually for example and require vendors to demonstrate their security competences.
4 Likes
Done, however as they have over 2,000 open outstanding issues, I can't see it getting fixed anytime soon.
1 Like
Can you expand on that Bart? What is missing from Zerotier for your use?
I have both Zerotier and Tailscale accounts, I think I use Zerotier just because of it's simplicity.
I know this is covered in "etc" but it might be worth mentioning again that there are other ways than the exec node to execute OS commands.
eg there was a recent thread about executing OS commands from a function node.
1 Like
Because of Node-RED's strengths, there are just so many ways it can be used nefariously I'm afraid. Another example is the discovery that Node-RED can always edit the settings.js file no matter what you do to try and secure it. And yet, that file contains the restriction settings. Of course, you then have to force Node-RED to restart, but that isn't that hard to do.
So it seems that it would be extremely difficult to actually make the Editor "Secure".
In the past, I've recommended that if you want some flows to be kept secure, the appropriate approach would be to have multiple Node-RED instances with different access.
Ok thanks @TotallyInformation!
I had already that approach in my head, because the external services are - like you say generally speaking - maintained by experts, which do follow up of their systems much better than we do ourselves. So thanks for confirming that!!!!
Yes that is my only issue with Tailscale. In my tailscale agent running on my Raspberry, I want to setup 2 paths to my Node-RED system:
- A public tunnel (they call it a funnel) - which their agent secures with LetsEncrypt certificates out of the box - to allow the Google Assistant servers to access my node-red-contrib-googlehome node.
- A private service (they call it a serve) to make my Node-RED flow editor and dashboard available within my LAN for all (e.g. Android) devices running a Tailscale agent. That way I again have LetsEncrypt certificates within my LAN out of the box.
So I don't use a public funnel to access the Node-RED dashboard or flow editor. It is only available to devices within my Tailnet, i.e. devices running a tailscale agent...
Some peoply might wonder why I want to use SSL with LetsEncrypt certificates within my LAN: I need this to access my Node-RED dashboard in order to be able to use e.g. my web push node to push notifications to my smartphone. Chrome only allows my dashboard clients to subscribe my web-push service worker when you are using https with certificates signed by a CA. I don't know if the new PWA (progressive web application) that recently was added to dashboard D2 needs it (because it uses another way to load the service worker).
But currently the Tailscale agents have this bug: when a funnel is created then the local serve becomes public also. And the other way around: if you create a local serve, then the funnel becomes private. So I need a Caddy in between my Tailscale agent to grab - via a Caddy integration they have provided - the LetsEncrypt certificates from the Tailscale agent to use them within my LAN 
. Will send them a reminder.
Thanks @Paul-Reed for the thumbs up in my Github issue!!!
Sorry for letting repeating yourself. But it feels better if somebody like you tells it
Oh it is already some months ago that I tried Zerotiere, and my brain is getting old. I thought that at the time being there were no public tunnels and LetsEncrypt certificates. And that they planned to support that in a next major version, but that I understood from the discussions that this was already planned a long time ago. I have described above in this post why I need those certificates. But perhaps you found a better way to do this with Zerotier?
Yes that is something I learned from you in the past. I had a look at Ngrox also a few months ago. But perhaps I did not look good enough. I thought that it was something like a tunneling service, so that your flow editor or dashboard would need to become public available when you want to use their certificates. But perhaps you can also use Ngrox to secure access to Node-RED with SSL and certficates within your LAN? Which I need as described above...
I'm afraid most of that goes way over my head!
I don't know what "web push" means. As for notifications, I have a shell script that can send SMS messages through my mobile broadband router. No idea how, it's all magic isn't it? 
1 Like
Quick scetch to explain how a setup with Tailscale looks like, and what my issue is. For those interested in the topic, to make it hopefully easier to compare with other solutions:
- I create an account
- I install agents on my Raspberry, Windows portable, Android phones. And add those clients to my tailnet (e.g. with name "mytailnet" which is a private virtual network.
- I setup some optional stuff in my tailnet, e.g. some logical dns hostnames and which traffic I allow between my devices.
- On my Raspberry I tell the agent to setup a secure funnel to port 3001. This becomes a public endpoint on the Tailscale servers, so my Google home can send voice commands to my node-red-conyrib-google-smarthome node.
- On my Raspberry I tell the agent to serve port 1880 within my tailnet. Note that Node-RED has no ssl related stuff anymore: i.e. it works with plain http!
- Now I can simply enter https://mytailnet.ts.net/mydashboard in the browsers on my devices, and there it is, without having to expose my Node-RED on the internet!
- Since I have dashboard over SSL with LetsEncrypt cerificates, i can install my ui-web-push node and the browser allows it to install the node's service worker background process. So my Node-RED flow can now send push notifications to my devices.
The only issue I have (see red arrows), is that the Tailscale agent on my Raspberry does not allow a public funnel and a private serve together. They become both public or both private, depending on which of both you create last
I workaround that now by a Caddy as reverse proxy between my Tailscale agent and Node-RED, to get the Letsencypt certificates from the agenr. Which is completely silly...
That was the least complex security setup I could find, which allows me to do all that I need out of the box...
If anybody sees a problem or improvement in my setup, or knows an easier way that offers all that functionality, please share it!!!
