SSL Port Forwarding with ACL Video

I've created a port forwarding video to help people hopefully set up port forwarding reasonably securely. The only thing that I didn't go over is how to setup Let's Encrypt with OctoPi, which would require a completely separate video.

I completely understand the discussions concerning VPN vs. Port Forwarding. I do reference the blog post for safely securing your OctoPi/OctoPrint installation as well as Gina's writeup on how to setup haproxy. For those that decide to go with port forwarding, I wanted to provide a way to do it that is reasonably secure. Here's a link to the video:

I would be interested in people's feedback. The link is still unlisted. So, if there are significant issues, this isn't going far and wide.

[Edited: Replaced old video, which was deleted with the new video.]

2 Likes

(I changed the title of your post so that people don't summarily ignore it as bad advice.)

I've reviewed the video and the approach appears to be reasonable.

The advice that I would give would be to always test the assertion that this won't work for a hacker:

  1. Visit http://external-ip/ to verify that HTTP doesn't route in from 80 externally
  2. Visit https://external-ip/ to verify that HTTPS doesn't route from 443 externally
  3. Visit http://external-ip:8080/ to verity that HTTP doesn't route in from 8080 externally
  4. Visit https://external-ip:8080/ to verity that HTTP doesn't route in from 8080 externally
  5. Visit http://external-ip:60001/ to verify that HTTP doesn't route from 60001 externally
  6. Visit https://external-ip:60001/webcam to verify that nothing displays externally unless you've credentialed

I think I would describe to the audience why this is better than non-ACL/SSL port-forwarding of OctoPi. As an I.T. geek, I know how but you can't assume that your viewer would. You might begin with a short blurb about what you're trying to fix (insecure setups) and to enable (remote control).

Pretty sure the average person would be interested to see their webcam output and this wasn't covered nor described. Decide whether you want to support that or not but at least mention it.

Good job, btw.

1 Like

@OutsourcedGuru - great suggestions. I'm going to change the title of the YouTube video based on the name you gave this post - much more descriptive. In fact, I'm going to put that in the video and re-upload it.

I'll also incorporate the assertions that you provided - excellent idea!

By the way, I'm not sure what you mean about the webcam output. I'm able to get to OctoPrint just fine and see the webcam. Is the webcam not streamed over https://[web address]/webcam/?action=stream it should be encrypted as well, right? Did I miss something?

Thanks!
Derek

Ok, new version with @OutsourcedGuru's suggestions incorporated.

The streaming output should only be enabled over https + ACL with haproxy's /webcam path rather than 1) natively over the mjpg_streamer's 8080 port or 2) over http without ACL. https://ip-address:60001/webcam would be acceptable since it has to jump through the ACL hoop first. Glad to see the webcam is working remotely with this solution. :+1:

1 Like

:+1:

Should we maybe move this into the "Guides" section?

1 Like

I’m not sure how to do that, but that would be fine with me.

I was about to suggest that myself.

is there a way not doing it for port 80 ?
Having problem with Cura can't connect

Rather than browsing to find it, click Add and manually enter the address and port for it; see if that works.

19%20PM

Didn't work, just fails to connect

I guess you're down to slicing in Cura and uploading the gcode to OctoPrint; I can't think of a work-around that doesn't expose port 80 and that's just dangerous.

Is there a way to configure haproxy based on the local network client connecting? I would assume that you could change the config to handle that so it's not forcing ssl redirect when you go to port 80 from an internal network?

1 Like

@jneilliii I was just about to ask the same if you could white-list local IP addresses ?

So I haven't tested it yet but I found this...

redirect scheme https if { hdr(Host) -i www.mydomain.com } !{ ssl_fc }

So I would assume that if you set this redirect line to the equivalent external ip (or FQDN) for www.mydomain.com then when you access it from internal ip address it wouldn't redirect.

I think this worked, update your haproxy.cfg to have something similar to the following in the public front end section just after the option forwardfor line and then restart the service.

        option forwardfor except 127.0.0.1
        redirect scheme https code 301 if { hdr(Host) -i www.mydomain.com } !{ ssl_fc }
        use_backend webcam if { path_beg /webcam/ }
        default_backend octoprint

Then when you go to http://192.168.0.2/ it doesn't redirect, but if you go to http://www.mydomain.com/ it does redirect.

Additional information, with the latest 1.3.10 release candidate I was able to use an application key to connect Cura to OctoPrint, but I had to manually add the server with ip address in lieu of using the discovered octopi.local connection that shows up in the Cura settings as described by @OutsourcedGuru above. I would assume that a user api key would also work here.

Note that if you want to use an https connection with the OctoPrint Connection plugin in Cura, there's a checkbox for that when you check the "Show reverse proxy options" checkbox in the Manually added OctoPrint instance dialog.

The problem I have with that is ssl based client certificates. I don't think the Cura plugin can handle that best I could tell.