An item I have had on my check list for a while is getting my outward facing device setup with HTTPS. I access my Octoprint from work / on the road using android apps or port forwarding through my router. This works great.
By default, however, HTTPS does not appear to be required or enabled. I looked up a few guides on how to get this done, and managed to successfully get this to occur on my local network. After following the guide, I have broken my external access. Although I can connect via HTTPS on my local network, I can no longer connect to either HTTP or HTTPS externally like I used to.
This is certainly my fault. That being said, this seems like it would be very natural to have some means of HTTPS setup as a wizard in Octoprint rather than me fumbling around an OS i'm not familiar with following a guide that may or may not be best practice.
What are the chances we could get HTTPS setup as part of a wizard for Octoprint?
HTTPs is not something that is in OctoPrint's control really. The underlying Python webserver doesn't support it, as most don't, because they are designed to be run behind a reverse proxy for handling traffic better. Because OctoPrint has no knowledge of the reverse proxy setup it can't control it.
On OctoPi, the OS image it bundles haproxy. Enabling https by default here would not work either, as you would require a certificate, and those certificates need a stable domain name which we can't control before the image gets to users either.
Edit: to add - please say you have better security for your port forwarding than just https. That's not security, that's connection encryption and if someone wants to access your sever then they will be able to do so. You need actual security with extra authentication before you get to OctoPrint, and if you can't do that then use a remote access plugin which is much safer.
Just to add to the already very good points, OctoPi actually DOES ship with https enabled on said haproxy, with a self-signed certificate for octopi.local, which will give you a certificate warning in every browser, but will actually encrypt the traffic.
You can of course throw a proper cert on the image, but as already pointed out, you really should best not even expose OctoPrint publicly without an additional layer of authentication in front, better yet a VPN. Something with heaters capable of starting a fire or at least melting plastic on it simply has no place on the public internet, regardless whether it has built-in user authentication or not.
Thanks for the reply. I have a DDNS setup to assist with name resolution. I wouldn't be supplying a static IP (I would need to pay my ISP more for that). I use my DDNS for a handful of apps with optional web facing services and have done so for a decade at this point.
It works great.
As for security: I personally take a very "cavalier" approach to the topic. I do not concern myself with magical ideas of people prying around. It is likely not happening. I find the simple act of obfuscation is enough.
I once had a web facing server located at port 8080 (I had left it at default). This port is not uncommon for many such services and was picked at more than few times. I noted the shutdown action had taken place (which occurs when more than 3 attempts were made unsuccessfully). This occurred 3 times before I moved port to a random number. It hasn't happened in 6 years since that period.
This idea that there are people snooping around open ports is simply not representative of what is actually happening. Those attempting 99999 times out of 100000 are trying known ports for known softwares. It isn't enough to have an open port, you need to know what's on the other side to exploit it. I am exceedingly confident if anyone came barking up my tree, they would be searching for "known" items and once that failed would simply move on.
It's the locked-car situation. Thieves are looking for unlocked cars. If your car is locked, they generally simply move on. You aren't worth it.
I understand this will likely draw more than a passing comment from you, based on your edit, but I think you are dramatically overstating the risk.
I know the likelihood of changing your mind is zero, but I do want to mention:
it's not just likely that people are prying around, it's a fact. I've personally learned this lesson the hard way a few times because I had the same attitude, though luckily not in a case that could cause actual physical damage.
People are saying not to do this because, yes, there really are people out there looking for systems to compromise, but not because they are looking for specific exploits. The damage is done for 'fun' and 'because its there.'
The irony in your 'thieves looking for unlocked cars' analogy is that the risk here is from an opportunistic person that finds an open port and decides to dig into it and see what havoc can be wrought. And you are the one providing that opportunity.
edit: sticking to your car thieves analogy, your argument sounds like: "I don't need to lock my car because I park it in the side yard"
@SiX - listen to what @TTalkington said. It's trivially simple to set up a scanner to find IPs that are vulnerable to known exploits, especially on known ports. You personally may not need to worry about targeted attacks, but may inadvertently become part of an automated one with that mindset.
The attacks are real and the costs are tangible. Lax security turns personal computers into botnet participants, and we should all do our part to limit that as both users and developers.