search

guysoft / OctoPi

Scripts to build OctoPi, a Raspberry PI distro for controlling 3D printers over the web
GNU General Public License v3.0
2.45k stars 368 forks source link

Redirect to SSL if not enabled #684

Closed AJRepo closed 3 years ago

AJRepo commented 3 years ago

Since both 80 and 443 are enabled, one should redirect to port 443 if a request comes in on port 80.

guysoft commented 3 years ago

@foosel Do we want to do that?

I know some users have browsers with really bad ssl errors that make them not use HTTPS

AJRepo commented 3 years ago

Some reasons for making it the default are:

foosel commented 3 years ago

As long as browsers show you big red scary warnings on self signed certificates on local addresses which will severely confuse the less tech literate majority of users or there, I see this severely increasing the support overhead which I frankly would like to avoid. Telling people to comment out a line in a config file they can only access through SSH will overwhelm them. Having to own a domain and making auto renewal of a letsencrypt setup somehow work for their supposed to be internal only OctoPi instance will overwhelm them. Teaching them to just click accept on big red scary messages in their browser is a bad idea.

HTTPS on LAN is not thought through for the not so tech savvy end user. Browser vendors completely ignore that whole scenario and make it impossible for self installed stuff like octopi to find a sensible solution that is secure but compatible to people who do not know what a certificate even is.

See also https://mobile.twitter.com/foosel/status/1022030752349913088

foosel commented 3 years ago

The only way I could see this working without people trying to murder us as a consequence is not a redirect but rather an explanatory landing page explaining that HTTPS is available, what to expect (FAQ link and probably a video because people don't like to read), and a way to still access stuff via http on a separate link.

That won't solve the "teaching people to ignore warnings is bad" problem but I don't have any other ideas how to solve this, given how browsers are making this harder and harder. Just redirecting definitely is not the answer.

PS: my phone's autocorrect hates me today

AJRepo commented 3 years ago

OK. I'll delete the pull request.

AJRepo commented 3 years ago

I saw your comment https://github.com/guysoft/OctoPi/pull/684#issuecomment-711413184 right after I closed the pull request.

I'm ok with you not wanting to make that change. It's easy for me to enforce SSL on my own. I have a printer with other users so SSL is a requirement for me.

I'll just make a comment in regards to the "users would be confused" comment and valid certs behind a firewall.

I help at a makerspace that has printers managed by OctoPrint and so can comment about non-technical users vs OctoPrint and encryption.

About a year ago I used a stock Pi install with a separately installed OctoPrint and a package-installed (apt install) HA-Proxy. Since the network is wireless and users are using actual username/passwords, it was important that the traffic be encrypted.

What I found was that just denying access to port 80 was confusing to users (it's not working!). Having a landing page that says "you should use the https encrypted page instead" was aggravating to users. Having a landing page with a 5 second delay and then automatically forwarding was confusing/aggravating to users (couldn't use the back button). Having a behind-the-scenes redirect that takes people directly to the SSL page with the "this is a self-signed cert" was what the final solution I came to as best because I have no rights to the DNS for the makerspace. I think mostly it's because people do not read anymore. They don't read warnings, they don't read buttons, they just click away.

In reply to your twitter comment/question about letsencrypt for private devices.

When I have access to the DNS, I've done valid certs to private servers/services many many times.

Browsers on the local DHCP network usually go to the local DHCP/DNS server first and so get told the local 192.168.1.X address even if the global IP also exists. That means you can have the same name (e.g. myoctopi.example.org) for a global and internal DNS name that differs in what IP is resolved for machines outside and inside the network.

If the DNS provider doesn't have a good API (e.g. godaddy ) then a method I like is to setup a global DNS entry, local router DNS entry, and a NAT to the HAProxy server on a non-privileged port (e.g. 8890) which is only live/used by certbot for requests/renewals.

So, simple DNS entries might look like Local: myoctopi.example.org = 192.168.1.111 Global: myoctopi.example.org = Real.global.IP.address NAT: Real.global.IP.address:8890 -> 192.168.1.111:8890

Then call sudo certbot certonly --standalone -d myoctopi.example.org --non-interactive --agree-tos --email certbot@example.org --http-01-port=8890 --preferred-challenges=http

and cert renewals will happen automatically from cron.

If you have Dynamic DNS then you can set the Global IP using something like DynDNS or have certbot script update DNS programmatically at cert renewal time.

If you have a DNS provider with a good API (e.g. dreamhost) Certbot DNS validation can check DNS entries instead of hitting the actual server so you can get a valid cert with no publicly accessible machine or needing NAT.

One could build such scripts into OctoPi to generate valid, signed certs on installation.

This could perhaps even be the basis of a paid subscription model for OctoPi where in exchange for a paid subscription users get signed certificates generated on installation. Just use the DNS api and no firewall modification is needed to get a valid cert. Once the subscription ends, certificates would no longer be renewed.

Since we're already way off-ticket/topic I'll stop there., but there's lots more steps one can take to make it even more automated/manageable.

Thanks for all you do with OctoPi, I had an SD card go wonky and found your repo as a very good and clean install. Very similar to my own install an appreciated it rather than re-doing the HaProxy/RasPi/OctoPrint setup.

foosel commented 3 years ago

What I found was that just denying access to port 80 was confusing to users (it's not working!). Having a landing page that says "you should use the https encrypted page instead" was aggravating to users. Having a landing page with a 5 second delay and then automatically forwarding was confusing/aggravating to users (couldn't use the back button). Having a behind-the-scenes redirect that takes people directly to the SSL page with the "this is a self-signed cert" was what the final solution I came to as best because I have no rights to the DNS for the makerspace. I think mostly it's because people do not read anymore. They don't read warnings, they don't read buttons, they just click away.

That is really disheartening I gotta say, but sadly not surprising given my own observations.

One could build such scripts into OctoPi to generate valid, signed certs on installation.

This could perhaps even be the basis of a paid subscription model for OctoPi where in exchange for a paid subscription users get signed certificates generated on installation. Just use the DNS api and no firewall modification is needed to get a valid cert. Once the subscription ends, certificates would no longer be renewed.

The biggest problem with all that is that not everyone has a domain, not everyone wants a domain, not everyone should need a domain. And providing all that as a service with the myriad of possible router/DNS and LAN setups out there would be more of a headache than implementing the DNS rebinding attack approach that plex runs. Still unobtainable with the limited resources we have (read: me as a full time dev on OctoPrint who can occasionally justify some work on OctoPi too and a couple of volunteer hours here and there from whoever can and wants to afford that), that would be a dedicated high support overhead project on its own :/