Strange, I wonder why mine does not work. If you open the Developer Tools in the browser and look in the Network tab and refresh the page, what url is it using to fetch the ui-gauge-classic umd.js file?
https://myserver.snake-color.ts.net/flow_editor/resources/@colinl/node-red-dashboard-2-ui-gauge-classic/ui-gauge-classic.umd.js
I see what is happening. Note that the url includes flow_editor when fetching the gauge js file.
If I set httpAdminRoot to /flow_editor as I think you have done and, taking the proxy out of the equation, access the dashboard locally at http://<IP>:1880/dashboard and look in the developer tools then I see that it is fetching the umd.js file from http://<IP>:1880/flow_editor/resources/@colinl/node-red-dashboard-2-ui-gauge-classic/ui-gauge-classic.umd.js. Note that it is using httAdminRoot. If I now access it through the proxy then it tries to fetch it from https://xxx.tailxxxx.ts.net/flow_editor/resources/@colinl/node-red-dashboard-2-ui-gauge-classic/ui-gauge-classic.umd.js. But I have not proxied /flow_editor so it does not find it.
If I don't set httpAdminRoot and go to http://<IP>:1880/dashboard then the file is fetched from http://<IP>:1880/resources/@colinl/node-red-dashboard-2-ui-gauge-classic/ui-gauge-classic.umd.js, but again, since I have not proxied / to / it does not work. In fact if I do proxy / to / then it does work.
You have proxied /flow_editor so for you does work.
I feel that the umd.js file be fetched from a /dashboard relative location rather then httpAdminRoot to avoid this problem.
1 Like
Didn't we see that problem previously? Surely anything for any user-facing resource should not come from the admin instance of Express? If it does, then a node-red instance with a protected Editor endpoint would fail to deliver the resource wouldn't it?
There are several issues registered which I have linked to (or referenced from) in the issue I linked earlier. Including apparently Docker related issues which I suspect also stem from this issue, though I have not seen it specifically related to a protected editor endpoint. It is only an issue with third party nodes, which are not that much used yet.
Sorry @Colin I am a bit late at your party...
Very nice to see that you started using Tailscale!!
Yes indeed PWA is a nice example that requires https.
I have a couple of other ones:
- I use web push notifications to my Android phone via my node-red-dashboard-2-ui-web-push node, which requires a service worker js background job to be installed in your browser. But you can both only install service workers and push web notifications in a browser, when using https with a trusted CA (like e.g. LetsEncrypt).
- Some web APIs, such as those for accessing geolocation, the camera, or the microphone, require the page to be served over HTTPS with a valid certificate.
So therefore I now put the web interfaces of all my local applications behind my Tailscale reverse proxy with https and LetsEncrypt certificates. Then I am rid of all those troubles related to http or https with self-signed certificates...
I have added the extra use cases to the tutorial.
Thanks to your tutorial it was very simple to install and get going. So far the only thing I don't like about it is the fact that it opens up the complete machine to anyone that managed to gets into one of my devices, and from there potentially has access to my complete home network. That is true of any VPN like system though.
Yes indeed. That is a TODO (see here) for the tutorial. All traffic arrives on your machine via the wireguard port 41641 where your Tailscale agent is listening, and forwarding (via its reverse proxy) the requests to all other ports of your machine). So in fact I "think" that only port 41641 needs to be accessible from outside your machine, but all other ports should only be accessible from localhost (i.e. from your Tailscale agent running on the same machine).
As I am sure you know, it is not necessary to open any ports on the router, as it will always allow response ports in.
The point I was making is broader than that. As an example, if you have enabled the ssh server in a pi (or your pc) for access within the local network (so not accessible from outside as port 22 is not forwarded by the router) then once tailscale is connected, any device on that tailnet will be able to ssh to the pi as, efffectively, your local network is expanded to include all the devices on the tailnet.
1 Like
And, as previously mentioned, this is the potential risk of ALL VPN solutions. They are only as secure as the weakest link. So if you have a device in a less secure location, such as a laptop that might be left in a hotel room or a mobile device, that is likely to be your most vulnerable device.
Obviously, actual risk is rather trickier to assess and each individual needs to do that for themselves.
I suppose it's important to act quickly if you suspect a device security has been compromised, by logging into the Tailscale account, and removing that device from your tailnet ASAP.
1 Like
Yes, and in practice for the average 'home' user it probably isn't an issue anyway. The person getting access would need to know what to do to access the network, whereas most lost or stolen laptops are just going to end up being sold on. The time it would be an issue is if you were being targeted by someone who knew what they are doing, which is not likely to happen to hobbyists.
Though it might if you also have a professional role "of interest" or indeed if you were to travel to certain countries and have been critical on social media. Or just coming from "The West" might also bring you under scrutiny in some countries.
It gets complex. Which is why I tend to clear down any mobile device I might take across country borders. And also why I don't use or advocate VPN's. 
Though of course, my roles and knowledge do make me rather more paranoid than average. 
If your concern is mostly about ssh, there might be two things interesting for you:
- Management of ssh by tailscale (see here).
- The Tailscale web ssh console (see here). Which is an online ssh console in your browser, based on WebAssembly.
I did not have time yet to read about it, so not sure whether it can solve any of your concerns unfortunately.
Well our community has unfortunately learned the hard way (not long ago) that we can be targetted by hackers. And I don't claim at all that our Tailscale setup is secure enough, especially since we don't have the time to digg deep enough into this. But we have at least some level of security, and we did at least as much as our free time and knowledge allows us to do. Only future will tell us whether it was enough or not...
My concern is not specifically about ssh, that was just an example of how the network is fully accessible if anyone can access a device connected to the tailnet. As far as I can see, the links posted do not stop access to your ssh server (if you have one), they are an additional way of using ssh. But as I said, I am not unduly concerned, just pointing out that it is not a panacea, you still have to be careful.
Indeed.
I think that it is probably pretty good and better than most people would have been able to do on their own. I know you've had to go through quite a number of head-scratching sessions to get to where you are and the effort is very much appreciated by all.
But Colin's point is well made I think. No security solution is a "magic bullet" and security vulnerabilities aren't static either.
If you take a device into the big-bad-world, you have immediately magnified your risks. This might be minimal for most cases, but in some cases it would be very large indeed. Best that people are aware.
Also, if you set up your "secure" environment and then don't keep it updated, one day there is a strong chance that you will find that it is no longer secure at all.
The best advice for most people doing home automation is still - don't expose it to the outside world! And where you need some outside control, keep it as hands-off as possible. For example, using a Telegram bot. Also keep it as minimal as possible, e.g. Don't expose the Editor - EVER! And if you want to provide remote control of your heating or the precious plants in your greenhouse, provide explicit controls with strong limits.
Indeed, perhaps I should add that last paragraph to the start of the security FAQ?
I've updated the internet security FAQ with a slight expansion of the paragraph.
1 Like
Is using Telegram or others really a 100% secure recipe? Who knows what could be hiding there inside? I'm using it myself to send information OUT from my system to my mobile but I know some are using it also to send commands IN to their systems. Regardless, how can I be sure that installed sw inside my protective wall does behave and doesn't jeopardize my privacy?
If I ever would need a UI to be accessible from outside (read Internet) I would consider putting that in a cloud and feed it with relevant mirrored data via a public MQTT server, never directly from the system I have running on my local network and never allowing commands to be sent into my system! I would instead try to overcome by improving my local automation to handle the "new" use case(s)
But really, as soon as you introduce some (not fully known) sw in your local network, how can you be sure? How can you be sure Nodes you are adding to your flow doesn't contain some malicious stuff. Maybe not visible in the javascript or html code but in the dependencies it is dragging in or when it is building the specific version fitting your platform?
Maybe everything is fine in current running versions but you tend to update from time to time I assume?
No such thing as 100% secure. So no, Telegram isn't. But using a polling bot is a plus. Then you are far more likely to create a LIMITED interface and to fully validate any inputs - which can be further restricted using defined commands, etc.
This is totally different to, for example, a web page which is likely to be more open, certainly has a more open protocol and therefore more open to security issues. Further more, a web page is a direct connection (albeit possibly via a proxy), a bot is not.
Your first line of defence with a bot is what channels does the bot interact with. This covers both inbound and out. You can lock it down to specific channels or individuals.
For incoming via the bot. Try to create defined commands for inputs where you can. That further restricts what input will be processed. Then make sure that any parameters are each validated. Each should have a min/max length and ideally only allow restricted inputs. e.g. only allow 10-25ā for temperature inputs. Or only allow certain keywords for text inputs.
This all adds to your "defence in depth" which is a key principal of secure by design. Using a bot automatically gives you some additional depth.
It isn't that you can't get that depth with a web page, you can. However, it is much harder to get it right and to maintain it securely when using web.
A fairly sound principal. However, using a cloud server introduces further complexity to your security. More layers that could potentially be compromised and so more that you should be monitoring. A common approach for example is to regularly push the code and configuration as well as the data from a more secure location to the less secure. Thereby limiting any exposure.
There are 2 methods for the Telegram bots. The more secure one being polling. Your bot (running on Node-RED) polls OUT to the Telegram server, no firewall holes needed. No way for a compromised Telegram service to do anything other than make available a rogue message. Which you will be validating with a Node-RED flow anyway. That is just data. The server application is entirely under your control alone.
On my own system, I can remotely turn on or off lights or query whether specific lights are on or off. Then I also get pinged if something goes offline unexpectedly. There is no sensitive data involved and the commands are very tightly locked down.
So risks are absolutely minimal (but of course, not zero).
There is, of course, always a risk that your supply chain (3rd-party node.js library in this case) is compromised. There is also the risk that Telegram itself might be compromised - but, taking into account what I said above, this is not going to be a real issue unless you have allowed sensitive data out or allowed unchecked commands in. It would become an issue if you were actively being targeted at home. So I wouldn't suggest this approach for the head of the Ukraine secret services! But for most of us, it is such a tiny risk, it can be ignored.
Indeed. Generally, not doing so is a far bigger risk. But I also keep an eye on what npm tells me when installing updates - It has excellent security intelligence built in these days.
Again though, I've restricted the processing to really only DATA, the node-red node is already fairly tightly constrained and the data processing is MY flow, not someone elses.
If you really want to start worrying, think about the number of libraries involved with Dashboard (either version) - many of which are running in the browser context and so far more likely to be compromisable.
1 Like
