I'm hoping this has already been done and someone can just point me off in the right direction
I'd like to create a webserver in NodeRED but all I want it to do is listen out on port 443 for an client computer making an HTTPS request and let me see what url was asked for so I can take some action depending on what url used in the client computer
but I need NodeRED to do a handshake so that the client doesn't cling to the port waiting for a timeout
I'm fairly ignorant when it comes to http stuff but I hope this is doable
(I'm trying to get Scratch3 talking to NodeRED which can then control Pi GPIO pins)
Urm, you can easily change the port in settings.js, I use:
// the tcp port that the Node-RED web server is listening on
uiPort: process.env.PORT || 1880,
as that lets you override the default using an environment variable but you can just set it to 443 as long as nothing else on the device is using that port. Of course, what you really want is for Node-RED to use HTTPS on the default port 443. That requires a couple of additional settings to configure the certificates and keys. But that would be true for any other web server too, including Python.
You also have several other options, especially if working on Linux:
Configure your OS firewall for port forwarding - so that incoming requests to port 443 are translated to port 1880. Plenty of Google help for that.
Use a reverse proxy to forward requests. Any of the major web servers will do this, my favourite is NGINX. HAproxy could be used instead.
My preference is to use NGINX to terminate your HTTPS requests and forward them over HTTP to port 1880. This lets you leverage the development effort put into securing NGINX without having to think about Node-RED security so much. NGINX will also be smart about retaining/releasing user connections.
This was just an attempt to get an HTTPS server running quickly on 443. At many points in the process, I found I was just getting deeper and deeper down a rabbit hole - so I gave up - I'm easily put off
Turned out to be one of those things that was just easier to do with a little bit of Python.
(It was just to listen out to HTTPS requests to localhost from Scratch3)
I know what you mean. If you are familiar with Node.JS, this is at least as easy as doing it using Python, I've done both. Node.JS was specifically designed for that kind of thing. I no longer use Python unless I have to since it is a little easier for me to keep the number of languages down and only use JavaScript.
However, let me reiterate that getting HTTPS correctly secured is harder than it looks at first sight. Also easy to mess up as it has a number of very serious flaws that can be hard to mitigate. When exposing Home Automation systems to the Internet, this can have very real-world and unfortunate consequences. That's why I only use Telegram as the interface between the outside world and my Node-RED HA system.
You might also want to look at the free services that Cloudflare offer. It is quite easy to expose a web interface (over HTTPS) to only Cloudflare and then let Cloudflare take care of securing the HTTPS interface to the rest of the world. Indeed, they now offer some simple user authentication/authorisation services too that you can easily add to any web interface - you don't have to do any coding at all. Well worth looking at and is on my list of things to do. I already use their TLS proxy for my own websites. They also filter out many known attacks.
Yes, I get that Simon. What I guess I'm pointing out is that, where the Internet is concerned, those quick solutions are dangerous. Very dangerous actually.
Whilst they are a little extra work to set up initially, some of the things I've outlined give lots of additional security for minimal effort.
@TotallyInformation Slightly off-topic, but have you looked at the VNC client and server access (RealVNC) that is distributed (free, last time I looked) with the Raspberry Pi? I've used it a few times to do remote maintenance on my HA system, and I wonder how it compares in terms of security with the recommendations you make in your wiki article.
Yes, but again you need to be careful to secure it properly. Also, since you are running a full desktop, it takes quite a heavy toll on older Pi's and the responsiveness can be low depending on network quality.
Personally, I never run a desktop on the Pi. However, i am now running WEBMIN on my Pi 3. This is a brilliant web interface for managing Linux servers. One of the things it will do is auto-update installed applications. It's a bit resource heavy for my older Pi2 which is also running too much other stuff though. I will be migrating at some point.
@TotallyInformation, all I have done to configure the VNC is follow the developer's instructions, so I'm not sure if there is anything else I should be doing. It seemed like a good way to avoid fussing with firewalls, dynamic DNS, certificates, etc.
Obviously, the GUI is a performance hit, and I wouldn't want to do real development with it over VNC. Still, I like having a desktop available, even on the machines that run headless. I tend to distribute work over multiple machines to avoid having a single failure take down multiple services, so I have never had a throughput issue (within reason) with a Pi3.
Thanks for the tip on WEBMIN. It certainly seems capable of things I didn't know I wanted to do. I'll be checking it out.
Realised just now that you were talking about using RealVNC. In that specific case, it does have some reasonable security though you are recommended to set up 2-factor authentication.
Yes, it is really good. I've used it for years on various shared and virtual private servers. Strongly recommend using the "Authentic" theme as it has lots of very good features. Also strongly recommend using 2FA if exposing to the Internet.
